RDFa DOM API Editors Draft

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RDFa DOM API Editors Draft

Manu Sporny
I had an action to create and publish a skeleton document for the RDFa
DOM API:

http://dev.w3.org/rdfa/specs/rdfa-dom-api.html

The content of the document has not been discussed prior to publishing,
nor should anybody expect it to be the approach that the group will take
in the coming months. I was mostly just playing around with ReSpec to
see if it has the facilities that we will need as we define the
interface for the DOM.

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.2.1 Released - Video and Data Sales
http://blog.digitalbazaar.com/2010/01/31/bitmunk-3-2-1/

Reply | Threaded
Open this post in threaded view
|

Re: RDFa DOM API Editors Draft

Michael Hausenblas
Manu,

> I had an action to create and publish a skeleton document for the RDFa
> DOM API:
>
> http://dev.w3.org/rdfa/specs/rdfa-dom-api.html

Good job. Some comments: as a fairly heavy user of Jeni's wonderful rdfquery
lib [1] I like the way I can extract the RDFa embedded in an element with
@id="ex1" just by saying:

$('#ex1').rdf()

Further, executing a query against triples extracted from a block (ideally
making it compatible with SPARQ 1.1 esp. re aggregates and updates) would be
very helpful.

Though my involvement in the RDFa TF has not precisely increased over the
past months I very much like the idea of having an API here and willing to
do some of the legwork. Hope my colleague Knud reads this and also chimes in
;)

Cheers,
      Michael

[1] http://code.google.com/p/rdfquery/

--
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html



> From: Manu Sporny <[hidden email]>
> Date: Mon, 01 Feb 2010 00:15:33 -0500
> To: RDFa TF list <[hidden email]>
> Subject: RDFa DOM API Editors Draft
> Resent-From: RDFa TF list <[hidden email]>
> Resent-Date: Mon, 01 Feb 2010 05:16:03 +0000
>
> I had an action to create and publish a skeleton document for the RDFa
> DOM API:
>
> http://dev.w3.org/rdfa/specs/rdfa-dom-api.html
>
> The content of the document has not been discussed prior to publishing,
> nor should anybody expect it to be the approach that the group will take
> in the coming months. I was mostly just playing around with ReSpec to
> see if it has the facilities that we will need as we define the
> interface for the DOM.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: Bitmunk 3.2.1 Released - Video and Data Sales
> http://blog.digitalbazaar.com/2010/01/31/bitmunk-3-2-1/
>


Reply | Threaded
Open this post in threaded view
|

Re: RDFa DOM API Editors Draft

Toby Inkster-4
In reply to this post by Manu Sporny
On Mon, 2010-02-01 at 00:15 -0500, Manu Sporny wrote:
> http://dev.w3.org/rdfa/specs/rdfa-dom-api.html

I know this is just very early thoughts, but here's a few comments:

| interface Triple

Doesn't contain a mechanism to differentiate between these triples:

  <foo> ex:test <bar> .
  <foo> ex:test "bar" .

Perhaps a boolean attribute "is_literal"?

I'm assuming that the "_:" convention would be used to identify blank
nodes, but it is not clear whether an implementation of this API would
be required to keep blank node identifiers exactly how they are given in
the source RDFa or not. (RDF assigns no meaning to blank node
identifiers -- they're not part of the data; just part of the
serialisation. It seems unwise to rely on them being preserved by the
parser.) Of course, not all blank nodes have identifiers in the source
(some will be assigned during parsing due to chaining rules, etc).

| children of type array of Triple, readonly
| A list of triples that contain the same subject as this triple.

Not sure why this attribute is called "children". If a familial relation
is wanted, "siblings" seems more appropriate to me, as there's no
obvious hierarchy between triples.

Better would just be to have a document.getTriplesBySubject(s) method:

        // Instead of this_triple.children...
        document.getTriplesBySubject( this_triple.subject );

Even better, document.getTriplesByPattern(s, p, o):

        var triples = document.getTriplesByPattern(
                null,
                'http://xmlns.com/foaf/0.1/name',
                'Toby Inkster');

| getTriplesByType
| To perform a match, a direct string comparison is performed. If the
| string comparison fails, the given type is checked against a subject's
| type starting at the last character in each string and moving
| backwards.

This seems odd. I can see why it might be useful to return a list of
foaf:Persons when document.getTriplesByType('Person') is called; but I
can see less justification in allowing document.getTriplesByType('rson')
to work. Perhaps use word boundaries rather than character by character
scanning?

Also, what triples would be returned? Say the document contains only
three triples:

   <> foaf:primaryTopic <#me> .
   <#me> a foaf:Person .
   <#me> foaf:name "Toby Inkster" .

All of the triples contain the resource <#me> (in either subject or
object position), and <#me> is a Person, so would they all be returned?
Or would just the triples with <#me> as the subject be returned? Or just
the single triple "<#me> a foaf:Person"?

If the last of these is correct, then returning triples seems
superfluous, as you already know what the predicate will be, and have a
pretty good idea what the object will be. So getResourcesByType(t),
returning not triples, but a list of URIs and blank node identifiers
would be just as useful.

--
Toby A Inkster
<mailto:[hidden email]>
<http://tobyinkster.co.uk>