W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2012

Re: Reconciliation of concerns, re islands and dataset semantics?

From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
Date: Fri, 02 Mar 2012 15:42:44 +0100
Message-ID: <4F50DC64.8030905@emse.fr>
To: public-rdf-wg@w3.org


Le 01/03/2012 18:16, Pat Hayes a écrit :
> A quick comment on part of this exchange (sorry, dont have time to
> respond to it all right now):
>
> On Mar 1, 2012, at 6:31 AM, Antoine Zimmermann wrote:
> [snip]

>>>>
>>>> This certainly works as a logic, but the question is whether
>>>> it addresses the use cases dealing with multiple graphs. Take
>>>> the case when I want to have the following information:
>>>>
>>>> :x thinks that { :a owl:sameAs :b } :y thinks that { :a
>>>> owl:differentFrom :b }
>>>>
>>>> which could be reformulated in :x endorses the first graph, :y
>>>> endorses the other graph, or the document at :x contains the
>>>> first graph, the one at :y contains the second, or again, a
>>>> SPARQL dataset contains the two graphs respectively "named" :x
>>>> and :y.
>
> These are *different* meanings. IMO, we should be distinguishing them
> and providing distinct ways to represent them, if indeed we are
> setting out to represent them at all. Because otherwise (as Sandro
> emphasised in the telecon) interchange of information expressed in
> this way will produce confusion.

Yes, they have different meanings, but they have something in common: 
they must separate the triples into distinct, identifiable graphs. 
Dataset allows this at the syntax level. The semantics ensures that 
there are no unintended interactions between facts asserted in different 
contexts. Maybe people *want* interactions, like they may want several 
triples to be combined to draw a new conclusion in RDF. In this case, 
they would use a more constrained extension of the semantics, just as 
they would use an extension of the RDF to draw interesting conclusions.

Let me take a pretty informal example that maybe will shed light on 
this. Imagine we have two sets of statements, that we will index with 
:rdf and :g-theory respectively.

:rdf {  Graphs are sets of triples. X is a graph.}
:g-theory { :Graphs are pairs. Y is a graph. }

The content of :rdf and the content of :g-theory, taken individually, 
are consistent. However, if you read the contents together, as if they 
were in the same context (e.g., both are in a W3C spec) then the 
statements are contradicting. But if you take a step back and look at 
the global knowledge that you have, there is absolutely no 
contradiction. It simply says that "in RDF, graphs are sets of triples 
and in graph theory, graphs are pairs". Here, :rdf certainly denotes a 
topic, or a field, but it could as well denote a time point or a time 
frame, or an opinion, or a provenance. I could equally say "in the time 
frame associated with :rdf, graphs are set of triples, while in the time 
frame associated with :g-theory, graphs are pairs.

The way we specify whether it is temporal or anything else is a 
different story, and we are not chartered to do so, so I would only 
expect that the WG gives examples of possible ways, without making 
anything normative in that direction.

However, no matter the "type" of context, there is this point in common: 
that the graphs must be splitted at the syntactic level, and that 
different interpretations of the contents of the "named" graphs should 
be allowed, to some extent (my proposal is the one which is the most 
liberal in that respect, but a proposal where URIs are interpreted 
identically across graphs could be proposed too).


> And, a prior point, we need to be clear as to whether we are indeed
> intending to use datastores to REPRESENT such things as beliefs,
> endorsements, provenance information and/or contextual assertions
> like time-dependent archives. Not that they get used internally in
> some applications in these ways (not our concern) but that the RDF
> standard endorses and specifies how to use them publicly as an
> information exchange notation in these ways. FWIW, I think it is
> worth doing this for time-indexing, as it is relatively easy and
> uncontroversial how to do it (I say RELATIVELY) and there is an
> obvious need for it. I think the other cases are both more obscure
> and less necessary. Just to have several graphs in a store and keep
> their conclusions separated does not require any new semantics at
> all, and so if that is all we want to do, we should not be talking
> about semantics.

Things like beliefs, endorsements, provenance, etc, are just examples 
that justify the need to split graphs. We can cite these as such without 
being obliged to propose a normative way to deal with them.


AZ

