Re: Really minimal dataset semantics

I really don't think that this is converging.

I maintain that to talk about actual graphs or actual containers of actual 
graphs, the semantics (and entailment) has to be able to distinguish actual 
graphs or actual containers of actual graphs. Neither of the minimal semantics 
proposals does this.  Sure, you can access the graphs in a dataset, but the 
semantics doesn't provide any support.

peter

On 09/22/2012 04:37 AM, Antoine Zimmermann wrote:
> 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
>>>>
>>>>
>>>
>>
>>
>>
>
>

Received on Saturday, 22 September 2012 11:40:45 UTC