The JERM Ontology is an application ontology designed to describe the items in SEEK and the relationships between them (for example, data, models, experiment descriptions, results, samples, protocols, standard operating procedures and publications); and to enable these relationships to be expressed with formal semantics.
Partial fix for #2 - mapping JERM to PROV-O as upper ontology.
I have mapped with rdfs:isDefinedBy citations rather than noisy owl import.
In particular mapping classes:
jerm:Person subclassOf prov:Person as a JERM person must be a member of at least one Project, and (for some reason) must be a contributor of some Asset
jerm:hasContributor subPropertyOf prov:wasAttributedTo (and thus also jerm:hasCreator)
While I was tempted, I did not add:
jerm:Process subclassOf prov:Activity -- as jerm:Process says it hasContributor some Person -- the mapping above for hasContributor would (on OWL import of the whole PROV-O ontology) cause an inconsistency because prov:wasAttributedTo has a domain of prov:Entity, which in PROV is disjoint with prov:Activity.
I am a bit confused of what the jerm:Process hierarchy means, are they plans for processes experiments, etc. that may or may not happen, or are they something that has happened (or is already happening). I would think it should be the second, which hints that it is a prov:Activity, as defined in PROV
An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities. [Detailed specification] Just as entities cover a broad range of notions, activities can cover a broad range of notions: information processing activities may for example move, copy, or duplicate digital entities; physical activities can include driving a car between two locations or printing a book.
In that aspect we would then presumably also map jerm:hasInput equivalentProperty prov:used and jerm:hasOutput equivalentProperty prov:generated -- but I'm not sure here again if JERM's hasInput/hasOutput are meant to be records of something that was used/made, or linking to a (template/type) of something that could be used/made - the use of present tense here makes it very confusing.
stuzart
commented
6 years ago
Partial fix for #2 - mapping JERM to PROV-O as upper ontology.
I have mapped with
rdfs:isDefinedBycitations rather than noisy owl import.In particular mapping classes:
jerm:Person subclassOf prov:Personas a JERM person must be a member of at least oneProject, and (for some reason) must be a contributor of someAssetjerm:MaterialEntity subclassOf prov:Entityjerm:InformationEntity subclassOf prov:EntityAnd object properties:
jerm:isDerivedFrom equivalentTo prov:wasDerivedFromjerm:hasContributor subPropertyOf prov:wasAttributedTo(and thus alsojerm:hasCreator)While I was tempted, I did not add:
jerm:Process subclassOf prov:Activity-- asjerm:Processsays ithasContributor some Person-- the mapping above forhasContributorwould (on OWL import of the whole PROV-O ontology) cause an inconsistency becauseprov:wasAttributedTohas a domain ofprov:Entity, which in PROV is disjoint withprov:Activity.I am a bit confused of what the
jerm:Processhierarchy means, are they plans for processes experiments, etc. that may or may not happen, or are they something that has happened (or is already happening). I would think it should be the second, which hints that it is aprov:Activity, as defined in PROVIn that aspect we would then presumably also map
jerm:hasInput equivalentProperty prov:usedandjerm:hasOutput equivalentProperty prov:generated-- but I'm not sure here again if JERM's hasInput/hasOutput are meant to be records of something that was used/made, or linking to a (template/type) of something that could be used/made - the use of present tense here makes it very confusing.