This is the archive of the goodrelations dicussion list

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"/>

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

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. 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 ?
In the same post, I don't understand, "wrap a SPARQL endpoint around…" . But would a link to a wikipedia page about the concept of sunset work? 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.

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.

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
Thank you for your help,
Daniel Reed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ebusiness-unibw.org/pipermail/goodrelations/attachments/20110607/87c540b4/attachment.html>