W3C home > Mailing lists > Public > public-rdf-comments@w3.org > June 2013

Re: [RDF-CONCEPTS] Skolemization

From: Pat Hayes <phayes@ihmc.us>
Date: Sat, 15 Jun 2013 21:01:45 -0500
Cc: Ivan Herman <ivan@w3.org>, public-rdf-comments <public-rdf-comments@w3.org>
Message-Id: <9496375A-AAAA-4FBA-A9F4-54C0321DC95C@ihmc.us>
To: David Booth <david@dbooth.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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:57 UTC