Re: ISSUE-29: Re: When is equal and when is it nonequal (eg, the IRI interface)

Hi Nathan,

> I'll ask again - does anybody actually have a use case for needing the
> origin's at all?

This whole technique is based on my own JavaScript parser, but in that
I don't return a DOM node for each object type -- instead I return a
single DOM node per projection, allowing the author to choose which
triple should supply that node.

What this means is that the DOM node comes back in a property group,
just like any other property:

  [
    {
      "name": "Toby Inkster",
      "homepage", "http://tobyinkster.co.uk/#i",
      "user: /* pointer to a DOM node */
    }
  ]

With this I can turn Toby's name into a link to his home-page by
manipulating the DOM node, using the data provided in the projection.

It's not a great example, since there was probably already a link in
the page in the first place! But I have a ton of examples which use
this technique to embed additional data into a page either inline (the
cover of a book from Amazon, an embedded Google map of an address, a
person's latest Tweets) or as tooltips (the structure of a chemical
compound, a chart of a stock, a geocoded version of an address).

So, in my view there are many use-cases for getting back the DOM node,
and what I'd like to do is slightly refocus the discussion on whether
we need to know the DOM node of every single piece of information, or
whether we can 'get by' with one DOM node per projection.

In all of the use-cases I've been experimenting with, I've only ever
needed one DOM node per projection. Since this node can be any DOM
node that generated a triple, it still gives a lot of power. When
querying for people you can choose whether the property points to the
DOM node that bears the @typeof (so that you can change the background
colour of all 'people') or the person's name (so that you can add a
tooltip which contains the person's avatar).

Of course, to do both would require two queries, so you might argue
that we need more than one DOM node per projection. But again in my
experience you end up with a much tighter programming model if you run
query/callback function combinations that do something quite precise
-- such as change the background colour, or add an avatar -- rather
than return a ton of information and then use lots of JavaScript to do
many things at the same time with that information.

Anyway, to sum up...my vote is for the DOM node to only be provided as
part of the projection routines, and not with every single part of a
triple. If we find we need more than one DOM node in a projection then
we can certainly look at that, but that's separate -- by limiting the
DOM node to projections we are able to leave the objects for IRI,
literal, triple, and so on as 'clean' as possible.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Thursday, 5 August 2010 09:01:05 UTC