Re: data model and example

Yes I agree between label, category and link we can do a lot towards what I might call a "commerce" extension to the core POI. Hopefully we can work on that before year end!

---
Raj
The OGC: Making location count...
http://www.opengeospatial.org/contact


On Oct 3, at 3:49 PM, Seiler, Karl wrote:

> Very cool, Raj. Works nicely. Concerning the meat in the non-core attributes, I was assuming between label, category and link we could potentially incorporate the rest, as local extensions via reuse of primitives.  See my example below.
>  
> <?xml version="1.0" encoding="UTF-8"?>
> <pois lang="EN-US" xml:base="http://www.navteq.com/pois">
> <description>An example collection of pois</description>
> <poi id="17529793"><!--<SupplierID>3</SupplierID>-->
> <label lang="EN-US" term="official">LANGER'S DELI</label>
> <category term="5800" scheme="../DEFINITIONS/category.xml#NT">5800</category>
> <category term="722110" scheme="http://www.census.gov/naics/2007/NAICOD07.HTM" href="http://www.census.gov/econ/industry/current/c722110.htm">Full-service restaurants</category>
> <link href="http://www.zagat.com/49465" type="text/html" rel="related"/>
> <location><point term="entrance"><Point>
> <location>
> <point term="entrance">
> <Point>
> <posList>34.05632 -118.2768</posList>
> </Point>
> </point>
> <address> BEGIN:VCARD VERSION:4.0 N:Gump;Forrest;;; ADR;TYPE=work;:;;704 ALVARADO ST.;LOS ANGLELES;CA;90057;United States of America REV:20080424T195243Z END:VCARD US </address>
> </location>
> <label lang="EN-US" term="accepts credit cards">TRUE</label>
> <description lang="EN-US">The "legendary" "hand-sliced" pastrami and "fantastic double-baked rye" really get 'em "drooling" at this 1947-vintage Downtowner, a "classic" "old-time deli" (tops in its category) staffed by "wiseacre" "waitresses who aren't afraid to call you 'honey'"; despite the "dicey" 'hood, it's "worth the schlep" for a "fix", though regulars know to "call ahead" for curbside pickup; P.S. closes at 4 PM daily, closed Sundays.</description>
> <!-- these items not part of core POI but interesting for an extension <Contacts></Contacts> <Details> <PaymentMethod></PaymentMethod> <Area></Area> <Review></Review> <Restaurant_Information></Restaurant_Information> </Details> --><!-- not core, but here's an example of how to do open 8am-4pm Monday through Saturday -->
> <time type="text/calendar"> BEGIN:VCALENDAR VERSION:2.0 BEGIN:VEVENT DTSTART;TZID=US-Pacific:19970902T080000 DURATION:8H RRULE:FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA END:VEVENT END:VCALENDAR </time>
> </poi>
> </pois>
>  
> 
>  
>  
> _______________________________
> Karl Seiler
> Director Location Technology & Services
> NOKIA Location and Commerce - Chicago
> (T)  +312-894-7231
> (M) +312-375-5932
>  
> From: Raj Singh [mailto:rsingh@opengeospatial.org] 
> Sent: Monday, October 03, 2011 12:33 PM
> To: Seiler, Karl
> Cc: public-poiwg@w3.org W3C
> Subject: Re: data model and example
>  
> Here's one of your POIs, and my POIWG interpretation. 
> Will post on Wiki soon.
> Matt, did you figure out how we can do XML syntax highlighting on the wiki?
> ---
> Raj
> The OGC: Making location count...
> http://www.opengeospatial.org/contact
> 
> 
> On Oct 3, at 9:37 AM, Seiler, Karl wrote:
> 
> > Raj,
> > 
> > Attached are 2 files with some example POIs that are rich, in the common sense, in my conventional POIXML format. I was going to try to convert to the W3C POI model.
> > 
> > I can grab some reference snapshots of:
> > - location objects (areas) - for city, state
> > - attached are raw materials for restaurants and camping
> > - commercial airports consist typically of several POIs for different arrivals and departure gates, will find some WEU and ME-A references
> > - for routes I will try to lift a formal bus or train transit route's raw product XML and see if we can convert
> > 
> > More to follow
> > _______________________________
> > Karl Seiler
> > Director Location Technology & Services
> > NOKIA Location and Commerce - Chicago
> > (T)  +312-894-7231
> > (M) +312-375-5932
> > 
> > 
> > -----Original Message-----
> > From: Raj Singh [mailto:rsingh@opengeospatial.org]
> > Sent: Friday, September 30, 2011 10:58 PM
> > To: Seiler, Karl
> > Cc: public-poiwg@w3.org W3C
> > Subject: Re: data model and example
> > 
> > Great! I'd love to start writing examples. I'd like a few more details though. Can you write up a series of use cases in short bullet points. Here are some examples already on my list:
> > - city in the US
> > - county in the US
> > - state in the US
> > - the US
> > - restaurant in NYC (with: opening/closing hours, menu, ratings, reviews)
> > - airport (links to airlines serving the airport?)
> > - museum (links to items in the collection?)
> > - historic site
> > - Boston Freedom Trail
> > - a bike route
> > 
> > ---
> > Raj
> > The OGC: Making location count...
> > http://www.opengeospatial.org/contact
> > 
> > 
> > On Sep 30, at 3:28 PM, Seiler, Karl wrote:
> > 
> >> Reviewed the example XML via the link below. Stared at it for a good bit. Made a few permutations of my own to see if I got how the layering works. I like it very much.
> >> 
> >> This is good! This works. This is useful.
> >> 
> >> I would like to make some smallest (crispest - minimal) to largest examples (all rich content as per fully blown out real world POIs fully and explicitly rendered) based on this model.
> >> 
> >> _______________________________
> >> Karl Seiler
> >> Director Location Technology & Services
> >> NOKIA Location and Commerce - Chicago
> >> (T)  +312-894-7231
> >> (M) +312-375-5932
> >> 
> >> -----Original Message-----
> >> From: public-poiwg-request@w3.org [mailto:public-poiwg-request@w3.org] On Behalf Of Raj Singh
> >> Sent: Friday, September 30, 2011 1:22 PM
> >> To: roBman@mob-labs.com
> >> Cc: public-poiwg@w3.org
> >> Subject: Re: data model and example
> >> 
> >> On Sep 30, at 12:35 AM, Rob Manson wrote:
> >> 
> >>> Hey Raj,
> >>> 
> >>>> No. I wanted to specify the author, but I'm having trouble figuring
> >>>> out how to represent it. See:
> >>>> http://rajsingh.org/poiwg/poi_logan_2.xml
> >>> 
> >>> Yeah I think that's better.  I'd assume if <value> is not defined then
> >>> the full content is assumed to be the payload?
> >> 
> >> I suppose that's a possibility. It would look cleaner, but as a developer, I'd rather just always know to parse the <value> element as text, rather than have a conditional check to see if there are elements within <description>, and if not then treat <description> as text.
> >> 
> >>>>> Is the <point><Point>...</Point></point> double nesting needed?
> >>>> 
> >>>> Yes. Everything in <Point> is straight from GML 3.3. And the
> >>>> double-nesting will be useful. For one, it will avoid the problem with
> >>>> <description> above, where you don't want to mix CDATA with an
> >>>> element. I.e. it's easy to slip an <author> element in as a child of
> >>>> <point> without messing with the location specification in <Point>.
> >>> 
> >>> Fair enough.  I'd also like to be able to support the simpler geo:uri
> >>> too as a lot of developers would be happy with just that too.
> >> 
> >> At the face-to-face we decided to put a stake in the ground here and have a single way to represent a point. There are too many "pet" point formats around. It would be better in the long run for the world to focus on a single one for interoperability. And what better place to have the canonical one than the W3C POI spec? And for practical reasons, if you're generating POIs, writing <Point><posList> instead of geo:uri is the least of your problems! And as a consumer of POI data (at least the XML format), it's nice to always know to find the coordinates in the <posList> element.
> >> 
> >> 
> >> 
> >> The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above.  If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited.  If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
> > 
> > 
> > The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above.  If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited.  If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
> > <NVTPOI_03_01_5800_001 xml><NVTPOI_03_ZAF_9517_001 xml>
> 
> 
> The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.

Received on Monday, 3 October 2011 20:01:58 UTC