It names the secured graph. Yes the same graph can be named two different things.
On Thu, Aug 6, 2015 at 4:15 PM, Andy Seaborne <[email protected]> wrote: > 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 >>>>>>>> >>>>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >>> >> >> > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
