Re: netlabs.org RDF/RDFa API implementation

Hey Manu,


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

this is not a problem, there is always too little time for too much todo
:-) So thank you very much for your elaborate answer, and we are happy to
now get into a discussion onto the library subject

>> With the RDF API <...> has a parse step to be executed in
>> any way before the Basic API or Projections could provide
>> access to RDF data?
<...>
> 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.

Hmm, according to the specsonly RDF Interfaces have a DataParser and a RDF
environment class, or has that already changed ? For RDF Interfaces this
question is clear.

> It may be that we end up putting an "output graph" on the Data
interface:
<...>
> 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?

I understand it as if you wold want to add a member to the interface. I
would consider that being a bit confusing, as any instance of the Data
interface that I would create, would hold a reference to the same output
graph - or do I misunderstand it ? Another option could be that there
would be an initialized instance of the Data interface holding the output
graph, while script code still could create any number of new Data
instances, parsing data from somewhere else. The only question then would
be how that instance would be named and where and how it would be attached
to, since in the RDF API spec no RDFEnvironment instance exists that could
be designed to e.g. return the Data instance holding the output graph.
However this seems to make most sense to me for now.

> 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?

That matches perfectly what we expected, and already have implemented and
used. This merge feature is most important for literally any of the use
cases that we came across until now. And after all, wanting to have a new
set of Data parsed simply needs a new object and then it is separated.
BTW, in a non-browser-based environment this even applies to RDFa API,
since there is no output graph and all data has to be parsed into a Data
object anyway.

>> 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?

Yes, indeed, similar to RDF Interfaces, however in the RDF API spec the
ParserCallback receives Projections, not a Graph. What brings me back to
the same question all over again, I am afraid. And of course these slight
differences between the RDF(a) API/Interfaces specs lead to confusion
anyway...

BTW, has it already been taken into consideration to merge the best of all
three specs into a single one? I would opt for the good structured
interfaces layout of RDF Interfaces and its datatype and language support,
and for well readable and smaller code I would add at least the
projections of RDF interfaces, if not also the basic API.

But maybe we just did not yet completely understand how to properly use
RDF Interfaces. We tried to convert one of the RDF(a) samples of our
library, trying to convert that into RDF Interfaces style.
This sample uses a small graph, specifying some FOAF values of three
persons. Using the basic RDF(a) API, the sample code queried all subjects
being a foaf:person, then querying the properties foaf:name and foaf:work,
and from the latter foaf:city.

To adapt to RDF Interfaces, from the parsed graph we called match() to
extract a new graph containing all subjects being a foaf:person, and then
per person using match() to query foaf:name, the foaf:work node and then
foaf:city. This does not only look ugly and requires considerably more
code, I somewhat have a feeling that this is not the way to go ;-) Maybe I
should have used actions and/or filters !? However, we were not able to
figure out a good alternative - are there some code samples around which
would show how to do some trivial things on behalf of a user ?

bye, Christian

-------------------------------------------------

Christian Langanke
cla@clanganke.de

Received on Wednesday, 28 September 2011 14:27:03 UTC