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.
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.