- From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
- Date: Wed, 26 Sep 2012 08:03:34 +0200
- To: Pat Hayes <phayes@ihmc.us>
- CC: Sandro Hawke <sandro@w3.org>, W3C RDF WG <public-rdf-wg@w3.org>
Le 26/09/2012 06:59, Pat Hayes a écrit : > > On Sep 25, 2012, at 9:25 PM, Sandro Hawke wrote: > >> On 09/25/2012 09:54 PM, Pat Hayes wrote: >>> On Sep 25, 2012, at 5:16 PM, Sandro Hawke wrote: >>> >>> >>>> For myself, at this point I'm 70% convinced that I can >>>> implement all the dataset use cases I understand (the ones I >>>> enumerated in the Federated Phonebook examples, plus SPARQL >>>> dump/restore) without any standard dataset semantics beyond >>>> having a standard place for metadata (eg the default graph in >>>> trig and the service description graph in SPARQL). >>>> >>> Sandro, how can you use metadata *at all* without some way to >>> force a URI to denote a graph? When you use the URI in the >>> metadata RDF, what (semantic or even pragmatic) constraint >>> ensures that what it denotes there is the graph that you have in >>> mind? Or indeed, that it is a graph at all? >>> >> >> My current theory is that I can do it via the documentation of the >> predicate(s) I use with that URI. > > Hmm. But the semantics being discussed right now explicitly > distinguishes the graph "named" by the URI it is attached to in a > dataset, from the entity the URI is understood to denote. And the RDF > semantics says that when a URI is used in an RDF triple, it refers to > what it denotes. So your documentation seems, on the face of things, > to be at odds with what the semantics says. The dataset semantics distinguishes the graph associated with the IRI and the thing denoted by the IRI but does not force these two things to be different (distinguish != differentiate). If the graph-metadata-spec says that an IRI of type eg:Graph MUST denote a graph, then you have to comply with it. In any case, most of the time, one doesn't want to talk about the RDF graph, one wants to talk about the container (or what you get when you dereference the IRI). > The basic point is, you can specify what your property means, but you > don't get free rein to say what the graph "name" URI refers to. (At > least, not unless you have something like a context to put it in, > where you *could* say what it means.) In fact, I'm sure what the IRI refers to will be well understood, under this kind of spec, just like, e.g., foaf:Document is well understood to be the class of real world documents. Simply the reasoner is not able to check that the graph IRI is indeed used as a graph (or container). AZ > > Pat > > >> Given the emerging sense of what datasets are, I think I can write >> that document in such a way that it will be quite clear to human >> readers (and thus the software they write) how it connects to the >> triples in the named graphs. >> >> I'm hoping the WG will end up making it really easy to write that >> documentation, but I'm pretty sure it's possible anyway. >> >> The example I used in [1] was: >> >> <g1> eg:sendCorrectionsTo <mailto:sandro@w3.org >>> . >> <g1> { w3c:group35462 rdfs:label "SPARQL Working Group" }. <g2> >> eg:sendCorrectionsTo <mailto: ivan@w3.org >>> . >> <g2> { w3c:group44350 rdfs:label "RDFa Working Group" }. >> >> (I'm using the default graph for metadata, and leaving off the >> braces around default-graph triples) >> >> And then I proposed documenting eg:sendCorrectionsTo something like >> this: >> >> X eg:sendCorrectionsTo Y >> >> Note: only meaningful as metadata for a dataset which has a named >> graph with the name X. >> >> Meaning: Y is a good email address for sending corrections to the >> information in the named graph X. >> >> >> This definition doesn't really care whether named graphs are >> g-boxes or g-snaps, but I think it's probably good enough to work >> in practice. Other predicates might be much more precise, of >> course. >> >> I'm not thrilled with the predicate being only meaningful when used >> in a dataset metadata [I prefered my framing as rdf-spaces] but >> this works, too, I think. >> >> -- Sandro >> >> [1] >> http://lists.w3.org/Archives/Public/public-rdf-wg/2012Sep/0181.html >> >>> >> Pat >>> >>> >>>> -- Sandro >>>> >>>> [1] http://www.w3.org/2005/10/Process-20051014/tr#cfr >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------ IHMC >>> (850)434 8903 or (650)494 3973 40 South Alcaniz St. >>> (850)202 4416 office Pensacola >>> (850)202 4440 fax FL 32502 >>> (850)291 0667 mobile phayesAT-SIGNihmc.us >>> http://www.ihmc.us/users/phayes >>> >>> >>> >>> >>> >>> >>> >>> >> > > ------------------------------------------------------------ IHMC > (850)434 8903 or (650)494 3973 40 South Alcaniz St. > (850)202 4416 office Pensacola (850)202 > 4440 fax FL 32502 (850)291 0667 > mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes > > > > > > > -- Antoine Zimmermann ISCOD / LSTI - Institut Henri Fayol École Nationale Supérieure des Mines de Saint-Étienne 158 cours Fauriel 42023 Saint-Étienne Cedex 2 France Tél:+33(0)4 77 42 83 36 Fax:+33(0)4 77 42 66 66 http://zimmer.aprilfoolsreview.com/
Received on Wednesday, 26 September 2012 06:04:19 UTC