Re: netlabs.org RDF/RDFa API implementation

Apologies about the horribly late reply, Christian and Adrian - we've 
had our hands full prepping the 3rd Last Call for RDFa 1.1.

On 08/16/2011 04:08 PM, Christian Langanke wrote:
> netlabs.org currently is implementing a PHP library supporting most
> parts of RDFa API and RDF API specs according to the current working drafts.

Good to hear. :)

> At first, with the RDFa API it seems to be clear that the data that can
> be accessed is the data from the web document itself, and is available
> as soon as the document is loaded (and JavaScript is being executed).

Correct.

> With the RDF API spec this is not clear to me: is it that the document
> data is available fom initialization on as well or has a parse step to
> be executed in any way before the Basic API or Projections could provide
> access to RDF data?

Good question. I don't think we have a good answer yet, but here is an 
attempt at one:

There is no parse() step for an RDFa document in a DOM environment - the 
data is ready the second the DOM is ready. An implementation could delay 
parsing of the document until one of the RDFa data methods is called.

However, your question was about the RDF data - which is a slightly 
different question. There is the concept of an "output graph" in RDFa - 
that's whats available to the RDFa API. However, at present, we don't 
say anything about it - it's just assumed that it is there.

The RDF API has no such visible or hidden graph - it's stateless for the 
most part. You can call DataParser.parse() to generate a graph, or you 
can call, RDFEnvironment.createGraph() to create a new graph... but 
there is no "output graph" that is defined by the RDF Interfaces spec or 
the RDF API spec.

It may be that we end up putting an "output graph" on the Data interface:

http://www.w3.org/2010/02/rdfa/sources/rdf-api/#data-environment

That may be the most logical place to put this concept. Then, we can say 
that the graph is initialized on document load or on an as-needed basis. 
Does that sound reasonable to you?

> Second, if a parse step had taken place, does the Data interface from
> that point of time provide access to a) only the newly parsed RDF data
> or b) to the data of the document and the parsed data as they are merged?

When you call the .parse() method, you can provide a graph. If you 
provide the graph (that we have yet to add to the Data interface), then 
a merge would be performed. At no point do I think we wanted to destroy 
all of the old data in a graph (unless the contents of the document 
changed). It may be up to the application developer to figure out if 
they want the graph to be updated in a "clobber" or "preserve" triples 
mode. I think merging the data may be safer than clobbering the data. 
What are your thoughts on this?

> Third, if (at all) the Data interface was to provide access to the newly
> parsed data via the Basic API as well, and not only via Projections
> (which have already been prepared by the parse step), is it intended
> that implementers calculate the results of the Basic API methods by
> accessing the Projections?

No, the Projections are meant to be built from the RDF Interfaces 
methods. At no point should a developer have to reverse engineer the 
Projections to figure out the underlying triples.

> The reason for this question is that I started out with implementing the
> Basic API first. The Data interface supports a very basic parsing method
> and holds the parsed data (currently ARC triple array) in a private
> member and calculates all required results of Basic API methods from
> that. The projections get passed the Data object to the constructor so
> that they can use the Basic API to fulfill the requests put by the
> Projection interface.

That's the correct way to do it, imho.

> Now I am at the step of implementing the parse method with the RDFParser
> interface which is intended to do the parsing. If now RDFParser would do
> the parsing and export only the projections, the Data interface had
> nothing else available than only the projections to support the Basic API.

We may want to put access to the parsed graph on the Data interface, so 
something like this:

[NoInterfaceObject]
interface Data {
    readonly attribute graph;
    ...
}

So, when you call the Data.parse() method the resulting triples are 
placed in Data.graph. Would this be a good solution for you?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Building a Better World with Web Payments
http://manu.sporny.org/2011/better-world/

Received on Wednesday, 14 September 2011 00:03:42 UTC