Re: Blank Node Identifiers and RDF Dataset Normalization

On 2/26/13 12:46 PM, Andy Seaborne wrote:
>
>
> On 26/02/13 16:36, Kingsley Idehen wrote:
>> On 2/26/13 6:53 AM, Steve Harris wrote:
>>> On 2013-02-26, at 11:21, William Waites <wwaites@tardis.ed.ac.uk> 
>>> wrote:
>>>
>>>> On Tue, 26 Feb 2013 11:10:55 +0000, Steve Harris
>>>> <steve.harris@garlik.com> said:
>>>>
>>>>> Yes, but this can only happen if you merge multiple datasets,
>>>>> right? Otherwise no-one gets to write anything into the "default
>>>>> graph" against the will of the dataset maintainer.
>>>>> This is related to the reason why I find the idea of having a
>>>>> single format that can express both Graphs and Datasets so scary
>>>>> - you can bring this kind of situation on yourself without any
>>>>> prior warning. Very bad idea.
>>>> I agree, but this arises from the existing of a special graph called
>>>> default and the somewhat non-standard use of the word "default". A
>>>> longer but more accurate name might be, the "graph that cannot be
>>>> named or referred to of which there is only one where we put triples
>>>> that we can't think of a better place to put".
>>>>
>>>> This could easily be solved by putting
>>>>
>>>>     default_graph = http://some.name/graph
>>>>
>>>> in your sparqlserver.ini file and then manage the contents of that
>>>> named graph whatever way you see fit.
>>>>
>>>> We do not need the notion of "default graph" in the core RDF specs! It
>>>> is a mistake. Please let us get rid of it.
>>> I agree wholeheartedly, and argued quite vociferously against it's
>>> inclusion in SPARQL 1.0, but I think it's too late now. The anonymous
>>> genie is out of the bottle.
>>>
>>> - Steve
>>>
>>
>> As implementers of SPARQL compliant stores and DBMS engines, we (you,
>> Andy, I and others) do have the ability to conjure up our own best
>> practices which could then cycle back to the next round of RDF and
>> SPARQL specs related revisions. It's happened in the past, so why not
>> handle this matter the same way?
>>
>> Conclusion: We discourage the use of anonymous default graphs in our
>> respective products. Every useful thing should be denoted using an
>> identifier.
>
> Jena users find the default graph concept useful:
>
> 1/ When there is one graph being published

Yes-ish. I say that because the implications are really obvious.

Imagine if that's how an SQL RDBMS handled the fact that you just wanted 
to have some records created quickly i.e., they had an anonymous default 
table. Likewise, the schema was an anonymous table etc..

>
> 2/ As the union of the named graphs

But they could also explicitly seek a union of said graphs in a query if 
that's what delivered the solution sought.

>
> 3/ As a single place to put the manifest

That place could have a name by default.

>
> Conclusion: you don't have to use it if you don't want to.
>
> (all well worn points)
>
>     Andy

Yes-ish.

The trouble is that users always use defaults under the misguided 
assumption that defaults know best :-)

Kingsley
>
>>
>>
>>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen