Re: RDFa DOM API: Adding RDF triples to the DOM

On 24 Feb 2010, at 13:16, Benjamin Adrian wrote:
>> I doubt the wisdom of having a addTriple in an RDFa DOM API.
>>
> What about adding DBpedia links to phrases inside web pages?
> e.g., linking DERI to  http://dbpedia.org/page/Digital_Enterprise_Research_Institute
>
> An annotator might transform the following sentence on a web page:
>
> "DERI, is an international network of independent  ...  " to
> <span about="http://dbpedia.org/page/Digital_Enterprise_Research_Institute 
> " property="foaf:name">DERI</span>
> is an international network of independent  ...
>
> Now, doing this manually is burdensome.

The burdensome part is wrapping “DERI” into a span. Adding the @about  
and @property to the span is easy. And wrapping some bit of text  
content into an element is not an RDFa-specific problem; it's the same  
if you, let's say, want every occurrence of the phrase “DERI” to be  
shown with a light green background.

I don't think that the RDFa WG should apply band-aids to shortcomings  
of the HTML DOM API.

I think the RDFa WG should focus on providing an API that allows  
developers access to embedded RDFa data without having to implement  
the full parsing algorithm in the RDFa spec.

Best,
Richard



>> Such an API should provide read access to the RDFa graph that is  
>> encoded, perhaps with some ways of restricting and setting scope  
>> (“give all triples in that div, give me all triples with that  
>> subject, give me the element that is @about that URI”).
>>
>> If you want to modify the graph, you should modify the DOM tree  
>> using standard DOM operations, and attribute accessors  
>> (el.about='#me', el.property='foaf:name' and such). This is simple  
>> and works.
>>
> I wrote algorithms for that and would have been glad to have any DOM  
> API RDFa support except the low level node transformations. Indeed  
> it is not that simple, especially in JavaScript.
>> If you want to modify the DOM tree by invoking graph-level  
>> modifications, then you hit a gigantic impedance mismatch, and you  
>> will end up designing a horrible, horrible kludge. Don't go there.  
>> No one needs this.
> Well, :) I need it. It would make life easier and encourages to  
> create links not only between datasets but also between data and  
> documents.
>
> So I think it's worth discussing here.
>>
>> Best,
>> Richard
>>
> Greetings,
>
> Ben
>>
>> On 24 Feb 2010, at 09:27, Benjamin Adrian wrote:
>>
>>> Hi
>>>
>>> I was thinking about new methods for adding RDF triples in the new  
>>> RDFa
>>> DOM API.
>>> As code example I took the example from Use Case #2 at
>>> http://www.w3.org/TR/xhtml-rdfa-scenarios/#use-case-2:
>>>
>>> <div id="www2007_talk">
>>>  <h2>My WWW2007 Talk</h2>
>>>  a post by Paul.
>>>  <p>
>>>      I'm giving a talk at the WWW2007 Conference about structured
>>> blogging,
>>>  on the second day of the conference at 10. This will be one of my
>>>  <a href="technical">more technical talks</a>.
>>>  </p>
>>> </div>
>>>
>>> desired RDF triples are:
>>>
>>> @prefix cal: <http://www.w3.org/2002/12/cal/ical#>
>>> @prefix dc: <http://purl.org/dc/elements/1.1/>
>>> @prefix paul: <http://example.org/Paul/ns#>
>>>
>>> <#www2007_talk> a cal:Vevent ;
>>>              dc:title "My WWW2007 Talk" ;
>>>              dc:creator "Paul" ;
>>>              cal:summary "structured blogging" ;
>>>              cal:dtstart "20070509T1000-0800" ;
>>>              paul:audience <technical> .
>>>
>>> Three API cases came to my mind:
>>> 1. Add single RDFa markup to single DOM elements.
>>> 2. Add chaining RDFa markup to a DOM subtree.
>>> 3. Add single RDFa markup to a literal phrase pattern.
>>>
>>>
>>> Let's begin with the first one.
>>>
>>> 1. Add single RDFa markup to single DOM elements.
>>>
>>> I tried to add the desired triples by just modifying single DOM  
>>> elements at
>>> once.
>>>
>>> <div id="www2007_talk">
>>>   <h2     about="www2007_talk"
>>>      property="dc:title"
>>>      typeof="cal:Vevent">
>>> My WWW2007 Talk</h2>
>>>  a post by Paul.
>>> <p about="www2007_talk" property="cal:dtstart"
>>> content="20070509T1000-0800">
>>>      I'm giving a talk at the WWW2007 Conference about structured
>>> blogging,
>>>  on the second day of the conference at 10. This will be one of my
>>>  <a     href="technical"
>>>      about="www2007_talk"
>>>      rel="paul:audience"
>>>      resource="technical" >more technical talks</a>.
>>> </p>
>>> </div>
>>>
>>> This might be solved by extending the DOM API methods as follows:
>>>
>>> interface Element {
>>> Triple    addTriple(
>>>      in DOMString? about,
>>>      in DOMString? rel,
>>>      in DOMString? resource)
>>>
>>> Triple    addTriple(
>>>      in DOMString? about,
>>>      in DOMString? property,
>>>      in DOMString? object,
>>>      in DOMString? datatype)
>>> }
>>>
>>> You might have recognized that I could not markup neither the  
>>> literals
>>> "Paul"
>>> nor "structured blogging" with triples. There are no DOM elements  
>>> to attach
>>> these triples.
>>>
>>> 2. Add chaining RDFa markup to a DOM subtree.
>>>
>>> Again I tried to attach all triples, but this time I used RDFa's
>>> chaining. This
>>> will produce less data as I can add about="www2007_talk" to the  
>>> root node of
>>> this subtree.
>>>
>>> <div id="www2007_talk" about="www2007_talk">
>>>   <h2     property="dc:title"
>>>      typeof="cal:Vevent">
>>> My WWW2007 Talk</h2>
>>>  a post by Paul.
>>> <p property="cal:dtstart" content="20070509T1000-0800">
>>>      I'm giving a talk at the WWW2007 Conference about structured
>>> blogging,
>>>  on the second day of the conference at 10. This will be one of my
>>>  <a     href="technical"
>>>      rel="paul:audience"
>>>      resource="technical" >more technical talks</a>.
>>> </p>
>>> </div>
>>>
>>> This might be solved by modifying the upper DOM API method  
>>> extension with
>>>
>>>
>>> interface Element {
>>>
>>> /*
>>> * If about, rel, and resource are null nothing happens.
>>> */
>>> Triple    addTriple(
>>>      in optional DOMString? about,
>>>      in optional DOMString? rel,
>>>      in optional DOMString? resource)
>>>
>>> /*
>>> * If about, rel, and resource are null nothing happens.
>>> */
>>> Triple    addTriple(
>>>      in optional DOMString? about,
>>>      in optional DOMString? property,
>>>      in optional DOMString? object,
>>>      in optional DOMString? datatype)
>>>
>>> Triple    addSubject(in DOMString? subject)
>>> Triple    addRelation(in DOMString? predicate)
>>> Triple    addProperty(in DOMString? predicate)
>>> Triple    addResource(in DOMString? object)
>>> Triple    addRDFLiteral(
>>>      in DOMString? object,
>>>      in optional DOMString? datatype)
>>> }
>>>
>>> The developer now has to call these method several times in order to
>>> annotate
>>> each node correctly. This is really annoying. A good API should be
>>> simpler and
>>> hide chaining to the programmer.
>>>
>>> A better approach would be extending DocumentFragment as this  
>>> intends to
>>> be a
>>> DOM subtree.
>>>
>>> interface DocumentFragment {
>>>
>>> /**
>>> * The about attribute will be added the DocumentFragment's root  
>>> node.
>>> * Whenever in descendants of DocumentFragment the resource value  
>>> matches
>>> * an existing about, href, or src attribute, the current node will  
>>> be
>>> annotated
>>> * with the rel attribute. If no matches occur, the  
>>> DocumentFragment's
>>> root node
>>> * is annotated.
>>> **/
>>> Triple    addTriple(
>>>      in DOMString? about,
>>>      in DOMString? rel,
>>>      in DOMString? resource)
>>>
>>> /**
>>> * The about attribute will be added the DocumentFragment's root  
>>> node.
>>> * Whenever in descendants of DocumentFragment the literal value  
>>> matches
>>> * an existing text node, the current node will be annotated
>>> * with the property attribute. If no matches occur, the
>>> DocumentFragment's root
>>> * node is annotated.
>>> **/
>>> Triple    addTriple(
>>>      in DOMString? about,
>>>      in DOMString? property,
>>>      in DOMString? literal,
>>>      in optional DOMString? datatype)
>>>
>>> }
>>>
>>>
>>> Again I could not markup "Paul" and "structured blogging" for the  
>>> same
>>> reason
>>> as in case one.
>>>
>>> 3. Add single RDFa markup to a literal phrase pattern.
>>>
>>> Now lets give the substrings "Paul" and "structured blogging" RDFa  
>>> markup.
>>>
>>> <div id="www2007_talk" about="www2007_talk">
>>>   <h2     property="dc:title"
>>>      typeof="cal:Vevent">
>>> My WWW2007 Talk</h2>
>>>  a post by <span rel="dc:creator" resource="Paul">Paul<span>.
>>> <p property="cal:dtstart" content="20070509T1000-0800">
>>>      I'm giving a talk at the WWW2007 Conference about <span
>>> property="cal:summary">structured blogging</span>,
>>>  on the second day of the conference at 10. This will be one of my
>>>  <a     href="technical"
>>>      rel="paul:audience"
>>>      resource="technical">more technical talks</a>.
>>> </p>
>>> </div>
>>>
>>> interface DocumentFragment {
>>>
>>> /**
>>> * The about attribute will be added the DocumentFragment's root  
>>> node.
>>> * Whenever in text nodes of descendants of DocumentFragment the  
>>> regexPattern
>>> * value matches, the current node's C parent P will get a new text  
>>> node as
>>> * child that contains the original text value before the match.  
>>> Then P will
>>> * get a new node of type nodetype or SPAN as default. This new node
>>> element is
>>> * annotated with attributes property and datatype. As text value  
>>> it gets the
>>> * string match. At last the string after the match will be  
>>> attached as new
>>> * child to P. C will be deleted. If no match happens, nothing  
>>> happens.
>>> **/
>>> Triple    addTripleForPattern(
>>>      in optional DOMString? about,
>>>      in DOMString? property,
>>>      in DOMString? regexPattern,
>>>      in optional DOMString? nodetype,
>>>      in optional DOMString? datatype)
>>> }
>>>
>>> I know this is difficult to implement. But it is a very powerful  
>>> method
>>> encouraging developers to automatically link keywords to e.g.,  
>>> Linked
>>> Data URIs.
>>> In Epiphany[1], we make use of such a method do do exactly this.
>>>
>>> So now I am ready for comments :).
>>>
>>> [1]http://projects.dfki.uni-kl.de/epiphany/
>>>
>>>
>>> -- 
>>> __________________________________________
>>> Benjamin Adrian
>>> Email : benjamin.adrian@dfki.de
>>> WWW : http://www.dfki.uni-kl.de/~adrian/
>>> Tel.: +49631 20575 145
>>> __________________________________________
>>> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
>>> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
>>> Geschäftsführung:
>>> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr.  
>>> Walter Olthoff
>>> Vorsitzender des Aufsichtsrats:
>>> Prof. Dr. h.c. Hans A. Aukes
>>> Amtsgericht Kaiserslautern, HRB 2313
>>> __________________________________________
>>>
>>>
>>>
>>
>>
>
>
> -- 
> __________________________________________
> Benjamin Adrian
> Email : benjamin.adrian@dfki.de
> WWW : http://www.dfki.uni-kl.de/~adrian/
> Tel.: +49631 20575 145
> __________________________________________
> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschäftsführung:
> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter  
> Olthoff
> Vorsitzender des Aufsichtsrats:
> Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> __________________________________________
>

Received on Wednesday, 24 February 2010 14:29:19 UTC