Re: Some thoughts on the RDFa DOM API document

Manu Sporny wrote:
> On 04/27/2010 08:38 AM, Shane McCarron wrote:
>   
>>> So I would propose to set
>>>
>>> (Plain|Typed)Literal.value := (Plain|Typed)Literal.element.nodeValue
>>> This solves Manu's example:
>>>
>>> <div property="ex:name" datatype="">Shane <em>halindrome</em>
>>> McCarron</div>
>>>
>>> gives this triple:
>>>
>>> <> ex:name "Shane halindrome McCarron" .
>>>       
>> Yes.  And citing Manu's item about the node that defines this.... isn't
>> it the div?
>>     
>
> Err, this doesn't work, does it? The element.nodeValue for the <div> is
> always going to return NULL in DOM Level 2? There are four nodes in that
> <div> - three Text nodes ("Shane ", "halindrome", and " McCarron" and
> one Element node "<em>...</em>".
>
> http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-F68D080
>
>   
>   

Well... the value is the value as comes from the RDFa Processor.  But 
the Node is properly the enclosing Node in my opinion.  There is not a 
direct mapping from the Node.nodeValue to the RDFLiteral.value 
property.  That's okay.  It's why I raised this in the first place.

>   
>>>>   7. In the RDF Triple Iterator, if I specify a root attribute that is
>>>>      some Node in the tree, and the triples in that hierarchy refer to
>>>>      other triples outside of the hierarchy...  I assume its all fine,
>>>>      but it is not clear to me how I would follow that chain.
>>>>         
>>> Can you give an example Shane?
>>> If you mean that the iterated hierarchy of DOM nodes starts inside an
>>> RDFa chain,
>>> I would propose to generate BlankNodes for incomplete triples with
>>> missing subjects .
>>>       
>> I had assumed that.  When I reviewed the text I was worried that the
>> processor was being invoked on the tree.  However, I think now that the
>> processor is only invoked once, and that the API operates on the output
>> of the processor.  If that is true, then I am happy.
>>     
>
> The processor is not necessarily invoked only once. In the case of an
> RDFTripleIterator, Benjamin and I had discussed that an implementer that
> is concerned about memory usage could use the RDFTripleIterator to
> "stream" triples to the developer and thus cut down on memory usage.
>
> For example, if you have a document with over a million triples, and you
> want to process it on hardware that doesn't have a great deal of working
> memory (like a cell phone), one could eschew the use of rdfa.filter()
> and rdfa.projection() and instead rely solely on rdfa.iterate().
>   

Hmm....  I consider the API to be a consumer of the output of an RDFa 
Processor.  I can see how they might be coupled in a real 
implementation, but logically they have to be separate.  Otherwise the 
tool chain won't work right.  Moreover, RDFa Core clearly says that the 
processing of a document fragment is unspecified.  That's on purpose.  A 
fragment out of context will almost NEVER get the right triples.  You 
won't even know what the prefix mappings are necessarily.

> -- manu
>
>   

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com