Re: RDFa API - graph?

Mark Birbeck wrote:
> Hi Nathan,
> 
> I know this is not meant to be a completely precise discussion :) but
> I'm a little worried that we might lose sight of our vision here.

Likewise, many previous mails discussed two or three levels of API, my 
take away from those was that our vision was to have a nice level 2 or 
level 3 API, but our remit was to provide a level 1 API (basic RDF 
support) and an RDFa extension to interact with RDFa documents in the dom.

Thus, that we should define just that, but also leverage our collective 
understanding and vision of level 2/3 APIs to ensure that what we do is 
compatible and usable by by future RDF APIs and libraries which which to 
implement that kind of functionality now.

Something like: Here, we've defined the interfaces for the RDF concepts, 
for Graphs, for parsing and processing documents, take that, extend it 
and use it in your libraries - and whilst your there provide these 
methods on the DOM so that regardless of which library (or vendor!) 
people are using, they have standardized access to RDFa documents.

> Of course we want to support RDF programmers.
> 
> But we have also said many times that we want the API to be usable by
> JavaScript programmers.
> 
> We need to constantly remember our constituencies and for the latter
> constituency, if, as you say, they
> 
>> ...have to deal with triples, subject, predicate,
>> object, plain literals, typed literals and so forth.
> 
> then we have failed!

Perhaps, or perhaps we will have had great success enabling innovation 
in libraries whilst standardizing the core to ensure interoperability.

If we standardize the concepts and the basic interfaces, then end users 
can use rdfx.js to lift the triples from a document (because it's 
faster) then throw the standardized Graph of RDF Triples in to the store 
provided by rdfy.js (because it provides an IndexedDB powered persistent 
store) and query them along the way with rdfq.js (because it's got a 
great in memory query engine) - if we standardize the goggles through 
which libraries see RDF then we enable interoperability at a core level 
and encourage an innovative open market place of rdf libraries.

Personally I feel that if we provide an API that basically means all js 
libraries are the same, providing the same functionality, then we will 
have failed.

The other side of this is the RDFa Extensions, which enable working with 
RDFa Documents in the DOM, on that side we standardize the interfaces so 
that RDFa-centric scripts, libs and plugins work across all vendors, so 
that johnny-js-dev can knock up a little script which highlights all his 
friends on his personal homepage, and know that just as when he uses 
document.getElementByID, it'll work. Likewise for the future authors of 
some omg-its-amazing-and-so-easy jRDFaQuery library.

I guess my point is, let's not aim to provide some amazing API with the 
belief that we can do it perfectly, rather let's standardize just enough 
to enable interoperability and allow others (and ourselves) to create 
those amazing APIs & libraries.

> As it happens, 'graph' is no longer a computer-sciency term; thanks to
> Facebook most programmers will be familiar with the idea of the
> 'social graph' that expresses relationships between people, so all we
> need to do is indicate that we have a mechanism for managing and
> querying graphs of all types.
> 
> But even that point is moot since the novice programmer will begin
> with data stores, not graphs -- the store should manage one or more
> graphs, which gives programmers a choice as to which of these levels
> they wish to interact with the data.

I can only agree partially with that, in some cases they'll want a 
store, in others a set of triples (graph) and in most they'll want 
neither and just want to do something like:
   $("foaf:Person").click(showDetails);

So I suggest we ensure that regardless of which lib they use, a triple 
is a triple and a graph is a graph, and regardless of which platform 
that lib is running on it can depend on the functionality of 
document.getElementsByType.

Best,

Nathan

Received on Sunday, 31 October 2010 16:19:21 UTC