Re: Directions of the RDFa DOM API

Hi Ivan,

> I have a comment on the DOM interface on the wiki. I am little bit
> bothered by the fact that you mix the triple as a unit and the fact that
> an object/subject/predicate is a bnode, a literal etc. I would expect
> some sort of a hierarchy (forgive me, I am not sure how exactly to put
> this into Javascript syntax):
>
> Resource
>   !
>   ---> Literal
>   ---> BNode
>   ---> URIRef
>
> and then use Resource for subject/object/predicate in RDFTriple
>
>   
Yes, I know what you mean and already tried to mention that in the wiki.
The more that I think about this, the more I agree to use such a type 
hierarchy.

Resource
-> BlankNode
-> IRI
-> PlainLteral,
-> TypedLiteral.

My first thought was that such a hierarchy might be too much for this API,
but I had a closer look into  DOM Level 2.
There is also the hierarchy starting from:

Node
-> Element
-> CharacterData
   -> Text
...
So a Resource Hierarchy might be conform to the existing DOM API style.
> I must admit that I am influenced by the way RDFLib does thing in Python...
>
>   
This influence is a good one. I really love this API. ;)

Best regards,

Ben
> Ivan
>
> On 2010-3-10 15:17 , Benjamin Adrian wrote:
>   
>> Hello,
>>
>> As it's my turn to give you some information about the RDFa DOM API
>> direction tomorrow, I'll tell you the current status.
>>
>> First questions I tried to answer were:
>>
>> Q1: Why to have an RDFa DOM API if there are plenty of RDFa parsers and
>>    libraries out there?
>> A1: The RDFa DOM API is a chance to hide complex language constructs in
>> RDFa to
>>    application developers
>>    To understand what's really complex in handling RDFa, I looked into
>> source
>>    code from:
>>   * librdfa (C)
>>   * pyRdfa-2.3.7 (Python)
>>   * rdflib::RDFaParser (Python)
>>   * RDFaParser (Java, uses XSLT)
>>   * rdfquery (JavaScript)
>>   * Operator (JavaScript, Firefox Plugin, uses XPath)
>>
>>   My conclusions are:
>>   1. Developers spent most lines of code to filter DOM elements for
>> specific
>>      attributes that may contain RDFa content. A DOM extension would remove
>>      this effort.
>>   2. RDFa chaining forces RDFa Parsers developers to implement recursion or
>>      use a pushdown automaton.
>>   3. A DOM API could not only extract RDF triple from DOM nodes, but may
>>      also find DOM nodes with specific RDF content. This may be used for
>>      highlighting elements with RDFa content as done by Operator.
>>   4. The option to use either URIs or CURIES in RDFa code should be
>> hidden by
>>      the RDFa DOM API.
>>   5. In RDFa 1.1. Users may define external vocabulary definitions (either
>>      vocab or profile). Again the RDFa DOM API should hide this.
>>
>> Q2: What should be the focus of this API?
>> A2: 1. Extract RDF triples from RDFa annotated HTML5 and XHTML pages.
>>    2. Query for RDFa enhanced DOM elements with RDF triple patterns.
>>    (3. Add RDF triples as RDFa to DOM?) [3]
>>    (4. Remove RDF triples as RDFa to DOM?)
>>
>> Q3: Where is the cut between RDFa DOM API and RDF Triple Store API (Knut)?
>> A3: The RDFa DOM API allows developers to use RDF triples inside the
>> DOM. It is
>>    a rather low level API, whether the Triple Store API is set one level
>>    higher. This Triple Store API may be implemented based on the RDFa
>> DOM API
>>    and allow operations such as query the web page with SPARQL, and store
>>    extracted triples to allow inferencing.
>>
>> Q4: What functionalities should be provided by the RDFa DOM API?
>> A4: The API should be designed by analysing the following tradeoff:
>>    "Less programming effort for browser developers versus lightwight API
>> for
>>     application developers."
>>     => means: a few API methods that cover all use cases
>>     => RDFa DOM API feeling should preserve the DOM feeling
>>
>> Q5: What concrete functions should be offered?
>> A5: I set up a wiki page [1] with a Web IDL draft specification. Please
>>    conside that it is not complete and in parts a bit simplified. We can
>> use
>>    this as base for discussion.
>>
>> Q6: Are there any Code Snippets showing us that the use of the specified
>> API
>>    is efficient wrt. spent lines of code?
>> A6: Yes one :), I added a section at [2]. More will follow. Please also add
>>    code that shows weaknesses of the current specification.
>>
>> So much for now. Please let me know if you agree, disagree or think I
>> misunderstood some things.
>>
>> Best regards,
>>
>> Benjamin
>>
>> [1] http://www.w3.org/2010/02/rdfa/wiki/RDFa-DOM-API
>> [2] http://www.w3.org/2010/02/rdfa/wiki/RDFa-DOM-API#Code_Snippets
>> [3] You may read discussion about this in thread:
>> http://lists.w3.org/Archives/Public/public-rdfa/2010Feb/0031.html
>>
>>     
>
>   


-- 
__________________________________________
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 Thursday, 11 March 2010 13:18:37 UTC