# Ontologies

Sticking to GN tables is a bad idea because it doesn't capture what "how" we want to define our data.  Second we are not using the freedom of RDF.

Here, we note down all lessons learnt while we continuously improve our ontologies.

### Resources
=> https://wrdrd.readthedocs.io/en/latest/consulting/knowledge-engineering.html Knowledge Engineering
=> https://www.w3.org/wiki/VocabularyMarket Vocabulary Market
=> https://www.w3.org/TR/prov-o/ PROV-O: The PROV Ontology
=> https://bioportal.bioontology.org/ontologies Browse Ontologies related to biology
=> https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ DublinCore DCMI Metadata Terms
=> https://www.w3.org/TR/skos-primer/ skos primer
=> https://www.w3.org/TR/vocab-dcat-2/ Data Catalog Vocabulary (DCAT) Version 2
=> https://www.w3.org/TR/vocab-data-cube/ Data Cube Vocabulary
=> https://www.w3.org/TR/shacl/ Shapes Constraint Language (SHACL)

####  Learning
=> https://sparql.dev/ Learn Sparql
### rdfs:label

Consider this pattern when dumping data in rdf:

```
(set gnt:displayName (field Species MenuName))
```

Notice that we use a new term: "gnt:displayName".  This is unnecessary.   Since what we want is to use a human readable way of capturing that.  A better way would be:

```
(set rdfs:label (field Species MenuName))
```

This prevents us from having to "invent" our own terms all the time.


### rdfs:domain and rdfs:range

We use "rdfs:domain" and "rdfs:range" to "connect" a property to a class.  So:

```
gn:code rdfs:domain gnc:inbredSet
```

means that gnc:inbredSet has the predicate gn:code.   To represent the above using rdfs:range:

```
gnc:inbredSet rdfs:range gn:code
```

Read more here:

=> https://www.ida.liu.se/research/semanticweb/events/SemWebCourse2018/OWL_basics.pdf Ontology Engineering - The basics of OWL (PDF)