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 > >>>>> > >> > >> > >> > > > > > > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
