Open wouterbeek opened 3 years ago
I was helped by two of my brilliant colleagues:
I hope this issue can still be of some help to others who have the same question in the future. (And it would not be wrong to use more descriptive labels, like [5]; although strictly speaking this is not necessary.)
If we had been starting with a blank sheet I would have made the relationship names clearer, but most of them had already been established in the 2006 Note, and we were constrained to preserve them for 'backward compatibility'. Perhaps the labels and descriptions could be made clearer? Would you have any suggestions?
@dr-shorthair I agree that the IRIs should not be changed now. (Personally, I actually like the conciseness of time:after
and time:before
). But indeed the human-readable labels and descriptions could be updated a little bit for clarification purposes.
I would propose the following:
time:after
rdfs:comment "Asserts that the subject term denotes a temporal entity that occurs after the temporal entity denoted by the object term. If a temporal entity S occurs after a temporal entity O, then the beginning of S is after the end of O. As such, this property can be considered basic for instants and derived for intervals."@en;
rdfs:label "is after"@en.
time:before
rdfs:comment "Asserts that the subject term denotes a temporal entity that occurs before the temporal entity denoted by the object term. If a temporal entity S is before another temporal entity O, then the end of S is before the beginning of O. As such, this property can be considered basic for instants and derived for intervals."@en;
rdfs:label "is before"@en.
My motivation is as follows:
time:before
. I'm not 100% sure this sentence really adds some useful information. But if it is added for time:before
, then it should also be added for time:after
.time:after
and time:before
are) and the human-readable label adds that extra connecting verb that allows formal triples to connect to their corresponding human-readable sentences (e.g., "World War 2 is after World War 1", assuming the events have human-readable labels as well).I'm not able to write the Spanish equivalents :-( I hope that somebody else may be able to do so.
Thanks @wouterbeek @lvdbrink @tguild what is the right strategy for improvements/revisions to documentation in existing RDF files.
@dr-shorthair @wouterbeek Maybe this issue should be reopened?
@akuckartz I've adjusted the issue title and description to turn what was a question about the semantics into a suggestion for improving the human-readable content.
@tguild what's the procedure for a non-normative update to a published REC? I believe that's what we want to do here.
Time is at Candidate Recommendation not REC (final stage, which although final has criteria for making modifications).
https://www.w3.org/TR/2020/CR-owl-time-20200326/
If we can deem them editorial instead of substantive changes then it is simpler process wise. Let the debate on semantics around substantive begin :)
https://www.w3.org/2020/Process-20200915/#substantive-change
I've found myself turned around more than once on these two properties. A small change to the documentation would be welcome.
I would say that the here proposed changes are not substantive: the meaning of the properties is not changed, only clarified.
^ I was not aware of the formal definition of "substantive". See @lvdbrink 's post for the correct answer.
Looking at https://www.w3.org/2020/Process-20200915/#substantive-change ...
Changes which resolve ambiguities in the specification are considered to change (by clarification) the implementation requirements and do not fall into [the class of Corrections that do not affect conformance].
That would suggest that the changes @wouterbeek proposes, updating the human-readable labels and descriptions for clarification purposes, would be substantive changes.
But his proposal is to change the published vocabulary file, not the spec itself, does that change things?
Time is at Candidate Recommendation
It had been a Rec but flipped back to Candidate when we added the IANA Considerations section. That was best part of a year ago. It should be OK to progress already.
W3C process and rules are rather fierce.
Previous transition https://github.com/w3c/transitions/issues/228
I discussed with @plehegar and he suggests and I agree:
The .rdf and .ttl are only mentioned in the abstract but should be made normative in section 4 explicitly, indicating they take precedence to the more human readable spec.
We should correct the rdf/ttl, clarify their role and republish as a CR.
He also helpfully provided an example:
https://www.w3.org/TR/ttml2/#schemas
We can do similar in Section 4
Or section 2, where the namespace URI is introduced? That URI currently gets you the TTL file, though that is not made clear in the text, and the URI is not a hyperlink. And perhaps there should be a HTML landing-page with links to alternative serializations.
@dr-shorthair It is not uncommon to have a html page at the same URI of the namespace, intended to be human readable. In this case we have the spec.
We also typically do content negotiation for giving ttl, rdf, html or other versions
So I created this HTML landing-page for the namespace: https://github.com/w3c/sdw/blob/gh-pages/time/time.html I also took the opportunity to add links to the RDF artefacts for the two extensions that are published as Working Group Notes.
This landing page looks good to me!
@dr-shorthair if you follow Ted’s suggestion
The .rdf and .ttl are only mentioned in the abstract but should be made normative in section 4 explicitly, indicating they take precedence to the more human readable spec.
We should correct the rdf/ttl, clarify their role and republish as a CR.
Then we can move this CR throught the process as it should and get a REC published with this fix.
OK - I've done the minimal changes to the Rec document that point out to the RDF implementation, where this improved documentation will be found.
Can we move this forward now?
@dr-shorthair others,
I just ran into the same issue that I had in 2021: having to look up the order of time:after
and time:before
and finding it hard to deduce from the OWL Time vocabulary. Then I remembered this issue :-)
IIUC then all details were sufficiently discussed and we are waiting for somebody to effectuate the suggested improvements.
Observation
This issue is about clarifying the intended directionality of
time:before
andtime:after
. Suppose a user wants to describe the two world wars as historic events. According to Figure 2 in the OWL Time standard document, she should use assertion [2] for this and not assertion [1]. For a user that is only looking at the vocabulary, this directionality will not become clear. And even if the user looks up the standard document, the directionality is only explained in Figure 2, and not in the running text.Suggestion
Let's improve the vocabulary file to include better human-readable content for
time:before
andtime:after
. Specifically:From the description of
time:after
the intended directionality is not clear. A reader does not learn the correspondence betweenT1
/T2
in the description and the subject/object positionality in triple usage, which is crucial for applying the property correctly:The description of
time:before
does not provide any additional information over the description fortime:after
. Since this description is completely symmetric with that oftime:after
, both directionalities are still possible:The values of
rdfs:label
do not communicate the directionality either. These labels are identical to the IRI local names, i.e.,"before"@en
and"after"@en
, not exposing additional information to the reader either.See the comment below for a concrete suggestion for a rewrite of these human-readable label. The semantics of these properties is not affected, only their documentation within the vocabulary.