Re: Directions of the RDFa DOM API

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

I must admit that I am influenced by the way RDFLib does thing in Python...

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
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf