radical-data / mosa-ontology Goto Github PK

Related to #6, if the ontology allows for multiple perspectives, we might also want to allow that mutual agreement is made on a piece of information. In this case, we would want to 'lock' that information. How would this work at the ontology level?

It turns out @valevo is old school and writes directly in HTML. This is fine for now (and quite funny for me).

However, this isn't ideal for maintenance longer term.

I'm wondering what tooling is available for developing, documenting and maintaining ontologies. This is a new area to me so we will need some research.

In some initial notes, @valevo wrote "For the MoSA, we opt for a Linked Open Data (LOD) approach (a rather obvious choice)". At the risk of sacrilege I want to check: is this obvious? For ease of implementation, could another approach not make sense?

Based on our discussions with Leo and Paula, a key part of the MoSA database (and thus ontology) will be its ability to incorporate different views. How can we do this?

One question to help think through this might be: what is the primary mental model for this? Perhaps it is closer to a wiki than a traditional database? However, wikis typically involve different views disputing the one perspective which will be labelled the truth. What we're looking for is an ontology that can maintain multiple dissenting views at the same time.

@valevo:

can we make use of https://localcontexts.org/?

@jokroese:

Do you have a vision for which part of their work is most relevant for us? The part I can find that is most relevant for the data model is this taxonomy: https://localcontexts.org/support/taxonomy/

Other than that, it would be great to learn about their labels/notices/guidelines on working with indigenous communities.

@valevo:

where do we get unique identifiers from for objects? (what about persistent identifiers?)
→ mint our own? especially for sources of information that don’t provide them
→ even for objects registered at institutions that provide IRIs, minting our own could be a gesture of reclamation

@jokroese:

mint our own?

This would be great! I think it would be great to do this for all of them, as a singular trace through time and, as you said, a gesture of reclamation.

In this part of the data model:

        cidoc:P43_has_dimension [
            a cidoc:E54_Dimension ;
            # could additionally have cidoc:P2_has_type mosa:Height (for example)
            schema:unitText "cm" ;
            schema:value 165 ],
        [ 
            a cidoc:E54_Dimension ;
            # could additionally have cidoc:P2_has_type mosa:Width (for example)
            schema:unitText "cm" ;
            schema:value 9 ],
        [ 
            a cidoc:E54_Dimension ;
            # could additionally have cidoc:P2_has_type mosa:Width (for example)
            schema:unitText "cm" ;
            schema:value 6 ] ;

There's the following comment:

by using CIDOC-CRM's P43_has_dimension, we are committing to objects being "cidoc:E70_Thing"s (because that's the deomain of the predicate)
dimension could also be made part of the mosa:physical_object property (depending on how "debatable" this info is considered)

Could we instead define (e.g.) height through schema's height property (https://schema.org/height)? Would that avoid us committing to It being a 'Thing' in CIDOC's sense? (height is also a property of schema's 'Thing' type, but in schema Thing is more general, with subtypes such as 'Person'.)