Re: an alternative for microformat-like simplicity

Manu Sporny wrote:
> Things of importance regarding Ben's proposal:
> ... 
> Things of importance regarding Mark's proposal:
> ...

If we look at purely the @profile aspect of this issue, there most
important question to answer is "At which layer does the processing occur?":

        +----------------------+
        | Application Layer    |
        +----------------------+
        | RDFa Processor Layer |
        +----------------------+
        | Document/Tree Layer  |
        +----------------------+

If we look at the problem holistically, it really doesn't matter - the
same amount of work has to be done with either approach. We're just
pushing failure further up (Ben's proposal) or further down (Mark's
proposal) on the DOM-processor-application stack.

To get the triples that we want, in both cases, the system has to:

1. Dereference the @profile document.
2. Extract meaning from the @profile document.
3. Process the page's triples accordingly.

Ben's proposal is concerned about not having to dereference anything
during the RDFa processor stage because it leads to complexity and the
possibility of not generating triples at parse-time. However, I'm not so
sure that this fixes the dereferencing problem, or even if that is as
bad of a problem as we seem to think.

For example, say I'm on a music blog and I've just extracted a number of
triples from the page about some songs. I'm doing this in Firefox with
an extension that will glean music information from pages and display
them to me so I can remember albums that I've looked at recently.

However, in order to do this, the plugin must detect a couple of very
specific triples from a specific vocabulary. If the plugin cannot
dereference the @profile document at the moment it reads the page, its
going to have a very hard time generating a browser UI for the music
it's detected on the page. The RDFa short-hand in the page becomes
fairly useless at that point.

This problem happens with either approach. The one benefit with Ben's
approach is that the triples could be stored and dereferencing the
document could occur at a different time (when the document is available).

This is, however, a detectable error. Whatever layer that ends up doing
the processing is going to kick out an error when it can't dereference
the document. In both cases, the triples are fairly useless until the
document can be dereferenced. In both cases, /something/ can be cached
or noted until the @profile document can be dereferenced.

I'm not sure if we should be so concerned if dereferencing a document
ends up with triples not being generated at certain points in time. This
is the web, after all, things break often - changing sites, layouts, and
even page meaning.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

Received on Wednesday, 29 July 2009 04:49:35 UTC