Re: Some thoughts on the RDFa DOM API document

Benjamin Adrian wrote:
> Good to see that the discussion becomes more lively.
>
>>   1. Rather than defer to RDF-CONCEPTS for the definition of a language
>>      tag, I think we should refer to IETF BCP 47 - that's what the I18N
>>      WG likes people to use these days.
> The RDFa DOM API makes no use of Exceptions, yet.
> Should an implementation check if the language tag is valid
> and throw an Exception if it is not?
No.
>
>
> 2. I assume that the designation of BlankNodes are constant for the
> >     lifetime of a specific document instance.  In otherwords, if I
> >     process a page and start using it, depending upon blank node names
> >     like '_:123' , that designator will refer to the same node at
> >     least until the next time the page is processed.  We should make
> >     this explicit if it is true.
> >
>
>> If I understand well what you say then I think I disagree. So here is 
>> how I understand: if I look at an RDFa page today and run a 
>> javascript with the API and I get _:123 as an identifier for a 
>> particular bnode, is it true that if I run the same javascript on the 
>> same page tomorrow, will I get _:123 as an identifier for the same 
>> bnode? If this is what you ask then my answer is no. There is 
>> absolutely no reason for that, _:123 is not a stable and permanent 
>> identifier for a node, it is only a temporary identifier at a 
>> particular run. It is a perfectly valid implementation of bnodes to 
>> use random identifiers, with the only requirement that two different 
>> bnodes should have different identifiers. (In fact, RDFLib explicitly 
>> runs a random generator to generate a bnode id to avoid giving the 
>> false impression that these are stable ID-s.) 
>
> For not confusing developers with RDF internal definition,
> I would say a pragmatic solution would cover the following Blank Node 
> management:
> - If two or more documents are processed with the RDFa DOM API,
>  it has to be assured that comparing Blank Nodes from different documents
>  never result true. (this means, the Node document has to be an part 
> of the comparision)
> - Blank Nodes from a single document should preserve the same ID as 
> used in the document.
>  If no ID is given or exists, a unique number is generated as ID.

Agreed.  However, that unique number would be persistent for the life of 
the current document.rdfa object, right?

>
>>   3. PlainLiteral and TypedLiteral return both a Node (in element) and
>>      the Node contents (in value).  RDFa requires that value of a
>>      Literal be extracted in a pretty special way.  We should probably
>>      indicate that the 'value' reflects the result of extracting the
>>      Literal from the DOM.  In other words, that it is very different
>>      than just looking at the content of the Node reflected by element.
> (Plain|Typed)Literal.value is designed to represent the String 
> representation of a literal.
> 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?

>>
>>   5. I confess that I don't understand the URI Mapping stuff.  In RDFa
>>      URI mappings are done in the context of a Node.  It doesn't make
>>      any sense to me to have a global mapping class.  I know that
>>      people don't generally override the mappings throughout a
>>      document, but still... they could, and I don't see what value
>>      having global mappings has?
> URI mappings are just convenient for using URIs of
> common vocabularies  in source code.
>
> Your confusion indicates that the label "URI mapping" is ambiguous.
> I think about a better one.

Thanks
>
>>   6. RDFTriple has a complex constructor definition.  However, what I
>>      don't see in there is the ability to use a BlankNode as a
>>      predicate.  Within the context of a single document, I think it is
>>      perfectly reasonable to define a hybrid type as a BlankNode and
>>      then cite it as a predicate for other triples.  Isn't it?
> Blank Nodes as predicates? This is not allowed in RDF. (see definition 
> in http://www.w3.org/TR/rdf-concepts/#section-triples)

Really?  Ok, never mind then.

>>   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.

>
>>
>>   9. In section 3.2 and 3.3, the predicate in the various method is
>>      limited to a URI.  Can't it also be a bnode (see above)?  Also,
>>      and I know this contradicts what I said above about prefix
>>      mappings, it would be nice to be able to filter using CURIEs as
>>      well as URIs.
>>
> Predicates can't be Blank Nodes.

OK



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

Received on Tuesday, 27 April 2010 12:39:25 UTC