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

date of the public event currently is hiding as a nerdy "A textual representation of the Temporal Entity" in hasTime #24

Open
SebastianSK opened this issue Dec 7, 2022 · 2 comments

Comments

@SebastianSK
Copy link

SebastianSK commented Dec 7, 2022

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.

image

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

@EmidioStani
Copy link
Member

Hello @SebastianSK , thanks for your feedback, while I kept the definition the same (coming from Time ontology), I added the usage note:
https://semiceu.github.io/Core-Public-Event-Vocabulary/releases/1.0.0/#Public%20Event%3Ahas%20time

@jpmckinney
Copy link

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.

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

3 participants