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

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 02:24:01 UTC