Re: RDF Semantics: two issues, connected to OWL

>  >>Could it be that the PR version of RDF Semantics is not the
>>>proper version?
>>
>>Well, it is the version intended. Whether it is 'proper' in some
>>broader sense remains to be seen, of course.
>>
>>>It seems that some changes that you describe below are not
>>>in the document.  See below.
>>
>>Apart from one mistake, noted below, I believe all the requested
>>changes have been made or responded to.
>
>There are two requested changes in [1], for which your response
>was that they were made, although they have not been made.
>See below.
>
>>
>>>(I could not check this with an earlier version of the
>>>document; the editorial version was not updated when you wrote
>>>your last mail, and there was no pointer to new document text
>>>in your last mail.)
>>
>>Yes. I am sorry that we were unable to circulate this in advance. We
>>were at the time in the very throes of the publication process, and
>>it was impossible to delay it sufficiently to review the changes.
>>
>>>
>>>>>[...]
>>>>>
>>>>>>>
>>>>>>>Issue 1- It seems that two changes made to RDF Semantics
>>>>>>>during LC2 have not yet been incorporated completely
>>>>>>>in the definition of D-interpretations.
>>>>>>
>>>>>>As already remarked in earlier messages: that I regard as a typo, and
>>>>>>plan to get it changed before final publication , if the process will
>>>>>>allow it.
>>>>>
>>>>>Without going into the meaning of the word typo, I would only like
>>>>>to note for clarity that I added two changes in my previous message,
>>>>>to the change about which you remarked in [5] that you regard it as a
>>>>>typo.
>>
>>Yes, I know you did. I thought I had made it clear in my response
>>that I did not accept the 'large' change you suggested there (your
>>'issue 2' in [1].)  That is why that change has not been made.
>
>This is not related to the 'large' change of 'issue 2'.
>When you indeed responded that you did not accept the change of issue 2
>(to move the XMLLiteral semantic conditions from the basic requirements
>on RDFS interpretations, in Sections 3 and 4, to become an optional
>datatype that might be included in datatype maps), I mentioned that
>this discussion about XMLLiteral would be continued in WebOnt.
>(This discussion has not yet finished there; see, for example,
>[2] and [3].)

I hope that an appropriate settlement can be reached there.

>The "two changes" that I mentioned belong to 'issue 1', and not to
>'issue 2'.
>See below.
>
>>
>>>   >
>>>>If I regard it as a typo, then I can consider the change to be
>editorial
>>>:-)
>>>>
>>>>I have made those changes to the final version of the document,
>>>
>>>Unlike the last statement suggests, I cannot find the "two changes"
>>>that I mentioned above, from [1], in the document dated 15 December.
>>
>>I was referring only to the changes referred to in your 'issue 1' in
>>[1].  Insofar as I had understood the import of your messages on this
>>topic, I had made changes in response to them.
>
>Below I try to give further explanation of the two changes in 'issue 1'
>that have not been made.

I see now the points that I had missed.

>
>>
>>>These two changes were left over as part of changes from LC2 that
>>>were not yet complete:
>>>1) the omission of the terminology "from V" as opposed to "in V"
>>
>>?? That terminology is not used in the document, I believe, except in
>>a context of normal English usage of the word "from". No special
>>technical meaning is given to the phrase, in any case.
>
>This is the first of the two changes not made.
>The point is here that it is not guaranteed in line 1 of the
>definition of D-interpretations that the expression I(aaa) is defined,
>since it is not explicitly assumed that aaa is in V.
>Therefore, I suggested below to correct line 1 as follows:
>--if <aaa,x> is in D then [aaa in V and] I(aaa)=x
>(I made the connection with the terminology "from V" because
>there was a time when the RDF Semantics document did give
>special technical meaning to the phrase.  It seems that I confused
>the matter by mentioning this connection.)

Apparently so; I apologize for missing this part of your point. I 
agree it might be slightly clearer with the addition, but in fact it 
is not likely to give any cause for misunderstanding in practice. And 
since the notion being defined is a D-interpretation, where D itself 
assigns the names to the datatypes, it is not in fact unreasonable to 
require that the datatype names are interpreted even if the URIs are 
not part of the given vocabulary. So I accept that this addition to 
the text would be an improvement, I do not feel that this is worth, 
as it were, stopping the presses for (even if the presses could be 
stopped, which they cannot at this stage.)

>
>>
>>>and
>>>2) the change not to require all possible literal values in LV
>>>- these changes are not yet incorporated in the definition of
>>>D-interpretations.
>
>This is the second of the two changes not made.  The point is here
>that it is assumed in line 2 of the definition of D-interpretations
>that the entire value space of each datatype in D is contained in LV,
>and thereby in IR.  As was seen in LC2, an analogous assumption
>in simple and RDFS interpretations led to severe problems in the
>proof of the RDFS entailment lemma, while such a strong assumption
>is used nowhere.

It certainly led to awkwardness in the proof, and as you say is not 
in fact used.

