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
