Warning: This tool or project is no longer maintained and kept available only for archival purposes. Since GoodRelations and schema.org have evolved significantly in the past years, the current status available on this page is unlikely to function as expected. We take no responsibility for any damage caused by the use of this outdated work, to the extent legally possible.

Due to a lack of resources, we are unable to provide support for this project outside of consulting projects or sponsored research. Please contact us if you can contribute resources to update and enhance these resources.

GoodRelations - The Web Vocabulary for E-Commerce

This is the archive of the goodrelations dicussion list

GoodRelations is a standardized vocabulary for product, price, and company data that can (1) be embedded into existing static and dynamic Web pages and that (2) can be processed by other computers. This increases the visibility of your products and services in the latest generation of search engines, recommender systems, and other novel applications.

[goodrelations] shop opening times - different times for different days in the week, and non-standard times for specific dates?

Ben Dougall ben at hdbatik.co.uk
Fri Oct 15 17:12:09 CEST 2010


Hello Martin,

On 10 Oct, 2010, at 5:10 pm, Martin Hepp wrote:

> If you want to be more specific, simply attach gr:validFrom and 
> gr:validThrough to your opening hours node:
>
>   <div about="#store" typeof="gr:LocationOfSalesOrServiceProvisioning">
>     <div property="rdfs:label" content="Pizzeria La Mamma"></div>
>     <div rel="vcard:adr">
>   ... vcard part omitted in here
>       </div>
>     </div>
>     <div rel="gr:hasOpeningHoursSpecification">
>       <div about="#mon_tue_thu" typeof="gr:OpeningHoursSpecification">
>         <div property="gr:opens" content="08:00:00" 
> datatype="xsd:time"></div>
>         <div property="gr:closes" content="17:30:00" 
> datatype="xsd:time"></div>
>         <div property="gr:validFrom" content="2010-10-10T00:00:00Z" 
> datatype="xsd:dateTime"></div>
>         <div property="gr:validThrough" content="2010-10-10T23:59:59Z" 
> datatype="xsd:dateTime"></div>
>         <div rel="gr:hasOpeningHoursDayOfWeek" 
> resource="http://purl.org/godrelations/v1#Thursday"></div>
>         <div rel="gr:hasOpeningHoursDayOfWeek" 
> resource="http://purl.org/goodrelations/v1#Tuesday"></div>
>         <div rel="gr:hasOpeningHoursDayOfWeek" 
> resource="http://purl.org/goodrelations/v1#Monday"></div>
>       </div>
>     </div>
>
>
> You must add these two lines
>
>         <div property="gr:validFrom" content="2010-10-10T00:00:00Z" 
> datatype="xsd:dateTime"></div>
>         <div property="gr:validThrough" content="2010-10-10T23:59:59Z" 
> datatype="xsd:dateTime"></div>
>
> to any <div about="#..." typeof="gr:OpeningHoursSpecification"> block.
>
> The time interval can be of any size - a single day, a week, a month, 
> a year.
>
> In GoodRelations, you can attach validity to opening hour information, 
> offers, or any pricing information.
>
> Thus, consumers of your data do not have guess on how long your 
> promises will hold.

I'm a little bit stuck on how to do this for what I want. Bit of 
background: I've already, previous to learning about the existence of 
GoodRelations, made an opening times system for a shop to display its 
opening times on its website so that the times shown always reflect 
reality, rather than the usual static generic Mon-Sun opening times 
display which are guaranteed to misinform people for some days of the 
year when opening times differ from standard. The system has a web form 
for the shop keeper to insert any differing from usual Mon-Sun opening 
times -- for specific dated days. The shop keeper is required to do 
this, when possible, at least 10 days in advance of the day in 
question, because 10 days is the amount of time the system looks ahead 
for displaying; if there's any days with differing from usual opening 
times within 10 days from the current day, rather than display the 
usual Mon-Sun times, it displays each dated day with its opening times 
10 days into the future. So the opening times display always reflects 
actual reality (assuming its kept up to date); but only for 10 days 
ahead. So I want to (I think this is what I want to do, maybe it's a 
bad idea? maybe there's a better way?) emit GoodRelations opening times 
data using the same logic as I'm using for the display of the opening 
times, that is, if in the next 10 days from the current day there's no 
days which differ from standard times, emit the weekly Mon-Sun 
GoodRelations opening times data. Alternatively, if and when there is 
at least one day whose times differ from the standard Mon-Sun opening 
times within the next 10 days from the current day, emit GR data which 
contains that specific info in the way you describe in the above quoted 
text.

 From your description above of how to do specific times, I think I'll 
be forced to give standard times (for any weekly day(s) whose times 
differ from standard), specific date ranges. For an example: Say it's 
now 1st of July and on the 12 of July, a Monday say, the shop has 
different from standard Monday times. 12th of July is 11 days away from 
the 1st of July, so on the 1st of July the standard Mon-Sun 
GoodRelations data would be emitted. Now let's jump ahead a few days. 
Now, on say the 5th of July, the 12th of July is within 10 days, so, so 
far as Monday goes, the GoodRelations data, an English description of 
it, should be this I think:

5th July to 11th July: Monday's standard opening times
12th July to 12th July: the differing from usual Monday opening times
13th July to ......... : Monday's standard opening times

My problem is what date to put in where I've put dots? In English you'd 
want to say "onwards" rather than a date. The system I've made, 
assuming it's being used correctly, only knows the right opening times 
10 days in advance -- for sure. So, the date where the dots are, seeing 
as "today" is the 5th of July, could be the 16th July. The system could 
say that knowing to be correct; no danger of misinforming. But doesn't 
that imply (or even state outright?) that the shop will be closed on 
Mondays from the 17th of July onwards? If it does imply or state that, 
then I should use a date months and months into the future maybe?, but 
with every chance of emitting incorrect data, as it's highly likely 
some Monday in that range, in the future, won't have its standard 
times. So my question is basically, how should this be handled, 
logically that is? In particular bearing in mind my system only knows 
10 days ahead for sure, but does know the standard weekly times, which 
generally, in a vague way, hold indefinitely.

It doesn't feel right having to give standard times date ranges. It's a 
shame you can't state standard weekly times indefinitely (no date 
range), and at the same time state any specific dated day's times which 
over-ride standard times. That's more how standard times work. Standard 
times are like default times. In the absence of any other info, 
standard times are assumed; defaults to them. I don't know how flexible 
the GR system is, I mean how much of its design can change, but it 
seems to me for opening times it'd be far better to be able set default 
weekly times, and then in addition to those, on top of those, specific 
times as and when needed which over-ride the standard times. Is it 
outright wrong to specify the standard weekly times, while in addition 
specifying a single day's date range with times which differ from the 
standard weekly times? If so, could be made to be not wrong?

Thanks, Ben.





More information about the goodrelations mailing list