>During LC2, this was changed for each of the
>other kinds of interpretations (simple, RDF, RDFS), but not for
>D-interpretations.  Therefore, I made this comment.
>As I also remarked in [1], to weaken this assumption on
>D-interpretations would be in line with the general spirit
>of the document to keep definitions as general as possible, so
>that semantic extensions, such as OWL, have the largest freedom to
>make more specific assumptions.
>Moreover, I noted in [1] that making such a change would enable
>a useful generalization of the RDFS-entailment lemma that includes
>datatypes.
>
>I did not make a concrete suggestion for changing line 2 of
>the definition of D-interpretations because it seemed to be preferable
>to editorially reword the definition as described below, to make the
>correspondence to the semantic conditions on XMLLiteral clearer.

I am afraid that I may have missed this part of your comment as when 
I read [1] this all seemed to be 'bundled' with a more extensive 
proposal to rewrite the notion of RDF entailment so as to reduce 
rdf:XMLLiteral to a normal datatype. This more extensive proposal is 
a major design change which is not acceptable, for a number of 
reasons; so I am afraid that I did not extract, as it were, the part 
of it that stood alone on its own merits as a simple editorial 
improvement to the existing wording.

I agree with you that this small modification - weakening the rdfD 
semantic conditions so as to apply only to literals in the vocabulary 
- would be an improvement to the document. At this stage I will 
consider this to be an error to be corrected at the first opportunity 
available for correcting errors.

>
>>>For example, line 1 of the definition would need change as follows:
>>>--if <aaa,x> is in D then [aaa in V and] I(aaa)=x
>>
>>No, aaa here is the datatype name, not a literal.  The only change
>>that was required was made, in line 3 of the definition, the
>>inclusion of 'in V'; as indeed you suggested in your original
>>comment, as I recall.
>
>As I said, it also seems necessary to make this change to line 1,
>since otherwise the expression I(aaa) is not guaranteed to be defined.
>(Compare several other places in the document.)

That point is now clear, though it was not previously. However, it is 
also possible to interpret this condition as it stands as a 
requirement that the vocabulary of a D-interpretation must contain 
all the datatype names in D.

>  >
>>>
>>>However, instead of making such local changes to the definition,
>>>I suggested to implement these changes by editorially rewording
>>>the definition of D-interpretations so that it is more obvious
>>>that the XMLLiteral conditions, from Section 3 (i.e. two RDF
>>>semantic conditions) and Section 4 (i.e. two RDFS axiomatic triples),
>  >>form a special case.
>>>As I pointed out in [1], this would enable a generalization of the
>>>RDFS entailment lemma to include datatypes.  Even though such a
>>>generalized
>>>lemma is not in the RDF Semantics document, it could become useful.
>>>I included a suggestion for such a rewording in [1]:
>>>
>>>HtH>Given a datatype map D and a vocabulary V, a D-interpretation
>  >>>of V is an rdfs-interpretation of V

should be: rdfs-interp of V union {x: <x,d> in D for some d}, i.e. 
treat the dtype names as logical vocabulary.

>such that for all
>>>><a,d> in D we have:
>  >>>- a in V and

omit. Since V is *given*, one cannot, speaking strictly, impose 
conditions on its membership. See previous suggestion.

>I(a) = d
>  >>>- I satisfies the triples
>>>>      a type Datatype
>>>>      a subClassOf Literal
>>>>- if l=s^^a is a typed literal in V and s in L(d),
>>>>    then IL(l)=L2V(d)(s) in LV  and  <IL(l),d> in IEXT(I(type))
>>>>- if l=s^^a is a typed literal in V and s not in L(d),
>>>>    then IL(l) not in LV  and  <IL(l),d> not in IEXT(I(type)
>>>
>>
>>Yes, and I thank you for the suggestion. We did not use it because we
>>were trying to keep changes to the document, even textual changes, to
>>a minimum.
>>
>>>
>>>
>>>PatH>as
>>>>well as inserting the required 'extra' rule (christened rule gl and
>>>>defined immediately after rule lg in the document, with a short
>>>>explanation) and other small modifications as required in the rdfs
>>>>entailment lemma proof.
>>>>
>>>>
>>>
>>>Remark:
>>>it seems that the editorial work is not yet entirely complete, as
>>>the two statements of the RDFS entailment lemma differ.
>>>The appendix version does not yet include gl in its statement.
>>
>>Whoops, that is indeed an editorial slip, mia culpa. At this point it
>>will have to be registered as an error, and corrected later.
>>
>
>Herman
>
>>>
>>>[1]
>  >>http://lists.w3.org/Archives/Public/www-rdf-comments/2003OctDec/0233.html
>
>[2] http://lists.w3.org/Archives/Public/www-webont-wg/2003Dec/0068.html
>[3] http://lists.w3.org/Archives/Public/www-webont-wg/2003Dec/0095.html

Pat

-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Friday, 19 December 2003 19:10:03 UTC