|
It looks like there are several proposals how to publish opening hours in RDF. Are there any real world applications with actual opening hours? I've read that the GoodRelation ontology should fit but only if your opening hours are very simple. I've also seen some artificial toy examples and discussions (for instance at Code4Lib). The opening hours should allow for day ranges and multiple time ranges per day, for instance:
And it should allow for multiple opening times for different seasons, for instance:
The seasons could also have date ranges, but a label should also be fine to start with. I also though about Timezone information, but if the opening hour is bound to a physical location, the timezone should better be derived from this location. |
|
As for day ranges and multiple time ranges per day, this is supported by GoodRelations. You can link multiple
It seems that GoodRelations would only need a minor modification to support "named" date ranges and thus to comply to the needs you stated above, perhaps some sort of 1
If you decide to use the time ontology, consider to use URI for timeInstant or timeIntervals as proposed by Ian Davis (http://placetime.com/). Once I create the instant or interval (e.g. http://placetime.com/instant/gregorian/1995-01-01T00:00:01+01:00) I attach to it the time:inTimeInstant property with value xsd:dateTime 1
Cool, I only need an algorithm to reshuffle the triples for a display like in my example - this could be a very complex SPARQL query, or I better use another method. It's only annoying that the range of I use it with real data when creating RDF dataset. In my opinion every datatype property is a dead end for linked data, so I use URIs as much as possible. In this case I also provide an alternative/traditional description to time by the xsd:dateTime. I model the start year and end year for a country to be member of a commission. I use the time information in my queries. |
|
@literary_machine provided a good answer that can be used for unnamed date ranges. To name a date range, you could create a resource that has the same date range. I found that only the Timeline Ontology can specify date ranges in a natural way (with a start day and an end day):
The client could then look up matching intervals in its terminology ( Wouldn't the |

