Re: General feedback on the RDFa API draft

Mark, All,

As a thought exercise, I've taken all the interfaces and made whatever 
changes would be needed to turn this in to a generic RDF(a) parser which 
is not DOM dependent - all quite minor changes, and essentially creates 
a set of interfaces which could all be easily extended for a DOM 
specific API.

Changes to 'RDF Interfaces':

IRI, PlainLiteral, TypedLiteral
   DOMString changed to string
   loose origin

BlankNode
   DOMString changed to string


Changes to 'Structured Data Interfaces':

DataContext, TypedLiteralConverter,
   DOMString changed to string

DataStore
   DOMString changed to string
   createIRI, createPlainLiteral, createTypedLiteral loose origin
   filter method changed to filter( subject, predicate, object, filter )
   filter method could also be:
    filter( filter, subject, predicate, object )
   so that it could be extended with 'element' for DOM based interface

DataParser
   DOMString changed to string
   iterate method changed to filter( subject, predicate, object, filter )
   iterate method could also be:
    iterate( filter, subject, predicate, object )
   so that it could be extended with 'element' for DOM based interface
   !!parse() method is problematic, the argument would need to be any / 
string or similar (no Element).

DataIterator
   root changed to Object from Node

PropertyGroup
   DOMString changed to string
   looses origin

DataQuery
   no change

Document
   removed, no need

DocumentData
   DOMString changed to string


And here are the Interface definitions:

RDF Interfaces

IRI
note: still benefit in being an interface, can be extended and can be a 
point to strap on helper methods
[Constructor(in string value),
  Stringifies=value]
interface IRI {
     readonly attribute string value;
};

PlainLiteral
[Constructor(in string value),
  Constructor(in string value, in string language),
  Stringifies=value]
interface PlainLiteral {
     readonly attribute string value;
     readonly attribute string language;
};

TypedLiteral
[Constructor(in string value, in IRI type),
  Constructor(in string value, in IRI type),
  Stringifies=value]
interface TypedLiteral {
     readonly attribute string value;
     readonly attribute IRI       type;
     Any valueOf ();
};

RDFTriple (no change)
[Constructor(in IRI subject, in IRI predicate, in IRI object),
  Constructor(in IRI subject, in IRI predicate, in PlainLiteral object),
  Constructor(in IRI subject, in IRI predicate, in TypedLiteral object),
  Constructor(in IRI subject, in IRI predicate, in BlankNode object),
  Constructor(in BlankNode subject, in IRI predicate, in IRI object),
  Constructor(in BlankNode subject, in IRI predicate, in PlainLiteral 
object),
  Constructor(in BlankNode subject, in IRI predicate, in TypedLiteral 
object),
  Constructor(in BlankNode subject, in IRI predicate, in BlankNode object),
  Stringifies, Null=Null]
interface RDFTriple {
     readonly attribute Object subject;
     readonly attribute Object predicate;
     readonly attribute Object object;
};


The Structured Data Interfaces

DataContext
interface DataContext {
     void setMapping (in string prefix, in IRI iri);
     void registerTypeConversion (in IRI iri, in TypedLiteralConverter 
converter);
};

TypedLiteralConverter
interface TypedLiteralConverter {
     Any convertType (in string value);
};

DataStore

interface DataStore {
     readonly attribute unsigned long size;
     [IndexGetter]
     Object       get (in unsigned long index);
     boolean      add (in RDFTriple triple);
     IRI          createIRI (in string iri);
     PlainLiteral createPlainLiteral (in string value, in optional 
string language);
     TypedLiteral createTypedLiteral (in string value, in string type);
     BlankNode    createBlankNode (in optional string name);
     RDFTriple    createTriple (in Object subject, in Object predicate, 
in Object object);
     [Null=Null]
     DataStore    filter (in Object? subject, in optional IRI? 
predicate, in optional Object? object, in optional RDFTripleFilter filter);
     void         clear ();
     void         forEach (in function callback);
};

DataParser
interface DataParser {
     attribute DataStore store;
     [Null=Null]
     DataIterator iterate (in Object? subject, in optional string? 
predicate, in optional Object? object, in optional RDFTripleFilter filter);
     boolean      parse ( ?? );
};

DataIterator
interface DataIterator {
              attribute DataStore       store;
     readonly attribute Object          root;
     readonly attribute RDFTripleFilter filter;
     readonly attribute RDFTriple       triplePattern;
     RDFTriple next ();
};

PropertyGroup
interface PropertyGroup {
     attribute Sequence[IRI] properties;
     Sequence[any] get (in string predicate);
};

