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

Re: RDFa DOM API Document update

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Tue, 18 May 2010 23:25:53 +0100
Message-ID: <AANLkTimcf_9_LzmOBfnyhQ7qL5NsjyyDFkGOhT6V4171@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: RDFa WG <public-rdfa-wg@w3.org>
HI Manu/Toby,

This is exactly how it's implemented in my parser.

The rule is essentially that at the moment the parser generates a
triple, it should store alongside that triple a reference to the
current DOM element that it is processing.

Doing this has the effect of keeping track of all of the *objects* in
the tree (in the RDF sense of objects, not the OO sense), because it's
always objects that cause triples to be generated. (@typeof is not an
exception -- it just happens to be an abbreviation for a
predicate/object pair.)

Keeping track of objects turns out to be exactly what we want when
dealing with DOM+RDFa, because now you can highlight names, put
tooltips on objects, and so on.



On Tue, May 18, 2010 at 11:14 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> On 05/17/2010 03:17 AM, Toby Inkster wrote:
>> On Sun, 16 May 2010 21:50:18 -0400
>> Manu Sporny <msporny@digitalbazaar.com> wrote:
>>> http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/Overview-src.html
>> How exactly do these getElementsByX methods work? Although RDFa defines
>> how to generate an RDF graph from a DOM tree, it doesn't offer a clear
>> and unambiguous mapping back from the RDF graph to DOM nodes.
> Right, we'd have to specify how that mapping happens.
> I was thinking about something along these lines:
> * The active DOM node is carried along with the context
> * When a subject, predicate or object starts to be generated, the
>  currently active DOM node is associated with the subject, predicate
>  or object being created.
>> For example:
>>       <a about="#me" typeof="foaf:Person"
>>            rel="foaf:homepage" href="http://example.com/">
>>         <span rel="rdf:type" resource="[foaf:Document]"
>>            property="dc:title">My Homepage</span>
>>       </a>
>>       <i about="#me" property="foaf:name">Joe</i>
>> What element would be returned in the case of
>> getElementsByType('foaf:Person')? Presumably the <a> element because it
>> set the subject for the {?thing rdf:type foaf:Person} triple.
> Yes, it would be where the @typeof is specified - or rather, the subject
> ("#me"), the predicate (rdf:type), and the object (foaf:Person) would
> all have the same ".origin" property - the <a> Element.
>> But what about the getElementsByType('foaf:Document')? If we apply the
>> same reasoning, it would be the <a> element too.
> Well, if we apply the "currently active node" rule for determining the
> associated DOM Node, it would be the currently active node when the
> object was determined, in this case, the <span> tag. So the triple's DOM
> Node associations would be:
> subject   -> "#me"         -> <a>
> predicate -> rdf:type      -> <span>
> object    -> foaf:Document -> <span>
>> Would the <i> element be selected by getElementsByType('foaf:Person')?
>> After all, we know #me is a foaf:Person.
> Nope, getElementsByType() only returns DOM Elements that are directly
> associated with the declaration of that type. So, only these patterns
> would match:
> @typeof
> @rel w/ @src/@href/@resource
> Even when we get fancy, I think this works:
> <div rel="rdf:type">
>   <span resource="foaf:Document" />
>   <span resource="sioc:Post" />
>   <span resource="owl:Thing" />
> </div>
> In each case about getElementsByType() would return the associated span
> element for foaf:Document, sioc:Post, and owl:Thing.
>> As much as I think these getElementsByX methods would be useful, I
>> don't think they can be implemented in an especially obvious,
>> consistent and predictable way.
> Does this approach change your mind? It's a fairly simple rule, can you
> think of where it may break down?
> -- manu
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Bitmunk 3.2.2 - Good Relations and Ditching Apache+PHP
> http://blog.digitalbazaar.com/2010/05/06/bitmunk-3-2-2/2/
Received on Tuesday, 18 May 2010 22:26:28 UTC

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