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

Hey Karl,

yep...the samples I've mapped out are just one overly simple example
expressed in different forms.  I think you could definitely do the type
of version/provenance tracking you describe by adding links for this.
For example in the html5 embedded example you could add a version
history and author link right down to the individual field.

This simple field...

  <span itemprop="description">This is an individual poi</span>

...would become something like this...

  <span itemprop="description">
    <link itemprop="version-history" href="http://mob-labs.com/poiwg/example01/pois/123/location/version-history">
    <link itemprop="author" href="http://mob-labs.com">
    This is an individual poi
  </span>

The same works at the poi level too etc.

See the list of link rel types I listed at the top of the document that
I think would be worth exploring further...and please add to this if you
think any of the others in the IANA list are relevant too.

I think payment is definitely an interesting one 8)

BTW: Now that I look at it again some of the structure in the json and
html5 embedded examples still don't seem quite right to me.  e.g. the
html5 embedded version is kinda missing the location block 8(  I'll work
on refining these a little further.


roBman



On Fri, 2011-09-23 at 08:06 -0500, Seiler, Karl wrote:
> 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.
> http://www.w3.org/2010/POI/wiki/Data_Model_Examples
> 
> 
> roBman
> 
> 
> 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:32:03 UTC