DataQuery
interface DataQuery {
     attribute DataStore store;
     Sequence[PropertyGroup] select (in Object? query, in optional 
Object template);
};

interface DocumentData {
     readonly attribute DataStore   store;
     readonly attribute DataContext context;
     readonly attribute DataParser  parser;
     readonly attribute DataQuery   query;
     DataContext createContext ();
     DataStore   createStore (in string type);
     DataParser  createParser (in string type, in DataStore store);
     DataQuery   createQuery (in DataStore store);
};

RDFTripleFilter
interface RDFTripleFilter {
     boolean match (in RDFTriple triple);
};

Best,

Nathan


Mark Birbeck wrote:
> Hi Nathan,
> 
> Many thanks for your feedback.
> 
> The goal is definitely to allow the API to be implemented
> independently of the DOM, but I agree that this is not very clear at
> the moment.
> 
> Perhaps if I give you the 'aim' you can see where we're headed, and
> also where we currently fall short.
> 
> The idea of having a rather detailed array of interfaces (such as
> Parser, Store, etc.) is so that it's easier to make clear how the
> different components work together, and most importantly what their
> life-cycles are. We wanted to ensure that we could answer questions
> like 'when can I run a query', or 'when is parsing complete', and the
> only way to do that is to drill further into the architecture and
> specify more of it.
> 
> However, we also believe that the single most important use-case for
> the API will be JavaScript/Ajax programmers doing clever stuff with
> the data in a web-page, and for this reason we wanted to provide a set
> of API definitions that would be appropriate for a DOM-based
> implementation. To put it a different way, we didn't want to run the
> risk of different browser-implementers deciding to combine the various
> modules in incompatible ways.
> 
> So what it sounds like we need to be clearer on is that the DOM-based
> part of the spec is not a requirement for all implementations of the
> parser, but it is a requirement for implementations based on a DOM.
> 
> This does flag up another issue which is the 'origin' property, which
> at the moment is defined as pointing to a DOM Node, and should really
> be more general.
> 
> Personally I see this as a 'user-defined' property that can be used
> for any purpose, and it just so happens that a DOM-based parser uses
> it to point back in to the DOM. But a different parser could use it
> for other purposes, which means that its name should probably be
> something more generic.
> 
> Anyway, as you can see there are still things to sort out, but
> hopefully you can also see that the kinds of clarifications you want
> are being worked through, and comments such as yours are really useful
> for helping to close in on a solution.
> 
> Regards,
> 
> Mark
> 
> On Sat, Jun 19, 2010 at 12:36 AM, Nathan <nathan@webr3.org> wrote:
>> Hi All,
>>
>> precursor: much of what follows may be addressed by changing the title to
>> 'RDFa DOM API' and stating 'An API for extracting structured data from Web
>> documents in a User Agent that implements the DOM' :)
>>
>> Without delving in to too many specifics, I'm slightly (something) that the
>> RDFa API only caters for handling RDFa inside a User Agent with DOM support,
>> it appears to me that the API could easily be split so that core
>> functionality could be implemented in any context.
>>
>> side: To quickly touch on subject.origin (or subjectOrigin), given that one
>> may pull in several resources via XHR and add them to a single DataStore,
>> how would this affect the subject.origin, and moreover what about the origin
>> of the triple (as in the URI/Document/NG it came from) - what we typically
>> think of as the ?g in a quad.
>>
>> Back to the specific issue of 'only works if you have a DOM', here's a
>> specific scenario:
>>
>> The rdflib.js from tabulator currently supports RDF/XML, N3 etc.. RDFa
>> support is currently being added - this could easily be an implementation of
>> the RDFa API - however the code also currently works on the server side (in
>> V8, node.js and suchlike), so it's a kind of universal library, but if we
>> upgraded it to use the RDFa API, then server side support would be lost.
>>
>> If however the RDFa API was created with this consideration in mind, then it
>> could be implemented in not only rdflib.js, but any server or client side
>> rdf library. Moreover, it would set the way to align everything but
>> serialization specific parsing with RDFa API, essentially creating a one for
>> all RDF API - I'm sure you can see the benefits in this, failing that even a
>> one for all RDFa API that can be implemented outside of the current
>> generation of User Agents would be nice.
>>
>> Apologies for introducing multiple issues for you to consider, perhaps not
>> everything is in scope, and I'm unsure if it needs addressed but just some
>> thoughts.
>>
>>
>> Best,
>>
>> Nathan
>>
>>
> 
>

Received on Saturday, 19 June 2010 14:25:50 UTC