Re: different Semantics proposals (Re: Agenda for 19 Sep 2012)

Le 18/09/2012 15:27, Peter F. Patel-Schneider a écrit :
>
[skip]
>
> OK, so you are referring to the part of the semantics where it is the
> denotation of the graph names in the default graph that is used as the
> start of the mapping to the named graph itself. I am against this
> because there can be strange bleeding from the default graph to the
> identity of the named graphs, such as in example 2.16 in
> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Minimal-dataset-semantics
> although the analysis there is incorrect.
>
> if all you are dong is recording named graphs, then why should
> information in the default graph potentially cause two named graphs to
> be smushed together?

This issue is addressed in:

http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/Minimal-dataset-semantics#DD4:_Does_the_graph_extension_assign_graphs_to_resources_or_to_IRIs.3F

that is, IGEXT maps IRIs to graphs instead of resources to graphs.
This, however, does not solve your requirement that the (in)consistency 
of the default graph does not impact the (in)consistency of the dataset.


>>> (1) Even if you used an empty default graph, you get some carry-over
>>> into the named graphs. For example, the named graph resources can
>>> only be taken from the resources in this interpretation. Fortunately
>>> (or unfortunately) all RDF interpretations are infinite, so there
>>> probably are no observable consequences.
>>>
>>> But in any case, why should I be forced into turning my default graph
>>> into a named graph (with some arbitrary name) and adding an empty
>>> default graph?

Would you be able to address your own requirements and my own 
requirements with a mathematically sound and complete proposal that 
defines a notion of dataset interpretation?

I summarise your requirements as: entailment can be performed completely 
separately between named graphs and default graphs, and nothing can make 
a dataset inconsistent.
My requirements are summarised as followed: if G  E-entails  G' 
according to a RDF graph entailment regime E, then:

  { G }  E-dataset-entails  { G' }

and for all IRIs n:

  <n> { G }  E-dataset-entails  <n> { G' }

?

I can see solutions for this, but they are not elegant at all.


>>>
>>>
>>> One interesting use of RDF datasets is to collect information from
>>> the web. The named graphs record the source of the graphs and their
>>> contents. The default graph can either be related to these collected
>>> graphs or unrelated to them. Having the default graph affect the
>>> meaning of the named graphs is undesired.
>>>
>>
>> I don't see how you can usefully communicate collected information
>> like that unless you have a private protocol arranged (in which case
>> this is all moot), or you use the default graph for metadata.
>>
>> -- Sandro
>>
>
> I would turn this question around and ask how the current minimal
> semantics can be used for the same purpose.
>
> I also don't see why excluding useful private ways of doing things
> (particularly ones that might already be in use) is moot.

Privately, applications and people can do what they want. It's only when 
they communicate to the world that they have to follow interoperable 
practices.  Take the OWL standard: its semantics prevents people from 
doing complete reasoning on world wide collected data (Web data, as a 
whole, is inconsistent).  Yet, there are applications that reason with 
merged collected data that are OWL inconsistent, and still provide 
useful results.  Fair enough.

Now, with datasets, there can be any kind of internal recipes, but what 
we are saying with this proposal is that the default graph should be 
considered "asserted", and if you are asserting contradictory things, 
what you say is globally inconsistent. The named graphs, however, are, 
sort of, "quoted" because what they say does not impact the truth of 
what you say.

In a situation where a triple store is internally using the default 
graph to put the merge of all named graphs, and that merge is 
inconsistent, the system should be careful when exposing its dataset to 
other systems.  It can either make it available as is, with the 
understanding that it may get rejected by conformant software, or only 
expose the named graphs, without the merge put in the default.

At the moment, I'm convinced there are many private ways of doing 
things, but I don't think there are many exchange of datasets between 
systems, such that the need for a sanctioned semantics have been 
limited. But we see a number of use cases that are either happening 
right now, or that are going to appear inevitably, which requires a 
common understanding of what dataset semantics is.

Of course, we want the least common denominator such that as many 
current practices as possible are conforming.

But we may also make bold decisions that prevent what we consider bad 
practices, even if it breaks some implementations.


-AZ

> I didn't exclude using the default graph to record information about the
> named graphs and their sources. However, I didn't want information in
> the default graph to affect the situation in the named graphs.
>
> 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 66 03
Fax:+33(0)4 77 42 66 66
http://zimmer.aprilfoolsreview.com/

Received on Tuesday, 18 September 2012 16:26:41 UTC