Re: [RDF-CONCEPTS] Skolemization

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.

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
>
>
>
>
>
>
>
>
>

Received on Saturday, 15 June 2013 21:15:33 UTC