W3C home > Mailing lists > Public > public-poiwg@w3.org > September 2011

RE: POI data model examples serialised as JSON, XML, HTML5 & KML

From: Seiler, Karl <karl.seiler@navteq.com>
Date: Fri, 23 Sep 2011 08:06:08 -0500
To: "roBman@mob-labs.com" <roBman@mob-labs.com>, "public-poiwg@w3.org" <public-poiwg@w3.org>
Message-ID: <133ACBBC61BE0E4081B6E35E542ECE230EBADC09@hq-ex-mb03.ad.navteq.com>
Please note we want to be able to apply change tracking, ownership, rights attribution optionally at the POI package/bundle, individual POI and POI element/attribute levels of specificity.

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 Rob Manson
Sent: Thursday, September 22, 2011 9:45 PM
To: public-poiwg@w3.org
Subject: Re: POI data model examples serialised as JSON, XML, HTML5 & KML

I've copied these examples to a new page on the wiki.


On Fri, 2011-09-23 at 03:15 +1000, Rob Manson wrote:
> Hey Raj,
> > First of all, kudos for stepping forward with examples. Very brave!
> it's just the rough output of me trying to think through all the details
> we discussed and I'm very happy to receive constructive criticism...like
> yours below 8)
> > - can you put it on the wiki so we can all edit?
> Yeah...will do.  Just wanted to get a first round of feedback first and
> didn't want to interfere with the examples I think matt is going to put
> up from Boulder.  But short answer is yes...definitely.
> > - this whole idea of pointing to alternate versions of the same thing
> > is starting to worry me. This is functionality that seems better
> > suited to a service interface/negotiation and not something that
> > should be encoded in the file.
> Do you mean the serialisation type?  e.g. xml or json, etc.
> This is definitely one of the key points I'd like to discuss further.  I
> think you're absolutely right about content-type negotiation.  HTTP
> Headers, User Agents and Servers are best at handling that.
> I probably erred too much on the side of being explicit here.
> > - you have different IDs in each format. Shouldn't the ID be the same
> > and the href change? So the POI is should be
> > http://mob-labs.com/poiwg/example01/pois/123 and the href for the XML
> > encoding would be http://mob-labs.com/poiwg/example01/pois/123.xml,

> > and the href for JSON would be
> > http://mob-labs.com/poiwg/example01/pois/123.json, etc.
> Yeah...I think that's a great point and relates directly to the point
> above.  Also see the note I put in there about Atom requiring that an id
> is a permalink/URI and not just a relative id.
> > - you have a lot of Atom elements at the POIS object level that we
> > haven't discussed. I like it but not sure that's the group consensus
> Yeah...I thought some of them might be a bit contentious 8)
> I started with the UML data model diagram you did...but when I got to
> things like "label" it didn't seem to map cleanly to the existing
> conventions in Atom, Dublin Core or KML.  So I just followed each of
> these points through to try to pull out the key metadata fields that are
> common across all these different specs.  Where they weren't completely
> common I went with the most popular one e.g. author vs creator.
> In this vein I'd also like to discuss atom:category and link rel=tag in
> more detail too.
> But my goal with this is really just to stir up a bit more discussion at
> this detail level based on the existing specs and very happy to learn
> more about what's already been agreed by the broader group.
> In this I also promoted a lot of these up out of a metadata block into
> the top level...but happy to discuss this further too.
> > - JSON: the POI object has gone away. So you just have the array POIS.
> > I see what you're doing and that this array-style format doesn't need
> > the POI object, but it doesn't "feel right" to me.
> Well...each of the {...} objects inside the pois array is really a poi
> object.  I did have a {type:poi} key in there initially but it seemed a
> bit redundant.  Happy to add that back in if people think this is
> useful...but I think having any type other than "poi" inside a pois
> array would be a bit strange 8)
> roBman

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 Friday, 23 September 2011 13:06:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:22 UTC