How to deal with rough dates

[fvepwc]

During the last webinar there was a discussion on how to represent events that only have a rough date. We outline the main point below:

It could be problematic to have too tight a specificity on things like dates, for instance if you want to set up a meeting with only a rough idea (e.g., just the day and not the actual hour).

• Almost all models assume a specific date
• If it is just a rough idea, we better put it in another field. Question is which field…
• We could remove the date cardinalities to allow events without an exact timing. Which can then still be added later.
• Maybe for dates we could use the interval URI approach: http://reference.data.gov.uk/id/quarter/2006-Q1 [ see https://www.epimorphics.com/using-interval-set-uris-in-statistical-data/ ]

Please continue the discussion below

[rtroncy]

Almost all models assume a specific date

I'm a bit puzzled by this statement! Most of the event vocabularies have a property to indicate the start and sometime the end date of an event, but this largely includes fuzzy dates and certainly does not mandate to have timing information. I think that some of you may confuse the date type and the dateTime type, the later being just more specific than the former!

Many vocabularies defer the management of dates to the OWL Time Ontology for precisely this purpose. A year is a date. A month is a date. A day is a date. OWL Time enables to represent all sort of fuzzy dates.

The core event vocabulary should NOT create multiple properties to indicate the same level of information which will over complexify the queries while the (OWL Time) date type naturally handles fuzzy dates and times. Can you be more explicit on what exactly you have difficulty to represent in OWL Time?

[marc-portier]

There seems to be some confusion of terms here.

1. vocabulary versus application profile

• imho a vocabulary needs to stick to describing meaning an intended/suggested use, but not inforce models or cardinalities --> the latter is the realm of application profiles.

• all this should work in a context of open world assumption: there is no conclusion to be derived from fields (predicates) not being present

• of course particular applications can always decide not to be able to handle entities that have certain properties missing (e.g. if no dates are available, I can't show them in a calendar view) - other applications (e.g. handling with 'draft versions' have no reason to enforce such rules)

2. semantics of ranges versus semantics of indecision

there seems to be a string semantic distinction between these:

• we have decided to have an informal community event on the 2nd week of next year, that will start off as soon as enough people show up, and end when all drinks have been consumed...

• we have not yet decided on a particular date for this formal press conference that will take no longer than 15 minutes on some specific date and time in the 32rd week of this year to be announced

[EmidioStani]

In relation to issue #20, the proposal is to reuse OWL Time ontology which allows indeed different type of date formats

[williamverbeeck]

During the webinar on the review of Core Vocabularies on the 27th of October, it was agreed to:

• Use TemporalEntity.
• Add description and frequency property to TemporalEntity.
• Add hasNextEvent and hasPreviousEvent.