Re: multiple-graph example in the Primner

On 12/07/2013 09:54 AM, Kingsley Idehen wrote:
> On 12/7/13 8:28 AM, Sandro Hawke wrote:
>> Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>> On 12/7/13 7:54 AM, Sandro Hawke wrote:
>>>> Pat, I agree with you about the situation except I believe there's a
>>> way out, which is why I stopped objecting back when we were making
>>> these decisions.  The way out is to define some vocabulary which
>>> communicates from Alice to Bob what kind of dataset semantics Alice is
>>> using.   That vocabulary doesn't need to be defined in a W3C
>>> recommendation to work.  So the primer just needs to posit that such
>>> vocabulary might exist, and give the example as a hypothetical.
>>> Alternatively, we could define that vocabulary (non rec track) right
>>> now and use it in the primer with a caution that this is only one of
>>> many possible ways to use datasets.
>>>>        - Sandro
>>> Yes, a vocabulary can be used to solve the problem. Net effect, we
>>> still
>>> don't need a confusing and contradictory example in the spec :-)
>>>
>> I don't see any need for it to be confusing or contradictory. I'd 
>> suggest we choose the semantics where URLs used as graph names denote 
>> sources which yield the associated graph.   I believe that's what the 
>> overwhelming majority of readers will expect, so when they read the 
>> example they will feel reassured that they can do what they 
>> expected.   The only confusing thing will be our caveats, if we're 
>> not careful.
>>
>>    - Sandro
> The following examples will lead to confusion:
>
> ## Relative Resource URL serving as a Named Graph IRI
> <>
> {<#s> <#p> <#o> } .
>
> ## variation of the above
>
> <.ttl>
> {<#s> <#p> <#o> } .
>
> ## Absolute Resource URL serving as a Named Graph IRI
>
> <http://example.org/example.ttl>
> {<#s> <#p> <#o> } .
>
> ## 3 Named Graphs where two are derived from Resource URLs and one is 
> an inferred Default (or System) Named Graph which maybe be associated 
> with
> ## {<#s> <#p> <#o> } .
> ## OR
> ## a Union of the Default, <.ttl>, and <> .
>
> <.ttl>
> {<#s> <#p> <#o> } .
> <>
> {<#s> <#p> <#o> } .
>
>
> All of the examples above cover implementation and usage scenarios 
> that are best covered via related specs such as SPARQL (for querying) 
> and concrete syntaxes (NQuad, TriG etc.).
>
> It is best for the RDF spec, primer, and related collateral to focus 
> on RDF semantics for triples based structured data representation. All 
> examples should be simple for the reader to understand and follow :-)

I don't think the example has to be that complicated.   I think if we 
just include in the TrigG details a triple like "<> a eg:WebSource" (and 
mention that's a suitably defined class) then we're technically correct, 
and users aren't particularly confused. (I'm happy to have it be 
rdf:WebSource defined in a WG Note, if we want).

If the Primer also included a diagram of the dataset being discussed -- 
drawn as an RDF graph of the merge of the two named graphs and the 
default graph, color coded and segmented by their names -- then I think 
it wouldn't be confusing at all.

       -- Sandro


>
> Kingsley
>>
>>> Kingsley
>>>> Pat Hayes <phayes@ihmc.us> wrote:
>>>>> On Dec 5, 2013, at 4:53 AM, Guus Schreiber <guus.schreiber@vu.nl>
>>>>> wrote:
>>>>>
>>>>>> In the telecon yesterday there were some flames about the graph
>>>>> metadata examples in the Primer.
>>>>>> My position:
>>>>>> - There needs to be at least one example triple in the Primer in
>>>>> which a graph name is being used. Dropping this completely is for
>>> the
>>>>> editors a no-go.
>>>>>
>>>>> Including such an example is a no-go for me. I will formally object
>>> (or
>>>>> protest, or register a dissent, I am not sure of the exact W3C
>>> process
>>>>> involved here) if the WG publishes any document which implies that
>>> such
>>>>> usage is in any way supported by the RDF 1.1 specifications. That is
>>>>> *exactly* the semantic stumbling-point at which we were unable to
>>>>> provide any semantics for datasets. RDF 1.1 does NOT imply in any
>>> way
>>>>> that the use of a graph-name in an RDF triple can or should be
>>>>> understood to refer to the graph. On the contrary, it explicitly
>>> denies
>>>>> the validity of such an assumption.
>>>>>
>>>>>> - We are happy to consider other examples. Please suggest.
>>>>>> - We're happy to include other/updated caveats
>>>>>>
>>>>>> Current phrasing included below. Text suggestions very much
>>>>> appreciated!
>>>>>> Guus
>>>>>>
>>>>>> From
>>> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-primer/index.html#subsection-multiple-graphs 
>>>
>>>>> :
>>>>>> [[
>>>>>> We can write down triples that include a graph name, for example:
>>>>>>
>>>>>>    <http://example.org/bob> <is published by> <http://example.org>.
>>>>>>    <http://example.org/bob> <has license>
>>>>>>        <http://creativecommons.org/licenses /by/3.0/>.
>>>>>>
>>>>>> These two triples could be interpreted as license and provenance
>>>>> information of the graph http://example.org/bob.
>>>>>> NOTE
>>>>>> RDF does not define the way in which the graph name and the graph
>>> are
>>>>> related. It is therefore up to application developers to decide how
>>> to
>>>>> interpret such triples.
>>>>>
>>>>> That does not deal with the central difficulty. RDF is intended for
>>> use
>>>>> in publishing data on the open Web. The issue involved here is, if
>>>>> Alice publishes an RDF dataset, and Bob reads it, how can Bob know
>>>>> whether a graph name used in RDF in the datset should be interpreted
>>> as
>>>>> referring to the graph it names? And the clear, unambiguous answer
>>>>> given by our RDF specs is, Bob cannot know this. There is no way
>>>>> specified to record or transmit this information through RDF or any
>>>>> means usable by an RDF engine. Alice might conform to the metadata
>>>>> useage needed by PROV, and Bob might read this and interpret it
>>>>> differently, without failing in any way to conform to RDF. So as far
>>> as
>>>>> RDF is concerned, this usage is invisible. Vague references to
>>>>> "application developers" does not deal with this issue.
>>>>>
>>>>> Pat
>>>>>
>>>>>> ]]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ------------------------------------------------------------
>>>>> IHMC                                     (850)434 8903 home
>>>>> 40 South Alcaniz St.            (850)202 4416   office
>>>>> Pensacola                            (850)202 4440   fax
>>>>> FL 32502                              (850)291 0667 mobile
>>>>> (preferred)
>>>>> phayes@ihmc.us       http://www.ihmc.us/users/phayes
>>>>
>>>>
>>
>>
>>
>
>

Received on Saturday, 7 December 2013 15:12:55 UTC