Re: [RDF-CONCEPTS] Skolemization

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

Received on Friday, 14 June 2013 22:43:58 UTC