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] Hello, questions about describing service area, sunset, and more

Martin Hepp martin.hepp at ebusiness-unibw.org
Tue Jun 7 22:41:59 CEST 2011


Hi Dan:
On Jun 7, 2011, at 10:15 PM, dan r wrote:

> Dear All,
> My name is Daniel Reed. I work for a mobile service company in California, USA. When I'm not providing service for a customer I integrate our administrative work flow into a SaaS CRM. Nothing too technical just some HTML forms, CSS, and cut-and-paste Javascript. I'm glad that you have an online annotator because  when RDFa gets complex I'm not sure how to properly code it. 
>   There are a few things I'd like to change in the results:
> 
> 1. How would the CA subdivision of US be stated here?
>  <div property="gr:eligibleRegions" content="US" datatype="xsd:string"/>

The list is e.g. at

http://en.wikipedia.org/wiki/ISO_3166-2:US

California is "US-CA":

> <div property="gr:eligibleRegions" content="US-CA" datatype="xsd:string"/>


> 
> 2. The business, stump removal, is classified as a tree service plus underground construction, therefore I give an estimate for the known portion of the service and the likely best case for the unknown portion. If the unforeseen or unexpected happens the customer is aware that the additional work is at the hourly rate. So I'd like to make them aware that I accept checks according to local customs ( gr:COD for cash or "local check" ) but not gr:CheckInAdvance since the actual price is known upon completion of service. I was hoping that if my terms weren't available the solution would be simple like gr:PaymentMethod xsd:comment"check", especially for gr:closes

I would use gr:COD.

For more specific payment options ("pay me in gold metals"), you can create a shop-specific instance of gr:PaymentMethod and define it in your main page (or any other page):

<div xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns:gr="http://purl.org/goodrelations/v1#">
   <div about="http://www.mypage.com/#Gold"
        typeof="gr:PaymentMethod">
      <div property="rdfs:label">Gold (gr:PaymentMethod)</div>
     <div property="rdfs:comment">We accept pure gold as a form of payment</div>
   </div>
</div>

You could then say
<div typeof="gr:Offering>
	<div rel="gr:acceptedPaymentMethod" resource="http://www.mypage.com/#Gold"> </div>
</div>

> 
> 3.The telephone callback hours are implied in our online survey 0800h-2000h. But the service hours are mainly daylight hours. So I'd like to express them as open: 0800h and close: sunset.

I would either use 0800-2000 or create multiple statements that are constrained using gr:validFrom and gr:validThrough - e.g., indicate individual opening hours for each month of the year. Computers need data; they cannot infer enough precision from a text like "sunset".

What you can to, though, is adding additional text to the gr:OpeningHoursSpecification element using rdfs:comment.


> Also, Saturday "by previous appointment only" ( I've noticed lately that many dentists are working Saturday "by appointment only").  I think of sunset as a relative term, but could it be a recurring pattern as mentioned in:
> http://ebusiness-unibw.org/pipermail/goodrelations/2011-May/000355.html ?
You could create a gr:OpeningHoursSpecification node for gr:Saturday, omit gr:opens and gr:closes and just attach your text using rdfs:label

> In the same post, I don't understand, "wrap a SPARQL endpoint around…" .

That means that you can expose a database or other dynamic data source as if it was an RDF database with all combinations materialized, while they are actually created only when a relevant query arrives. SPARQL is a W3C query language and interface specification for RDF data.

> But would a link to a wikipedia page about the concept of sunset work?
No, unfortunately.
> I'm trying to avoid multiple instances of gr:close for month and day-of-week all year long.
>   Even more precisely would be "close: sunset or local ordinance whichever is earlier". I'm content to live without this precision but it might be interesting from a modeling perspective. If locksmiths and automotive roadside assistance companies were to adopt good relations en masse then it would be useful to have a model like "sunset" for "after dark" since their terms of service change at nightfall.

The only way to model these terms in a form understandable for a machine is to compute those hours for any given day and create specific opening hour statements for each single day. But this would be a pretty sophisticated use-case. I would work with monthly approximations.
> 
> 4.There are two common ways of specifying a service area. One is a radius around a given location and the other is to specify a potentially irregularly shaped area in this case specifically, a county. Therefore I have a need for greater geographical granularity. Google places allows me to specify a service area by listing three counties and two cities. Google then includes all points in between. So in keeping with this concept, perhaps five vcards similar to this:
> BEGIN:VCARD
> VERSION:3.0
> N:Service Area 1
> ORG:Stump King LLC
> ADR;TYPE=WORK:;;Santa Clara County;CA;United States of America
> END:VCARD
> (modified from wikipedia example)
> then the snippet might be:
> <div rel="vcard:adr" resource="http://www.stumpking.com/#address"/>
>       <div rel="gr:hasPOS">
>          <div class="description" about="http://www.stumpking.com/#LOSOSP_1"
>               typeof="gr:LocationOfSalesOrServiceProvisioning">
>             <div rel="vcard:adr">
>                <div class="description" about="http://www.stumpking.com/#address"
>                     typeof="vcard:Address">
>                   <div property="vcard:country-name" content="United States of America" xml:lang="en"/>
>                   <div property="vcard:email" content="info at stumpking.com"/>
>                   <div property="vcard:locality" content="san jose"/>
>                   <div property="vcard:postal-code" content="95110"/>
>                   <div property="vcard:street-address" content="237 N. Autumn St."/>
>                   <div property="vcard:tel" content="+1-408-296-4476"/>
>                   <div rel="vcard:url" resource="http://www.stumpking.com/"/>
>                </div>
>             </div>
> <<!--my guess for service area-->>
>             <div rel="vcard:adr">
>                <div class="description" about="http://www.stumpking.com/#servicearea1"
>                     typeof="vcard:Address">
>                   <div property="vcard:country-name" content="United States of America" xml:lang="en"/>
>                   <div property="vcard:locality" content="santa clara county"/>
>                   <div rel="vcard:url" resource="http://www.stumpking.com/"/>
>                </div>
>             </div>
> <<!--repeat code block for four remaining components of service area incrementing to #servicearea2,etc.--> 
>             .
>             .
>             .
>          </div>
>       </div>
> </div>
> 
>  The hard way, I imagine, would be to approximate the corners of the service area shaded by Google with lat/long coordinates. Currently, the service area is implied by listing many local telephone numbers and cities.

GoodRelations does currently not allow specifying arbitrary geographical areas. You can only go down to ISO 3166 granularity. We may extend this in the future.
> 
> 5. The business has seven telephone numbers each listed next to an appropriate city. Fine for people and current SEO, but what about machines? It seems reasonable to have a vcard with seven TEL properties. Do machines need a pairing of city and telephone number? If so, seven vcards with n,adr, and tel properties only? (Where adr is only the city name). This is without pretending to have seven stores or gr:hasPOS

By far the best modeling is to create individual instances of gr:Location (new name for gr:LocationOfSalesOrServiceProvisioning, will become the preferred name tomorrow) for each service location and attach the phone numbers to those locations.

So seven gr:Location with seven vcards, seven tel properties.

> Thank you for your help,

You are very welcome!

Martin

> Daniel Reed
> _______________________________________________
> goodrelations mailing list
> goodrelations at ebusiness-unibw.org
> http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations





More information about the goodrelations mailing list