Bruce D'Arcus wrote:
On Wed, Mar 19, 2008 at 7:39 AM, Michael Stahl <[EMAIL PROTECTED]> wrote:
...
> Am *really* not sure about this, but I wonder if it would make sense to
> consider the document itself a graph?
hmmm, interesting idea.
If I understand the RDF model correctly, then a document would have a
graph associated, which consists of a set of named graphs (the RDF/XML files).
So the whole document is a graph, and every single RDF/XML file is a
subset of the document graph, and _also_ its own named graph.
Yes, except I'm suggesting that the content files also have their own graphs.
hmm... we could do this.
But there are some caveats:
For one, you cannot add arbitrary statements to a content file graph.
In fact, the RDFa methods at XRDFRepository are sufficient for
manipulating content files, and (as described in the message you quoted) i
would rather not allow using addStatement to manipulate the content graph.
Also, we want to easily identify the RDFa statements for an individual ODF
element (as described above, in those three dots).
Using the XML ID as the context seems expedient to me.
One thing I like about Sesame 2 is that it supports a list of contexts
when you add a statement.
Redland RDF, OTOH, only seems to support one context per statement.
So, the only thing that you could do with a content file graph is
enumerate it.
But you are right, that is useful functionality to have.
What about a method XRDFRepository::getRDFaStatements(Subject, Predicate,
Object)?
Or we could just have a content file graph, and its addStatements method
would just throw IAmAContentGraph_UseAddStatementRDFa_Exception :)
Or, alternatively, we split out the concept of adding statements from
XRDFNamedGraph, so that we have two interfaces, one without addStatement,
and another, inheriting from the first, that adds addStatement.
hmm, i think i prefer the first alternative.
But: we cannot add a RDF statement to the "whole document graph", while
not adding it to any named graph; if we allowed a statement that is not
part of any named graph, where would we store it in the ODF file
(especially in a way that is interoperable with other implementations of
the ODF metadata spec)?
Right.
So I would claim that it does not make sense to expose in the API a "whole
document graph"; you just add your statements to some named graph, and
they end up in the "whole document graph" as a side effect.
The drawback of this approach is that you cannot enumerate the "whole
document graph".
Except as a collection of named graphs, which is fine.
hmmm, actually we could have a method
XRDFRepository::getStatements(Subject, Predicate, Object)
that just enumerates the whole repository.
That should be easy to implement.
Do you think this is a useful addition?
But you can still query it with SPARQL, and it seems to me that is good
enough.
oh, and if you think i have misunderstood something, please tell me!
i only started reading up on RDF a month ago...
> 2) "executes a SPARQL "SELECT" query."
>
> Oooh ... nice! Do I thus assume the endpoint can be arbitrary? E.g. if I
> have an endpoint setup on a relational database somewhere, I can query
> that from the OOo API?
That was the idea, yes. The XRDFRepository interface can be implemented
either by an in-memory repository (as would be done for ODF documents), or
by some database, accessed via HTTP or SQL or whatever.
However, we want to have one repository per document, and the database
repository would be distinct as well, so you would not be able to write a
SPARQL query across document metadata and a database; you would have to
write two queries.
OK, but I think a single SPARQL query can point to multiple repositories (?).
well, that depends very much on the underlying implementation...
Actually i thought that Sesame 2 could do this, but no: it only has a
StackableSail which allows for creating a repository by stacking basic
blocks like a store and an inferencer.
Redland RDF cannot do this, which is bad enough, because we want to be
able to implement the whole API with it.
(Unfortunately, we cannot depend on Java for core OOo functionality.)
So, in summary, you can only query one repository with one SPARQL query.
...
So, the graph name must be an URI, and it must represent the file name
somehow.
The URI is a name for a graph, which in the context of ODF, gets
seialized as RDf/XML. In that sense, the file name is rather
orthogonal.
looking at the spec again i see that the manifest contains a pkg:path
property for the file name. Sorry, had forgotten that. Of course, in that
case what i wrote above does not make any sense.
Michael
--
PUBLIC NOTICE AS REQUIRED BY LAW: Any Use of This Product, in Any
Manner Whatsoever, Will Increase the Amount of Disorder in the Universe.
Although No Liability Is Implied Herein, the Consumer Is Warned That
This Process Will Ultimately Lead to the Heat Death of the Universe.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
