- From: Pat Hayes <phayes@ihmc.us>
- Date: Fri, 14 Jun 2013 17:07:12 -0500
- To: David Booth <david@dbooth.org>
- Cc: Ivan Herman <ivan@w3.org>, public-rdf-comments <public-rdf-comments@w3.org>
On Jun 14, 2013, at 11:34 AM, David Booth wrote: > > > On 06/13/2013 08:38 PM, Pat Hayes wrote: >> >> On Jun 12, 2013, at 12:41 PM, David Booth wrote: >> >>> First off, sorry I didn't see Pat's response to Ivan before I >>> replied. More . . . >>> >>> On 06/12/2013 12:20 PM, Pat Hayes wrote: >>>> >>>> On Jun 12, 2013, at 10:53 AM, David Booth wrote: >>>> >>>>> On 06/12/2013 10:04 AM, Ivan Herman wrote: >>>>>> >>>>>> >>>>>> David Booth wrote: >>>>>>> I'd like to propose a small change in section on >>>>>>> Skolemization: >>>>>>> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-skolemization >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > Regarding: "Systems wishing to do this SHOULD mint a new, globally >>> unique IRI (a >>>>>>> Skolem IRI) for each blank node so replaced." it seems to >>>>>>> me that this conformance requirement should be a MUST -- >>>>>>> not a SHOULD -- because the system has already made the >>>>>>> free choice to skolemize. >>>>>> >>>>>> I do not follow this. Why should be a MUST? >>>>> >>>>> Because an IRI that is not globally unique would not be >>>>> logically equivalent to a bnode, and thus could significantly >>>>> change the semantics, and that would violate the intent of >>>>> skolemization. >>>> >>>> It would not be skolemization, but that's just a matter of >>>> definition. >>> >>> Right, that is my point: it would not conform to the RDF spec's >>> definition of skolemization. But if the conformance word were >>> SHOULD, then it would conform. That is why I am pointing out that >>> the conformance word should be MUST. >> >> But skolemization is not something that requires conformance. It is >> simply an operation on graphs which might be useful in some >> circumstances. > > the same can be said of entailment. Yes, exactly. And we do not use RFC2119 language there either, for the same reason. > standardization of them is important so that users have a common understanding of them. Defining them exactly, and describing their properties, is important. Saying that applications MUST do them is wrong. >> Users of RDF and RDF engines are not required to >> perform, or prohibited from performing, any operations they like upon >> RDF graphs. So the MUST language isn't appropriate here. > > no, you are mixing up two completely different concepts: I am not mixing up anything. What I said applies to *any* operations that *any* RDF application wishes to perform on RDF graphs. None of them are subject to RFC2119-style requirements or prohibitions. An RDF engine that reads in RDF, randomly permutes the IRIs in the triples and randomly deletes 10% of what it reads and replaces it with something else, is a conforming RDF engine. > 1. arbitrary application specific transformations that may do whatever they please to a graph; and 2. meta-equivalence-preserving transformations that are independent of the application domain. By "meta-equivalence" I am referring to the kind of equivalence that you described in the current RDF semantics Draft: > https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html#skolemization-1 > >> > >> > [[ > >> Nevertheless, they are in a strong sense almost interchangeable, as > >> shown the next two properties. The third property means that even > >> when conclusions are drawn from the skolemized graph which do > >> contain the new vocabulary, these will exactly mirror what could > >> have been derived from the original graph with the original blank > >> nodes in place. The replacement of blank nodes by IRIs does not > >> effectively alter what can be validly derived from the graph, other > >> than by giving new names to what were formerly anonymous entities. > >> The fourth property, which is a consequence of the third, clearly > >> shows that in some sense a skolemization of G can "stand in for" G > >> as far as entailments are concerned. Using sk(G) instead of G will > >> not affect any entailments which do not involve the new skolem > >> vocabulary. > ]] > > meta-equivalence-preserving transformations preserve the important* aspects of a graph. the resulting graph is isomorphic and retains all of the same URIs, except for skolem URIs, in the same graph positions. > in other words, it carries the same application-relevant information as the original graph. that is completely different from performing arbitrary application specific transformations. Of course, and the spec explains all this in full gory detail. Still, none of this means that any applications MUST do anything or MUST NOT do anything. Pat > > *Exercise to the reader: define "important" in this context. hint: the particular choice of each skolem URI is NOT important, provided that it is unique and recognizable as a skolem URI, so that the graph can be round tripped. > > David > >> >>> >>>> But it would not change the semantics, >>> >>> WTF??? I don't know what you were thinking when your hands typed >>> that! >> >> I meant it quite literally, but I should probably have expressed >> myself better. Yes, it does change the meaning, and it is not >> logically valid. So? >> >>>> and even a skolemization is not *logically equivalent* to the >>>> bnode version. See >>>> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html#skolemization-1 >>>> >>>> > for the full monty on skolemization. >>> >>> I meant logically equivalent in the sense explained in the >>> Semantics: >>> https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-mt/index.html#skolemization-1 >>> >>> > [[ >>> Nevertheless, they are in a strong sense almost interchangeable, as >>> shown the next two properties. The third property means that even >>> when conclusions are drawn from the skolemized graph which do >>> contain the new vocabulary, these will exactly mirror what could >>> have been derived from the original graph with the original blank >>> nodes in place. The replacement of blank nodes by IRIs does not >>> effectively alter what can be validly derived from the graph, other >>> than by giving new names to what were formerly anonymous entities. >>> The fourth property, which is a consequence of the third, clearly >>> shows that in some sense a skolemization of G can "stand in for" G >>> as far as entailments are concerned. Using sk(G) instead of G will >>> not affect any entailments which do not involve the new skolem >>> vocabulary. ]] >> >> Right, that is skolemization and why it is useful. But imagine a >> conversation like this: >> >> A reads _:x :p :a . and outputs :a :p :a . B: Wait! That is not >> skolemization! A: So? B: But if you skolemize, you MUST skolemize >> properly! A: I am not skolemizing. I don't HAVE to skolemize. B: But >> your output is not entailed by your input! A: So? And in any case, >> even if I had skolemized, it would not be entailed by my input. So >> why are you making such a fuss? B: I don't think you are being >> conformant. A: Sure I am. B: But what you output isn't justified by >> what you read in. It might be false! A: I have my reasons, of which >> you know nothing. And I stand by my assertions. All you get to do is >> read my RDF and choose to believe it or not. I say, :a :p :a ., so >> there. What you decide to do with that is up to you. >> >> And A is right. >> >> Pat >> >>> >>>> >>>>> If it were a SHOULD then >>>>> >>>>> _:b :foo :bar . >>>>> >>>>> could be changed to >>>>> >>>>> :bar :foo :bar . >>>>> >>>>> If someone makes a change like that they should not be able to >>>>> claim that the change was conformant to the RDF spec. >>>> >>>> Sure they can. It *is* conformant with the spec, in fact. Its not >>>> a logically valid entailment, but users are not prohibited from >>>> making non-valid inferences in RDF. The user might happen to >>>> know, for out-of-band reasons, that the _:b is in fact this :bar >>>> guy. >>> >>> You are really going to confuse people if you say things like that. >>> Skolemizing >>> >>> _:b :foo :bar . >>> >>> into >>> >>> skolem:b :foo :bar . >>> >>> (where skolem:b is a skolem URI) is *completely* different from >>> changing it into >>> >>> :bar :foo :bar . >>> >>> The former "does not effectively alter what can be validly derived >>> from the graph", whereas the latter obviously does. >>> >>> David >>> >>>> >>>> Pat >>>> >>>> >>>>> >>>>> Bear in mind that the decision to perform the skolemization is >>>>> still optional -- it's a MAY. The MUST only kicks in after >>>>> they have made that choice: if they choose to do it they MUST >>>>> do it properly. >>>>> >>>>> David >>>>> >>>>>> >>>>>> Ivan >>>>>> >>>>>> >>>>>>> >>>>>>> Specific wording changes that I suggest: >>>>>>> >>>>>>> 1. Change: >>>>>>> >>>>>>> "Systems wishing to do this SHOULD mint a new, globally >>>>>>> unique IRI (a Skolem IRI) for each blank node so >>>>>>> replaced." >>>>>>> >>>>>>> to: >>>>>>> >>>>>>> "Systems choosing to do this MUST mint a new, globally >>>>>>> unique IRI (a Skolem IRI) for each blank node so replaced. >>>>>>> Each such Skolem IRI SHOULD conform to the syntactic >>>>>>> requirement for a well-known IRI [WELL-KNOWN] with the >>>>>>> registered name genid. This is an IRI that uses the HTTP or >>>>>>> HTTPS scheme, or another scheme that has been specified to >>>>>>> use well-known IRIs; and whose path component starts with >>>>>>> /.well-known/genid/." >>>>>>> >>>>>>> 2. Delete the paragraph: [[ Systems that want Skolem IRIs >>>>>>> to be recognizable outside of the system boundaries should >>>>>>> use a well-known IRI [WELL-KNOWN] with the registered name >>>>>>> genid. This is an IRI that uses the HTTP or HTTPS scheme, >>>>>>> or another scheme that has been specified to use well-known >>>>>>> IRIs; and whose path component starts with >>>>>>> /.well-known/genid/. ]] >>>>>>> >>>>>>> Thanks, David >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> ------------------------------------------------------------ >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> ------------------------------------------------------------ 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 >> >> >> >> >> >> >> >> > > ------------------------------------------------------------ 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 Friday, 14 June 2013 22:07:38 UTC