Re: Putting metadata in the "default" graph Re: Dataset Syntax - checking for consensus

On 27/09/12 12:52, Steve Harris wrote:
> On 2012-09-27, at 12:24, Andy Seaborne wrote:
>> On 27/09/12 12:13, Steve Harris wrote:
>>> On 2012-09-27, at 12:08, Andy Seaborne wrote:
>>>> On 26/09/12 17:41, Lee Feigenbaum wrote:
>>>>> We need to support it for compatibility, but I think it's a
>>>>> mistake to specify that anything important be put in that
>>>>> graph.
>>>>
>>>> There are two uses cases: you and Steve emphasis the
>>>> complicated case of multiple graphs collected from many
>>>> places.
>>>
>>> If that's not the case, why are you bothering with named graphs?
>>
>> Because different customers have different requirements.  I come
>> across both cases, but not necessary with the same data.
>
> I can imagine that situation in theory, but what real-world usecase
> leads you to use named graph, but where the metadata applied to the
> whole document?
>
> It seems like a corner case.
>
> Database dumps are one possibility (but then you'd often have both
> dataset-level and graph-level metadata), but those are more commonly
> in nquads formant, from what I've seen.

Lee's claim was that the default graph was "perhaps not widely used." 
and "it's a mistake to specify that anything important be put in that 
graph."

I was commenting that it's not "compatibility" when there is an 
important use case.

	Andy

>
>>>> The simple case is one graph.  For that, making the publisher
>>>> go through "naming" is just overhead for them.
>>>
>>> But that's "just" RDF, isn't it? In that case I don't see the
>>> issue.
>>
>> Yes, it is, and SPARQL is an RDF query language.
>>
>> Requirement - publish data.
>>
>> The idea of a "TriG" sub-ecosystem and an "RDF" sub-ecosystem is
>> not a happy thought.
>
> Strongly agreed, though I don't think many people share this
> concern.
>
> - Steve
>

Received on Thursday, 27 September 2012 11:59:30 UTC