W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2010

Re: RDFa API - uniting bnode, uri and projected objects

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Thu, 29 Apr 2010 01:46:06 -0400
Message-ID: <4BD91D1E.50702@digitalbazaar.com>
To: public-rdfa-wg@w3.org
On 04/27/2010 04:23 AM, Toby Inkster wrote:
> This is a proposal to create a superclass of blank nodes and URI
> references; and provide some extra methods and attributes on this
> superclass to make the current Projection interface unneeded.

Unfortunately, the Projection interface is a failed attempt at trying to
integrate Mark's concepts into the RDFa DOM API. Benjamin and I thought
we had captured most of what he wanted, but the latest e-mail from him
notes that we may have missed much of what he was attempting to convey.

In short, I think we need to discuss this more after the FPWD is out. I
expect that the Projection interface will change quite a bit over the
next month and this proposal and Mark's proposal should be explained in
a bit more detail so that we can capture it correctly in the RDFa DOM
API spec.

> For want of a better term, I'll call this superclass "Resource" as
> it's analogous to an rdfs:Resource.
> interface Resource {
>   readonly attribute DOMString value;
>   readonly attribute Node element;
>   readonly attribute Sequence[URI] properties;
>   [NameGetter] Sequence[any] get (in DOMString name);
> }
> The rdfa.extractObject/rdfa.project method would no longer be needed.

First thing that pops to mind is that this will be quite the CPU hog to
implement. Note that the 'properties' attribute has to be built for
/every/ triple extracted from the document. This would turn the average
case of processing each triple in the document via RDFTripleIterator or
RDFTripleList into a quadratic time algorithm (n^2) if you don't store
triples by subject in a hashtable-based cache (which is memory intensive).

One of the design goals of projection was to not require the time hit if
you are doing something like search through the set of triples. The same
holds for RDFTripleIterator. If we adopt the mechanism described above,
we lose the less CPU and memory intensive solutions in RDFTripleIterator
and RDFTripleList.

Is that accurate, or did I miss something?

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarming Goes Open Source
Received on Thursday, 29 April 2010 05:59:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:47 UTC