Open ddooley opened 2 years ago
Hmmm. Since
ex:EventA time:hasTime ex:TimeEntityB .
is logically equivalent to
ex:TimeEntityB time:timePertainsTo ex:EventA .
Can't you just mint the former?
These days I'm a little wary of creating inverse properties since then you have a synching challenge - if there are two ways to express the same assertion, then what if they are inconsistent? And in this case, since the cardinality of time:timePertainsTo
relations are potentially large, then time:hasTime
would generally be easier to manage.
Hi Simon,
Indeed, with an extra table I can do the former. This request was just about shortcut convenience, but not a dealbreaker. The table we're putting into a RDF knowledge graph with the robot transform tool is a list of event types (pesticide authorized date, revoked date etc) per pesticide. Robot only has 1 subject entity per table row and all relations have to emanate from that entity, so having time:timePertainsTo lets us add one more TimeEntity-centric piece of info. Basically, doing the same semantically as IAO "is about" does for information about some entity.
FYI, what the table looks like except I can't use "is about". Robot commands are 2nd line, they apply relation between id column and given column.
I’m not sure if this is the right contact point, but my question is whether or not there is an inverse relation for the OWL-Time time:hasTime object property? If not we would appreciate one, perhaps called time:timePertainsTo to enable easy addition of dates associated with an entity. The RDF building tool (http://robot.obolibrary.org/template) we use reads in tabular data and converts to RDF triples, so reverse relations are sometimes much more convenient. (In our project case, types of regulatory pesticide issue/revocation etc. dates that have a many-to-one relation to a pesticide.)
Regards,
Damion
Damion Dooley, Ontology Development Lead Mobile 778-688-0049 Centre for Infectious Disease Genomics and One Health Faculty of Health Sciences, SFU, Canada