- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 1 Mar 2012 09:45:15 -0600
- To: Antoine Zimmermann <antoine.zimmermann@emse.fr>
- Cc: public-rdf-wg@w3.org
On Feb 29, 2012, at 5:14 AM, Antoine Zimmermann wrote: > > > Le 29/02/2012 04:37, Pat Hayes a écrit : >> >> On Feb 28, 2012, at 11:50 AM, Antoine Zimmermann wrote: >> >>> As it is good to get down to earth with use cases, I'll start with >>> the following case: >>> >>> [2] would simply consider the 2 graphs to be independent because >>> possibly, you do not trust :g3 and it's a malevolant piece of RDF. >>> So, there would not much entailment, even assuming OWL entailment >>> inside each graphs. >> >> No. Look, we agreed on this in an earlier exchange: trust is one >> topic, truth is another. Suppose you dont trust :g3. Still, what :g3 >> actually says is what it is, whether or not you trust it. Your >> trusting it or not does not change what it says about the world; in >> fact, you may mistrust it *because* of what it says about the world >> (eg because that is wildly inconsistent with something else you >> believe to be true.) Refusing to believe it does not change what it >> means, or what it is claiming (ie what the world would have to be >> like IF it were true, which of course you don't believe it to be.) >> And refusing to accept it does not change any entailments it has. >> Maybe you refuse to accept the conclusions of those entailments, of >> course, since you don't accept their antecedent, but that does not >> change the actual entailment relationship between them (which is all >> that the semantics cares about). One being equal to zero entails that >> I am the Pope. I don't believe either of these propositions, but I >> don't need to deny the actual entailment. > > I rely on the trust example just to explain *why* this model is proposed. I maintain that it is orthogonal to what the semantics says, but sometimes I must rely on examples of what happens in a concrete system, to justify the choices. Sorry, but that simply does not make sense. If these topics are orthogonal, then using one to illustrate the other does not get the job done, since one of them has nothing to do with the other (which is what we mean by saying they are orthogonal.) So, try telling me a *semantically relevant* reason why this *semantic* model is being proposed. > It could have been an example with temporal information. It's just to say that there are actual sensible cases when you really don't want that one graph influence the reasoning of another one. Fine. But you really dont need to say anything about semantics for this. If you don't want one graph to influence another one, just don't give them both to a reasoning engine: give it one and not the other. Nothing in any semantics says that you *must* take everything into account. > E.g.: > > :g1 {:joe a :Child; :age 10 } > :g2 {:joe a :Adult; :age 30 } > :g3 {:Child owl:disjointWith :Adult } > >>> >>> However, if an application is using an internal ontology which >>> happens to contain the triple : >>> >>> :age a :FunctionalProperty . >>> >>> that application may decide that it must be merged with any other >>> graphs it indexes. Then the same application meets a document with >>> the triple : >>> >>> :Joe :age 10 . >>> >>> It mints a URI to put it in a "named" graph (say, :g1) then it >>> meets another graph later on: >>> >>> :Joe :age 20 . >>> >>> It mints a new URI (say :g2). Since the application already have >>> its internal ontology which it decides to merge with any graph, the >>> following dataset will be contained in that app RDF store: >>> >>> :g1 { :Joe :age 10 . :age a :FunctionalProperty .} :g2 { :Joe :age >>> 30 . :age a :FunctionalProperty .} >>> >>> This leads to a lot of duplication of course, but it's trivial to >>> optimise this without repetition. Then you have both assertional >>> data and terminological data in the same "named" graph, so you can >>> do useful inferences, which won't affect consistency globally. >> >> Im not sure what the point of this is. Yes, you can build something >> that will act in this way, clearly. I don't know why you would want >> to, but you could. But what has any of this got to do with semantics >> and entailment? > > I'm trying to be pragmatic. I want to show concretely how to use datasets (the syntactic structure) in such a way that the semantics will bring useful inferences. But you havent said anything here that involves any inferences that are not sanctioned directly by the current 2004 RDF semantics. So why propose any changes or extensions at all? If this is all we have to contend with, we can just leave the current specifications alone without changing them in any way, and everything will work fine. > With a superficial look at the semantics it may seem that all graphs ever found or built will be put in distinct "named" graphs and thereby, no useful inferences will ever occur. This is not true: it depends on what you are willing to merge or not and on also how semantic extensions are specified. > > Here, I can say that :g1 says that :Joe has :age 10 and that :age is functional; and that :g2 says that :Joe has :age 30 and that :age is functional too. According to the semantics of [2], maybe :Joe in :g1 is not the same thing as :Joe in :g2, but at least I know that in both cases, :age is functional and I can do inferences based on that. You can do exactly this just referring to the 2004 RDF semantics. You don't need anything extra to justify this semantically. And it can even be done with :Joe referring to the same thing in both graphs. There simply isnt a problem here that needs anything to be done to solve it. Pat > If one really wants to require that the two :Joe denote the same thing, that would require extending the semantics of [2]. > > > AZ. > >> >> Pat >> >>> >>> >>> AZ. >>> >>> Le 28/02/2012 17:51, Andy Seaborne a écrit : >>>> >>>> >>>> On 28/02/12 16:41, Ivan Herman wrote: >>>>> >>>>> On Feb 28, 2012, at 17:19 , Andy Seaborne wrote: >>>>> >>>>>> Pat, >>>>>> >>>>>> The fact you can have >>>>>> >>>>>> :g1 { :Joe :age 10 } :g2 { :Joe :age 30 } :g3 { :age a >>>>>> :FunctionalProperty } >>>>>> >>>>>> is the point. It's not about graph consistency until the app >>>>>> decides it wishes to apply RDF machinery to some combination >>>>>> of :g1 :g2 and :g3. How it does that is not spec'ed - it >>>>>> would be nice if it were, but given timescales, state of the >>>>>> art, etc, it's where the deployed semweb currently is. >>>>> >>>>> But this also means that [2] does not work for that case, >>>>> right? The 'right' way, according to [2], would be to add the >>>>> func. property triple into both :g1 and :g2. >>>> >>>> Pat's example was 3 different graphs. An app can decide to use >>>> the :g3 ontology is useful and that it thinks :g1 and :g2 have >>>> used it correctly. It can then use it with :g1 or on :g2 if it >>>> wants. Using on :g1 union :g2 is not good. This is a decision the >>>> app makes before the formal systems kick in. >>>> >>>> Andy >>>> >>>>> >>>>> Ivan >>>>> >>>>> [2] >>>>> http://www.w3.org/2011/rdf-wg/wiki/TF-Graphs/RDF-Datasets-Proposal >>>> >>>> >>> >>> >>>>> > -- >>> 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/ > > ------------------------------------------------------------ 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 Thursday, 1 March 2012 15:45:55 UTC