On 01/09/13 10:56, Claude Warren wrote:
Perhaps we should add a flag to the graph Capabilities object to specify
whether or not the supports "Generalized RDF".
"Generalized RDF" is an end-to-end concept, not just a graph one.
Sometimes code might be using it internally, but for an app to use
"Generalized RDF" in the widest sense, it needs reader, writers and
storage to work together, and also for the systems consuming the apps
data to work.
Not even JSON-LD isn't full generalized RDF.
While on the subject of the Capabilities object, what does findContractSafe()
mean?
I have no idea! The javadoc says ...
/**
Answer true if the find() contract on the associated graph is "safe",
ie, can be used safely by the pretty-printer (we'll tighten up that
definition).
*/
and it is referring to the RDF/XML pretty printer.
Andy
On Sun, Sep 1, 2013 at 10:45 AM, Andy Seaborne <[email protected]> wrote:
On 01/09/13 10:21, Claude Warren wrote:
hmmm.... Then the FileGraph adds the extra constraint to its
implementation
of Graph in that it can't accept the non-URI nodes in the predicate
position when transactions are in use as it writes the checkpoint file and
the writer won't accept a non-URI in the predicate. Perhaps this is a bug
in the writer then?
FileGraph is very old (does anyone use it much? at all? and
transactionally [*] ?) and is a bit of an outlier.
Whether a particular storage can deal with generalized RDF is not defined;
some will, some won't. Things have to be "fit for purpose". FileGraph
doesn't get much attention.
FileGraph uses an RDF writer (and RDF reader) - that's the restriction.
It's not a writer bug - it's the FileGraph choice of writing in fixed RDF.
Either a DataBag, RDF patch, or a special, generalized N-triples
writer/reader would work.
Andy
[*] The graph is not crash safe. It writes files in-place, not write to a
temp file in the same directory and mv it over the top which is the way to
get an atomic filesystem action.
On Sun, Sep 1, 2013 at 10:06 AM, Dave Reynolds <[email protected]
**wrote:
Hi Claude,
On 01/09/13 08:36, Claude Warren wrote:
I am a bit confused. I was under the impression that a predicate had to
be
a URI (not anon and not literal) node. This seems to be enforced by the
graph writing code but not by the graph code itself. Should not the
graph
code thrown an exception when a non-URI node is used as a predicate? Or
is
the writer too strict?
It is the Model/Statement layer which enforces "syntactic" constraints
like that, plus the writers.
The Graph/Triple/Node storage layer deliberately omits those checks,
implementing what some people call "generalized RDF".
This has several benefits. It keeps the storage layer uniform and simple,
it allows the reasoners to construct intermediate results which are
outside
the RDF model constraints, it allows for possible change to the RDF
model.
In particular the notion of allowing bnodes as predicates was discussed
and
postponed at the previous round of standardization and has certainly been
discussed in the current round (especially in the context of JSONLD) -
though I don't know its current status.
Dave
