- From: Pat Hayes <phayes@ihmc.us>
- Date: Sat, 15 Jun 2013 21:01:45 -0500
- To: David Booth <david@dbooth.org>
- Cc: Ivan Herman <ivan@w3.org>, public-rdf-comments <public-rdf-comments@w3.org>
On Jun 15, 2013, at 4:15 PM, David Booth wrote: > > > On 06/15/2013 01:44 PM, Pat Hayes wrote: >> >> On Jun 14, 2013, at 5:43 PM, David Booth wrote: >> >>> >>> >>> On 06/14/2013 06:07 PM, Pat Hayes wrote: >>>> >>>> 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. >>> >>> But I never suggested that applications be *required* to perform >>> RDF skolemization. the specification already says MAY for that, >>> and that is as it should be. the point is that if someone has >>> chosen to perform RDF skolemization, and they claim to have >>> performed RDF skolemization, then the result had damn well better >>> conform to the specification's definition of RDF skolemization! >> >> If you read it that way, then I will ask the WG to make the >> skolemization section non-normative. Thanks for the heads-up. > > *Non*-normative? that is the *opposite* of what I am requesting. > the use of RDF skolemization should be entirely optional, but the *definition* of it needs to be normative, just as the definition of RDF needs to be normative. I do not understand in what sense RFC2119 language can be applied to a definition. What behavior would we be prohibiting? Pat > > David > > >> >> Pat >> >>> and that means that the specification needs conformance terms to >>> define what *is* proper RDF skolemization. this is no different >>> than if someone claims to have written valid RDF: the specification >>> needs conformance terms to define what constitutes valid RDF. >>> >>> unless that SHOULD is changed to a MUST, the graph could be changed >>> in a very non-meta-equivalent way and it would still be considered >>> valid RDF skolemization, and that would *not* be good. >>> >>> David >>> >>> >>>> >>>>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> ------------------------------------------------------------ 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 Sunday, 16 June 2013 02:02:11 UTC