Re: Really minimal dataset semantics

Le 21/09/2012 17:44, Peter F. Patel-Schneider a écrit :
> 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.

Correct, and the proposed semantics does not prevent this. It simply 
does not tell you how to do it. We've discussed a *lot* about this 
already with Sandro and others, and being strict about what the graph 
name refers to is simply incompatible with several important use cases. 
In fact, often, people who say they want to talk about graphs do not 
want to talk about graphs, they'd like to talk about some kind of 
container of a graph, or even something else.

The case your making is not just against dataset semantics, it's against 
*any* semantics, including RDF semantics. RDF use cases include talking 
about Web addresses, RDF semantics does not support that; talking about 
Web documents, RDF semantics does not support that; talking about SPARQL 
services, no support from RDF semantics; there are cases where one wants 
to use a property as a key for certain objects, RDF semantics does not 
support it either.

There are almost no RDF use cases that are fully supported by the RDF 
semantics. And it's fine because the semantics is not *incompatible* 
with the use cases.


> 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.

So, you prefer that there is no semantics, to be absolutely certain that 
there is *no* support at all from the semantics. It does not make any sense.

>
> peter
>
> PS:  From http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs-UC I see at least
> 1.1,

Let us explore the use cases, starting with those marked "Priority A".
UC 1.1 is certainly compatible. If you want to slice the dataset 
according to programmes, access control, ownership etc, you certainly 
agree that the slices (subgraphs) are tree inside the named graphs. This 
UC is agnostic to what the default graph means or is used for.

UC 1.3, looking at the example in separate page, it's clear that what's 
true inside the graph should hold, and the way the default is used seems 
to require consistency.

UC 1.5 does not require a semantics, it's just the structure that is needed.

UC 4.9, certainly one wants to draw conclusions from the various 
sources. Additionally, I imagine that the default graph would serve to 
put metadata about trust measures etc, or the default would not be used 
and metadata be put in other named graphs. In the former case, you 
certainly want that the default is consistent.

UC 5.2, it's not clear what would be the use of the default but I can 
imagine that it would serve as the "main" ontology that exports others 
from the named graph. In that case, you certainly want that the "main" 
ontology is consistent, and that other ontologies carry the meaning that 
the OWL semantics provide.

I'll also add the crawler use case, which Sandro likes to take as an 
example. If you put the graphs inside the named graphs and the metadata 
about the graphs in the default graph, certainly you want to be able to 
draw conclusions from the default and keep it consistent. If you've 
taken the effort to gather all that data from the Web, it's certainly 
because some applications want to draw conclusions from the various data 
sources. in any case, the conclusions are not part of the dataset and do 
not prevent the crawler to faithfully transcribe what's fetched.

There are many use cases that have not been marked with a priority, so I 
don't know how important they are. In any case, I don't see how the 
proposed semantics is putting a barrier to solving those cases.


--AZ.
>
>
>
> 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
>>>
>>>
>>
>
>
>


-- 
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 Saturday, 22 September 2012 08:38:37 UTC