>
>>>>
>>>
>>> If (:a owl:sameAs :b) and (:a owl:differentFrom :b) appeared in
>>> the same graph, then an OWL reasoner, using the definition of
>>> the predicates, would deduce that there is a inconsistence. I
>>> mean: the triples themselves are just fine, it is up to a
>>> reasoner to find the problem.
>>>
>>> If they are in different graphs, then the inconsistence would
>>> not occur, because we only care about the models in separate
>>> graphs, independently from one another.
>>
>> Hmm, this seems to contradict what you said above. If URIs are
>> interpreted identically in all graphs with overlapping
>> vocabularies, how can :a be interpreted as the same thing as :b and
>> at the same time as something different then :b? Either you have an
>> inconsistency, or you interpret the URIs differently in the two
>> graphs.
>
> Yes, exactly. The inconsistency is there in RDF. Whether or not a
> reasoner decides to do anything about it is up to the application,
> but nothing is gained by putting the semantics' head in the sand so
> it can't see the inconsistency. OR, we can say there really is *not*
> an inconsistency here because these separate graphs are asserted in
> different contexts (maybe :a and :b merged at time :t), then we need
> a genuinely contextual model theory which shows how to express things
> likwe this clearly, and treat (some?) datasets as having this
> extended meaning, a different meaning than simply a bundle of RDF
> graphs. But we shouldnt haver and try to do two things at once or
> tell people to do two different things in the same way.
>
>
> Pat
>
>
>>
>>> [...]
>>>
>>>>
>>>> Now, if you want to do temporal reasoning, provenance, trust,
>>>> it's more complicated. But the fierceful rejection by Pat on
>>>> the mere idea of a multi-interpretation semantics has deviated
>>>> the discussion away from these issues.
>>>
>>> And I do not think this working group should deal with temporal
>>> reasoning, provenance, or trust. Just giving the basis in terms
>>> of that semantics is what should be done.
>>
>> I do not mean the WG should provide a standard for temporal
>> reasoning etc. I just mean that we have to analyse these use cases
>> in light of the various options we have for defining a semantics of
>> datasets/quads/multiple-graph structure.
>
> I really dont follow your thinking here. Are these use cases or not?
> IF they are, then surely the standard needs to address them as such
> and handle them properly. Or, if they are not, then we need to tell
> people to not rely on the standard to do these things, and they are
> running at their own risk if they do so. I dont feel that we are
> facing up to the decisions we need to make. In a nutshell: if these
> really are use cases, then we DO need to provide a standard for
> temporal reasoning (etc.) Or, if we decide we aren't doing that, then
> these are not use cases so much as misuse cases.
>
> Pat
>
>>
>>> [...]
>>>>
>>>> True, but this is difficult to put in the formal semantics as
>>>> model theory is only interested in what is true from a given
>>>> logical theory. It does not normally deal with behaviour, what
>>>> an application should *do*. That is why owl:imports does not
>>>> have a particularly constraining model theoretic semantics. The
>>>> mechanism behind owl:imports is defined outside the semantic
>>>> documents.
>>>
>>> I *think* I understand what you say, and it does not seem to
>>> contradict what I said: what, say, rdf:GETSemanticClass means is
>>> defined outside the model theoretic semantics. That is what I
>>> meant at least.
>>
>> Then we are on the same page. Good.
>>
>>>
>>> Ivan
>>>
>>>>
>>>> Similarly, we can very well define mechanisms that have no
>>>> representation in terms of model theory.
>>>>
>>>>
>>>>> Now is my turn to be torn apart by Pat:-)
>>>>
>>>> Good luck ;)
>>>>
>>>>
>>>> AZ
>>>>
>>>>>
>>>>> Ivan
>>>>>
>>>>> ---- Ivan Herman, W3C Semantic Web Activity Lead Home:
>>>>> http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF:
>>>>> http://www.ivan-herman.net/foaf.rdf
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> -- 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/
>>>>
>>>
>>>
>>> ---- Ivan Herman, W3C Semantic Web Activity Lead Home:
>>> http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF:
>>> http://www.ivan-herman.net/foaf.rdf
>>>
>>>
>>>
>>>
>>>
>>
>>
>> -- 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/
>>
>>
>
> ------------------------------------------------------------ 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
>
>
>
>
>
>
>

-- 
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 Friday, 2 March 2012 14:43:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:47 GMT