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
>>>>>
>>
>>
>>
>
