Does it name the Graph or the SecuredGraph? looks like the latter to me
- which makes sense to me if the same graph may in two SecuredGraphs for
different setups.
Andy
On 06/08/15 14:28, Claude Warren wrote:
The permissions code has the requirement that a graph be named, but it does
not store the name in the graph object.
For debugging, you could wrap graphs with a delegating graph implementation
that contains the graph name. This would get the functionality you want
without modifying graph itself.
I have not looked, but is there a way to set the graph "constructor" that
is used when calling GraphFactory.createDefaultGraph()?
Claude
On Thu, Aug 6, 2015 at 12:40 PM, Rob Vesse <[email protected]> wrote:
I would tend to be against having it as an API feature for several reasons:
- Users will assume that this is the one true name of the graph (a graph
could have multiple names)
- Every special graph potentially needs to have some kind of name (what
would the name of a multi-union be?)
- RDF 1.1 permits blank nodes as graph names which are almost certainly
unusable outside the context of a specific database so why expose them
(this also means the return type needs to be Node not String)
- What about systems that don't support named graphs (I guess you return
null but then you get users blindly running into NPEs they weren't
expecting)
- Is the graph name immutable? If yes then you could get unexpected
behaviour as follows:
Graph orig = new Graph("urn:foo");
Node name = NodeFactory.createURI("urn:bar");
dsg.addGraph(name, orig);
Graph retrieved = dsg.getGraph(name);
System.out.println(retrieved.getName());
Should that return urn:foo or urn:bar, or should it have returned nothing
and actually stored the graph under urn:foo?
Also having built an API where graphs had a name field on them I can say
that it caused far more problems than it ever solved and I would be
reluctant to introduce it to Jena. Note that most of the problems were
around the way assumptions about how the name field was used leached into
the rest of the API, the above code example is one place where introducing
such a field immediately has potential for confusion.
Rob
On 06/08/2015 09:39, "Holger Knublauch" <[email protected]> wrote:
Yes I can do that. I was wondering whether others have the same
requirement, so that it becomes a general API feature.
Holger
On 8/6/2015 18:31, Rob Vesse wrote:
Is there any reason why you can't just create your own wrapper class
NamedGraph which would hold the extra information and simply place your
actual Graph instances inside these wrappers with the desired names
attached?
Rob
On 06/08/2015 03:04, "Holger Knublauch" <[email protected]> wrote:
toString would be sufficient, but there needs to be a way to set this
name when the graph is created. Doesn't need to be persisted, and would
be sufficient for memory graphs.
Holger
On 8/6/2015 10:46, [email protected] wrote:
Since this is essentially about debugging, would it suffice to require
Graph implementations to provide something in toString() to uniquely
identify themselves, or do you really require user-settable or
-accessible labels?
---
A. Soroka
The University of Virginia Library
On Aug 5, 2015, at 8:35 PM, Holger Knublauch <[email protected]>
wrote:
While debugging I often run into cases where I walk through Graph
objects (esp MultiUnions) and don't really know which graphs they
are.
Looking at triples is often not sufficient. I wonder whether the
Graph
interface (or at least GraphMem etc) could be extended with a String
name field that could be set to identify the graph. Then people could
place a backward link to the graph name (or even just a comment) into
the Graph object itself upon creation. I welcome other suggestions
too,
or maybe I am the only one who would find that useful?
Thanks,
Holger
