- From: Sandro Hawke <sandro@w3.org>
- Date: Sat, 07 Dec 2013 10:12:47 -0500
- To: Kingsley Idehen <kidehen@openlinksw.com>, public-rdf-wg@w3.org
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