Re: types of "graphs"

On 09-05-2012 17:44, Guus Schreiber wrote:
>
>
> On 05-05-2012 15:02, Sandro Hawke wrote:
>> Manu's comment [1] spurred me to try show why we care about the
>> difference between a g-snap and a g-box.
>>
>> Intuitively, it matters to me because when I see
>>
>> <g> cc:license cc:by
>>
>> I want to know what is being licensed, or when I see
>>
>> <g> dc:creator "John Smith"
>>
>> I want to know what I'm being told he created.
>>
>> Also, the different types have different ideas about identity; there is
>> only one g-snap containing any given set of triples, so that affects the
>> kind of metadata we can meaningfully apply to it.
>>
>> To explore that a little more, I made a table of properties and
>> whether/how I thought they applied to the different types of things we
>> sometimes call an RDF "graph":
>>
>> http://www.w3.org/2011/rdf-wg/wiki/Containers_of_Triples
>
> Sandro,
>
> Nice document, thanks for putting this together.
>
> I don't really understand why the last entry in your first table can
> only be a g-snap, but that's probably because I'm not a SPARQL intimate:
>
> [[
> In Dataset X (Is this queriable as part of some particular SPARQL
> Dataset? A SPARQL Dataset is the abstract information against which a
> SPARQL query is executed.)
> ]]
>
> Conceptually, the properties mentioned actually do not make sense to if
> they hold *only* for g-snaps. A g-snap is an abstract notion; a g-snap
> may derive such metadata from the container(s) it is generated from (cf.
> the two penultimate properties, i.e. creator & license).

[Hope this helps and does not create confusion]

Taking the last point one step further: if people say something in RDF 
it is always in some box/space (in 2004-terms: the global box/space). 
So, people never create/store/query g-snaps, only containers (and 
transferring/storing them through some g-text). G-snaps just provide us 
with a mathematical view that allows us to reason with the contents of 
containers. This means we only need to provide mechanisms for typing 
g-boxes. Containers are by default dynamic, but for pragmatic reasons we 
might want to have a mechanism to say we consider a g-box to be frozen 
(which essentially is only a social contract). Ergo: we only need a type 
for a frozen g-box in our spec.

Guus


>
> Guus
>
>
>
>
>>
>> -- Sandro
>>
>> [1] "I really, really don't like all of the new terminology that the
>> group
>> is creating - having both 'graph' and 'layer' doesn't help simplify
>> this stuff to Web developers. Use a base word, like 'graph' and
>> modify it for the different types of graphs - graph snapshot,
>> graph container, etc."
>> -- http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0096.html
>>
>>

Received on Wednesday, 9 May 2012 16:17:48 UTC