Re: Proposal: The "POI as a simple collection of links" data model

Hey Raj,

good point about "time".  I didn't handle that at all.
Having primitives for that would make sense to me.  
Although it could also be handled with <meta> tags.

Some key items like <label> wouldn't be too bad either.  Although using
<meta> is valid for that too.

The data: uri part isn't a strong recommendation.  Just an option for
serialisation that already exists in this type of external link model
(e.g. in html5).


roBman


On Thu, 2011-08-04 at 09:56 -0400, Raj Singh wrote:
> 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 14:02:11 UTC