Get rid of multiple domains and time related issues
The following three properties all have multiple rdfs:domains
,
meaning the subject of that property has to be a subclass of at least two things:
-
time:TemporalEntity
(ortime:Instant
in the case ofvf:hasPointInTime
) - one of the VF classes listed in the
owl:unionOf
vf:hasBeginning a owl:DatatypeProperty ;
rdfs:label "has beginning"@en ;
rdfs:domain time:TemporalEntity ;
rdfs:domain [ owl:unionOf (vf:Commitment vf:EconomicEvent vf:Intent vf:Proposal vf:Scenario vf:Process) ] ;
rdfs:range xsd:dateTimeStamp ;
vs:term_status "unstable" ;
owl:propertyChainAxiom (time:hasBeginning time:inXSDDateTimeStamp) ;
rdfs:comment "The planned or actual beginning of a flow or process."@en ;
.
vf:hasEnd a owl:DatatypeProperty ;
rdfs:label "has end"@en ;
rdfs:domain time:TemporalEntity ;
rdfs:domain [ owl:unionOf (vf:Commitment vf:EconomicEvent vf:Intent vf:Proposal vf:Scenario vf:Process) ] ;
rdfs:range xsd:dateTimeStamp ;
vs:term_status "unstable" ;
owl:propertyChainAxiom (time:hasEnd time:inXSDDateTimeStamp) ;
rdfs:comment "The planned or actual end of a flow or process."@en ;
.
vf:hasPointInTime a owl:DatatypeProperty ;
rdfs:label "has point in time"@en ;
rdfs:domain time:Instant ;
rdfs:domain [ owl:unionOf (vf:Commitment vf:EconomicEvent vf:Intent) ] ;
rdfs:range xsd:dateTimeStamp ;
vs:term_status "unstable" ;
owl:propertyChainAxiom (time:hasEnd time:inXSDDateTimeStamp) ;
rdfs:comment "The planned or actual time of a flow; can be used instead of hasBeginning and hasEnd, if so, hasBeginning and hasEnd should be able to be returned with this value."@en ;
.
I would say, that this is quite uncommon, and I just tried to load it into a visual editor (https://app.gra.fo) that does not support it.
I checked the time ontology (http://www.w3.org/2006/time), and looking at :Instant
and :TemporalEntity
, I am pretty sure they are used wrong here in VF. VF uses them as "A subject that has a time (instant or interval)", but really it means "a time (instant or interval)",
so for example, a vf:Commitment
is not a time-interval, or say, there is no thing that is at the same time a time and a vf:committment, but rather there are commitments that have an assigned time. So time:Instant
, time:Interval
and time:TemporalEntity
should rather be used as the range, not as the domain. Then of course, we would have multiple ranges, so .. still an issue in my specific case, but less wrong already.
Also though, it seems to me like all of them would need to use time:Instant
, not time:TemporalEntity
, as they are all instants, no time ranges. If vf:hasEnd
and vf:hasBeginning
would be allowed to be ranges as well, then the second range (xsd:dateTimeStamp
) for them would be an issue again.
-> in short: This needs rethinking, I think.