- From: Raj Singh <rsingh@opengeospatial.org>
- Date: Thu, 4 Aug 2011 09:56:23 -0400
- To: roBman@mob-labs.com
- Cc: "public-poiwg@w3.org" <public-poiwg@w3.org>
I love the "POI as a simple collection of links" data model in theory. It's very clean conceptually, and that's the way I've been thinking of the larger POI "picture" also. However, I don't think it's the best way to implement. I think we still need a few primitives. The only things that are in the model now that don't fit your links model are the label, some time fields, and the location. The label and the time fields are so natural to just stick in there. That brings us to location. The data URI seems awkward to me and likely to turn people off of the spec. However, I'm open to other opinions. --- Raj The OGC: Making location count... http://www.opengeospatial.org/contact On Aug 3, at 10:23 PM, Rob Manson wrote: > Hi, > > based on the discussion on last weeks conference call I've spent quite a > bit of time looking into all the different uses of links. From the > seminal <a> link with an href that kicked off the whole web. Through to > the latest definition of the <link> element in the html5 spec. And > through the linked data communities ongoing evolution of concepts, etc. > > After absorbing all of this as best I can, I'd like to make the > following proposal for a slightly refined approach to the current data > model proposed in the PWD. > > Proposal: The "POI as a simple collection of links" data model > > Imagine a POI was just a way of linking (binding or anchoring) digital > content and data to a specific location. This would provide the > conceptual data model for a POI. Basically it's just a collection of > links, with at least one location link. > > Relevant information: > http://tools.ietf.org/html/rfc5988 > http://www.iana.org/assignments/link-relations/link-relations.xml > > > Based on this conceptual model POIs could then utilise 3 related data > serialisation models. > > - basic external link > - external link with data uri content > - external link with inline content > > Here's a more detailed description of these different serialisation > models. > > basic external link > > <link rel="thing" href="url_to_canonical_source_for_thing_stuff"></link> > > > external link with data uri content > > <link rel="thing" href="data:...binary-or-text-thing-stuff..."></link> > > > external link with inline content > > <link rel="thing" href="url_to_canonical_source_for_thing_stuff"> > serialised inline thing stuff goes here > </link> > > NOTE: I know the html5 spec defines the link tag as having no > end tag. However, the general spirit of tags with entities, > attributes and payload could be used as above to allow a system > to optionally include pre-rendered content inline within the > link itself. This has also been used in KML/GML. The href > would still point to the source of truth for this data...but the > inline content could be used to reduce the number of nested > network connections required. However, instead of the > "either/or" model commonly used in <script> tags. I think it > would be good to encourage the href to always be included except > where a data: uri is used so the original source of the content > is always known. > > Taking this model to it's logical conclusion you could model "pois" as a > collection of "poi" objects. Each "poi" object is a collection of links > with at least one link to a location. > > It would also be sensible to allow the crs to be defined at the pois and > location levels so multiple contexts can be easily integrated. At the > pois level you are setting the default crs for the entire collection. > At the location level you are defining it for that specific instance. > > <pois crs="..." href="url"> > <meta name="keywords" content="top,level,metadata,values,go,here"> > <link rel="stylesheet" href="generic_pois_style_url"></link> > <script type="application/javascript" src="top_level_script_url"></script> > <poi href="data:....ascii-or-binary..."> > <meta name="keywords" content="poi,specific,values,go,here"> > <link rel="stylesheet" href="specific_poi_style_url"></link> > <script type="application/javascript" src="poi_specific_script_url"></script> > <link crs="wgs84" rel="location" href="url_to_location"> > <latitude>xx.xx</latitude> <-- possibly better as attributes on the link? see last poi > <longitude>xx.xx</longitude> > <altitude>xx.xx</altitude> > </link> > <link rel="alternate" href="..." type="model/collada+xml"> > <rotation></rotation> <-- possibly better as attributes on the link? > <scale></scale> > <translation></translation> > </link> > </poi> > <poi href="url_to_poi"> > <meta name="keywords" content="poi,specific,values,go,here"> > <link rel="stylesheet" href="specific_poi_style_url"></link> > <script type="application/javascript" src="poi_specific_script_url"></script> > <link crs="wgs84" rel="location" href="geo:xx.xx,yy.yy,aa.aa"></link> > <link rel="alternate" href="..." type="image/jpeg"></link> > </poi> > <poi href="url_to_poi"> > <link crs="wgs84" rel="location" href="url_to_location" latitude="42.36" longitude="-71.09"></link> > <link rel="alternate" href="url_to_geometry_definition" type="application/geo+json"></link> > </poi> > </pois> > > A new rel type of "location" would then need to be proposed to IANA. > However, using the link model we could be very flexible and allow a > number of ways for this could be encoded e.g. > - inline tags (e.g. <latitude>xx.xx</latitude>) > - geo url (e.g. http://tools.ietf.org/html/rfc5870 ) > - tag attributes (e.g. latitude="xx.xx" ) > > However, keeping in mind the simple goal of this model...ALL other > information (e.g. other geometries, etc.) would be modelled as external > links (see the rel="alternate" geojson example above). > > It's also interesting to note that a draft for doing this type of basic > linking at the HTML document level has already been developed through > the IETF (last modified in 2008). > > http://tools.ietf.org/html/draft-daviel-html-geo-tag-08 > > > This combined with the basic html5 document model would allow the use of > link and meta tags to achieve much of what is laid out above. Except > for one key point. It implies one document linked to one geo location. > Effectively making one page into one poi. I think this is too limited. > > The pois/poi model outlined above takes this model and allows multiple > entities, each with their own location to be serialised into a single > data model. So at the top "pois" level the collection behaves much as > an HTML document does at the <html> tag level supporting link, meta and > script tags. But this behaviour has then also been enabled at the > individual "poi" level allowing each individual "poi" to also use link, > meta and script tags. > > There's a number of other things that could be explored. e.g. should the > "pois" collection also be segmented into a <head> and <body> block in a > similar way to <html> documents? > > But this cut down version of a "poi as a collection of links, with at > least one location link" should enable all the requirements covered by > the current PWD. But it should also allow any other type of arbitrary > relationship to be linked to this location based poi in an open ended > way. > > I think the use of the <meta> tag would alleviate the need for a new rel > type of "metadata" needing to be proposed to IANA. And then the > existing rel type of "alternate" could be used to bind any number of 3d > objects, other geometries, etc. to a poi. And the existing "media" > query model would allow this to be targeted to specific user agents too. > > This is obviously a very quick and dirty proposal that just lays out the > key tweaks...but I think it's definitely worth discussing further. > > If this model were adopted it would then allow the development of the > different profiles (e.g. AR profile) to be developed independently in > parallel as it's essentially then just a link/rel/type classification > challenge that should not impact this simple underlying data model in > any way. > > > roBman > >
Received on Thursday, 4 August 2011 13:56:49 UTC