Directions of the RDFa DOM API

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 Wednesday, 10 March 2010 14:18:22 UTC