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

Received on Friday, 23 September 2011 02:45:47 UTC