- From: Pat Hayes <phayes@ihmc.us>
- Date: Fri, 21 Sep 2012 13:06:46 -0500
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: Antoine Zimmermann <antoine.zimmermann@emse.fr>, public-rdf-wg <public-rdf-wg@w3.org>
On Sep 21, 2012, at 10:44 AM, Peter F. Patel-Schneider wrote: > I don't think that this is converging, even on technical grounds. > > My view is that many or most of the use cases in http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC have to do with talking about actual graphs. I agree this is most obvious way to interpret the idea of a graph having a name. And it sems to be required in order to have metadata about graphs being expressed in RDF. My favorite semantics for datasets would simply say that the meaning of a dataset containing a pair <u, G> is that u denotes G. Fomally, I(<u,G>) is true when I(u)=G. This gives the entailment rule that {G, N} entails {G' N'} just when N' is a subset of N. We could add in asserting the default graph if that makes people happy. We might want to tweak this to have u denoting a resource with G as its initial state, etc., if we ever get this kind of stuff into a semantics, but I won't hold my breath on that. > My view is that having semantic interpretations of RDF datasets being insensitive to the actual named graph doesn't fully support these use cases. I'm even a bit worried about defining entailment between RDF datasets that doesn't distinguish between equivalent named graphs. I agree. Semantic equivalence is not identity of graphs, and (contrary to what Antoine calims), the RDF semantics does not say that you have blanket permission to replace a graph with an equivalent graph. All the semantics does is to define semantic equivalence. Pat > peter > > PS: From http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC I see at least 1.1, > > > > On 09/21/2012 11:33 AM, Antoine Zimmermann wrote: >> Le 21/09/2012 17:25, Peter F. Patel-Schneider a écrit : >>> >>> On 09/20/2012 12:00 PM, Antoine Zimmermann wrote: >>>> Le 20/09/2012 16:54, Peter F. Patel-Schneider a écrit : >>>>> >> >> [skip] >> >>>>> >>>>> In the semantics there is no notion of a relationship between a name and >>>>> an actual graph. >>>> >>>> In the semantics to which I refer (viz., first version of the Minimal >>>> dataset semantics) there is a function IGEXT that maps graph IRIs to RDF >>>> graphs. Isn't this a notion of a relationship between a name and an >>>> actual >>>> graph? >>> No, as it does not distinguish between equivalent graphs. Suppose you >>> have two equivalent graphs, then you can use them interchangeably in >>> your semantics. >> >> If I have 2 equivalent graphs, I can use them interchangeably according to the *RDF semantics*. It's not my fault. >> >> >>>> Or maybe, by "actual graph", you mean a graph that is actually >>>> "written" in >>>> a given dataset? Normally, the semantics defines the notion of >>>> interpretation independently of a given formula, and an interpretation >>>> makes >>>> true all sorts of formulas. >>>> >>>> In what I propose, for an interpretation to make a named graph true, the >>>> name has to be related (via IGEXT) to whatever graph makes the graph >>>> inside >>>> the pair true. >>>> >>> Yes, but this doesn't pick out the actual graph, just one of many >>> possible graphs. >> >> If you want the graph inside a <name,graph> pair, just read the dataset. There are APIs for this. >> >> Dataset d = loadDatasetFromFile(new File("foo.trig")); >> Graph g = d.getGraph("http://ex.com/g"); >> >> That's it. >> >>>> >>>>> If named graphs and RDF datasets are supposed to carry a relationship >>>>> between a name and an actual graph, then shouldn't the semantics reflect >>>>> this? >>>> >>>> By IGEXT, it does, but a dataset interpretation is not defined in >>>> function >>>> of a given dataset, so there is no reason that the name be associated >>>> with >>>> the "actual graph" in a given dataset. >>> >>> Why not? Isn't a major use case for RDF graphs to record where graphs >>> (actual graphs, not equivalence classes of graphs) come from? >> >> And what's this has to do with semantics? >> If I want to record someone's speach, I don't need to know the semantics of what he/she says. >> >> >>>>> >>>>> This is totally different from properties. No one should be arguing that >>>>> RDF graphs are supposed to carry a relationship between a name and a set >>>>> of pairs. Instead this is what the semantics does. >>>>> >>>>> >>>>> >>>>>> (Of course, you >>>>>>> could always just ignore the semantics and directly use the graph from >>>>>>> the dataset, but then what is the point of having the named graph >>>>>>> there?) >>>>>> >>>>>> The data structure is also very important, just as in RDF graphs, the >>>>>> data structure is already a nice way of organising the data, linking >>>>>> data together, etc. Semantics does not have to come into play where it >>>>>> has no role. >>>>>> >>>>>> >>>>>> --AZ >>>>> >>>>> >>>>> Huh? If the meaning of a named graph is tied up with relating names to >>>>> graphs, then the semantics certainly has a role there. >>>> >>>> Sorry, maybe I misunderstood what you were saying, but then I don't >>>> understand your point. >>>> >>>> What I'm saying is that, if you find a dataset somewhere in the wild, >>>> or if >>>> you have a dataset in memory, you can get the graph associated with a >>>> graph >>>> IRI by simply parsing the dataset representation. Semantics does not come >>>> into play in that case. >>>> >>>> >>>> --AZ >>> >>> Sure, you can look right in the dataset to find the graph, no semantics >>> involved. However, if RDF datasets is supposed to be able to carry some >>> meaning about graphs and their sources then shouldn't its semantics >>> actually use graphs? >> >> No, they are not supposed to carry information about the graph. That's only one use case, and we know there are people against this idea (e.g., the default as merge case). I want the common denominator that would not lead to erroneous entailments according to anybody's understanding of datasets. >> >> For metadata about graphs, provenance, dates, whatever, define a vocabulary and make sure that all applications that support the vocabulary interpret it in the same way. It has been done before and it works. >> >> >> AZ >> >>> >>> peter >>> >>> >> > > > ------------------------------------------------------------ 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
Received on Friday, 21 September 2012 18:07:28 UTC