You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So whereas technically this seems fine. I see the following room for improvement:
On the semantic and organisational layer of interoperability and from a user perspective:
When I look in the Spec or search for the term "date" in the XSD file it seems not right to have no match.
The reference of the hasTime property with "A textual representation of the Temporal Entity" seems not to be state of the art (because it describes the concept with its own name". Here might be a good entry point to mention that this might include the DATE of the event.
So my recommendation is
a) to mention "date" or "date of the event" somewhere in the specification,
b) perhaps even stick the word "date" near to the property hasTime , e.g. in the description
The text was updated successfully, but these errors were encountered:
Most events either have a single time (for the start) or a pair of times (for the start and end). I understand that the time ontology is used to handle the wide range of other possibilities (recurring, etc.), but it would definitely benefit the documentation to have a few examples for the most common cases.
One use case of using the public event vocabulary could be to get to know WHEN is the public event.
This usually means the date and the time.
The current release features a
https://www.w3.org/2006/time#hasTime
property and has hasTime written in the UML Diagramme.
So whereas technically this seems fine. I see the following room for improvement:
On the semantic and organisational layer of interoperability and from a user perspective:
When I look in the Spec or search for the term "date" in the XSD file it seems not right to have no match.
The reference of the hasTime property with "A textual representation of the Temporal Entity" seems not to be state of the art (because it describes the concept with its own name". Here might be a good entry point to mention that this might include the DATE of the event.
So my recommendation is
a) to mention "date" or "date of the event" somewhere in the specification,
b) perhaps even stick the word "date" near to the property
hasTime
, e.g. in the descriptionThe text was updated successfully, but these errors were encountered: