dsp-api

dsp-api copied to clipboard

After discussing with @lrosenth and @subotic, and following issues #525 and #566, the knora projects metadata ontology should be implemented as a system ontology.

• @subotic and @lrosenth will provide the draft for this ontology
• I will proceed on this base to add the classes and properties listed here
• I will map them with at least a standard ontology (DCAT-AP being the first choice).

@subotic when do you think you will have time to help me with the draft ?

Maybe the easiest is to create a new branch and do it directly in the repository. I will do that now.

@benjamingeer any naming preference for this ontology? Something like knora-ontologies/knora-project-metadata.ttl ok?

Sounds good to me!

Great, thanks!

I have questions regarding the implementation of this ontology. Taking the other "system" ontology as examples, this what my classes look like:

knora-metadata:Agent rdf:type owl:Class ;
  rdfs:comment "An agent, involved in the data life cycle (research data, heritage data, etc.)"@en , "Un agent intervenant dans le cycle de vie des données (ex.: données de la recherche, données patrimoniales, etc.)"@fr ;
  rdfs:label "Agent"@en , "Agent"@fr ;
  rdfs:subClassOf [ rdf:type owl:Restriction ;
                    owl:minCardinality "1"^^xsd:nonNegativeInteger ;
                    owl:onProperty knora-metadata:hasName ] .

and here is what the properties look like:

• Datatype properties definition:

knora-metadata:hasName rdf:type owl:DatatypeProperty ;
  knora-base:objectDatatypeConstraint xsd:string ;
  knora-base:subjectClassConstraint knora-metadata:Agent ;
  rdfs:comment "An agent's name"@en , "Un nom d'agent"@fr ;
  rdfs:label "Name"@en , "Nom"@fr .

• Objet properties definition:

knora-metadata:hasMembership rdf:type owl:DatatypeProperty ;
  knora-base:objectClassConstraint knora-metadata:Organisation ;
  knora-base:subjectClassConstraint knora-metadata:Person ;
  rdfs:comment "An organisation a person is member of"@en , "Définit le rattachement institutionnel d'une personne"@fr ;
  rdfs:label "Membership"@en , "Affiliation"@fr .

Is it right? Or should I treat this ontology more like project-specific one and make all my classes subClasses of knora-base:Resource and all my properties superproperties of knora-base:hasValue ?

You're doing it right. Don't use knora-base-Resource for this.

But an object property needs to have rdf:type owl:ObjectProperty.

Thanks for the answer.

But an object property needs to have rdf:type owl:ObjectProperty.

Yes, of course. My bad.

But I was also asking because maybe we would like to use controlled vocabularies for some properties (e.g. licences, position, etc.). But I am not sure we could do that if the properties are not subproperties of knora-base:hasValue.

On the other hand, if we want to have our metadata harvested by any external aggregator, maybe we should keep it as flat and simple as possible. What do you think?

I would keep knora-project-metadata completely separate. Then if necessary, knora-base and knora-admin can reference it.

But I was also asking because maybe we would like to use controlled vocabularies

Do you mean existing standardised ontologies like FOAF? You can use them, no need for anything Knora-specific.

Do you mean existing standardised ontologies like FOAF? You can use them, no need for anything Knora-specific.

Not, that is not exactly what I meant. But using standardises ontologies will be the next step.

I mean we could decide to use some lists (flat list, hlist), like we usually do in project-specific ontologies. I thought we could for example provide a list of all the relevant licences the DaSCH will support under a pulldown menu. But maybe it is going too far?

@subotic If we use hierarchical lists in knora-project-metadata, maybe we should move ListNode and friends out of knora-base and into knora-admin? That would be fun. :)

I am just wondering. And asking for opinions :)

@mrivoal Another option would be to make a Licence class with NamedIndividual members (like Guielement in salsah-gui). Then it would be easy to query for all the licences and make a dropdown, for example.

Yes, we could do this if it is easier to handle.