- 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