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

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