Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TIME: Suggestions for alignment with PROV-CONSTRAINTS "precedes"? #1430

Open
ajnelson-nist opened this issue Jun 26, 2023 · 1 comment
Open

Comments

@ajnelson-nist
Copy link

This is an Issue about how to interpret a certain property in OWL-Time, time:before. There is a detour through PROV that explains why I'm asking. It is possible this issue also shows a point of needed clarification in the current OWL-Time draft.

While reviewing the non-normative alignment of TIME and PROV here ...

https://github.com/w3c/sdw/blob/gh-pages/time/rdf/time-prov.ttl

... I saw that there is an alignment axiom for prov:Activity:

prov:Activity
  rdfs:subClassOf time:TemporalEntity ;
.

From working with PROV, I had come to think it would be more appropriate for prov:Activity to be a subclass of time:ProperInterval. However, when double-checking my sources, I wasn't able to find a strict requirement that, given a prov:Activity with a prov:Start and prov:End, that prov:Start was required to happen strictly before prov:End.

From review of PROV-CONSTRAINTS, I came across this evidence that a prov:Activity is permitted to be instantaneous:

  • Constraint 30 (start-precedes-end) uses the defined term "precedes".
  • "precedes" is defined like so: "Specifically, precedes is a preorder between instantaneous events. A constraint of the form e1 precedes e2 means that e1 happened at the same time as or before e2." So, "precedes" is roughly writable as "<=".
  • "strictly precedes", in the same paragraph as "precedes", is defined to have the two related (instantaneous) events not occur at the same time.
  • Reviewing "Activity" in PROV-O and in PROV-DM didn't provide a hint on required inequality of its start or ends.
  • Reviewing "Start" in PROV-O and in PROV-DM shows a reliance on "follows" (inverse of "precedes") that is not clarified as being a strict "<" or permissive "<=" binary relationship.

Where all this circles back to OWL-Time: I see two properties that can be used to relate one time:Instant to another time:Instant, time:before and time:after. The definitions, as currently worded, do not make explicit whether the properties permit equality of the instants being related. Personally, my normal reading of the words "before" and "after" imply a strict-inequality relationship; but, apparently W3C editorial policy in the past has permitted a standard to be posted where "precedes" could be defined as "<=", so now I feel the need to check.

If I have a statement x time:before y ., can x and y refer to the same time:Instant?

For the sake of finding a way to align with the "precedes" definition in PROV-CONSTRAINTS: Is there a predicate in OWL-Time that defines "<=" between time:Instants?

Should one of time:before or time:after be designated an owl: AsymmetricProperty? An owl:ReflexiveProperty or owl:IrreflexiveProperty? time:before is currently a owl:TransitiveProperty, so it seems some thought was put into property specializations, but I'm not sure where notes on those specializations might be.

@dr-shorthair
Copy link
Collaborator

Thanks for the very detailed comment.

We only used some of the possible OWL axioms, in particular we did not attempt to complete the possible owl: AsymmetricProperty, owl:ReflexiveProperty, owl:IrreflexiveProperty, owl:FunctionalProperty, owl:InverseFunctionalProperty.
Maybe we should have.

However, the issues you raise may be dealt with in the 'extension' to OWL-Time where we attempted to complete the set of topological relations - see https://www.w3.org/TR/vocab-owl-time-rel/ in particular see https://www.w3.org/TR/vocab-owl-time-rel/#new-relations

As you will observe, this work, though several years old now, has not progressed past 'Note' status.
This was partly because we needed more evidence that these additional relations were in fact needed.
Your comment appears to confirm that they are.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants