W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2003

Re: RDF Semantics: use of functions IEXT / ICEXT

From: <herman.ter.horst@philips.com>
Date: Wed, 26 Feb 2003 17:07:43 +0100
To: pat hayes <phayes@ai.uwf.edu>
Cc: www-rdf-comments@w3.org
Message-ID: <OFA5011C92.AAFAA1F7-ONC1256CD9.0055D0C6-C1256CD9.0058C2D3@diamond.philips.com>

>>RDF Semantics document,
>>last call version, 23 january 2003
>>These comments were mailed earlier to the WebOnt WG [1].
>This response extends and corrects my earlier reply.
>>A consequence of the (new) setup of the RDF semantics
>>is that for each occurrence of IEXT(x) or ICEXT(x), it
>>should be clear that x is in the domain of the function
>>involved.  (For IEXT, this domain is the set IP.
>>For ICEXT, the domain is the set IC; compare my
>>other comment on this to rdf-comments [2].)
>>For example, in Section 3.3 the semantic conditions on
>>subClassOf and subPropertyOf take care of this explicitly.
>>It seems that this point is not taken care of completely
>>consistently throughout the document.
>After checking the various cases, I believe that the semantic 
>conditions as stated completely define all the relevant domains and 
>>In Section 3.1, RDF interpretations,
>>in the table defining an rdf-interpretation, IEXT(I(rdf:type))
>>is used before it is clear that I(rdf:type) is in the
>>domain of this function (i.e., the set IP).
>>Switching the first two lines of this table would remedy this.
>>Similarly, it seems appropriate to move the semantic
>>conditions on IC and IP in Section 3.3:
>>>  IC contains ...[many items]
>>>  IP contains ...[many items]
>>to become the first conditions, as each of the other
>>conditions in this table actually uses one or more of these
>Done. For the record, I do not regard the order of these items as 
>significant or meaningful.
>>The semantic conditions on rdfs:range and rdfs:domain in Section 3.3
>>do not yet incorporate explicit domain assumptions as just
>>discussed.  It seems that additions such as the following need
>>therefore to be made:
>The additions suggested are not required, since they follow from the 
>axiomatic triples in the next table and the other conditions on range 
>and domain.
>It is probably easiest to express the reasoning in terms of triples 
>that must be satisfied by an interpretation I. For example, suppose 
><x,y> is in IEXT(I(rdfs:range)), ie that
>I |= (x) rdfs:range (y)

I do not understand this step.  In these two lines x/y have a different
origin.  In "<x,y> is in IEXT(I(rdfs:range))", x and y are in IR.
In the triple "(x) rdfs:range (y)", x and y are uri's or blank nodes
(y may also be a literal).  So this conclusion ("ie that")
is not clear.

>Now, since
>I |=  rdfs:range rdfs:domain rdf:Property .  (axiomatic triple)
>  it follows by the semantic condition on rdfs:domain that
>I |= x rdf:type rdf:Property .
>ie, by the basic condition on IP, that x is in IP.

>Similar reasoning using a different axiomatic triple shows that y 
>must be in IC.
>>If <x,y> is in IEXT(I(rdfs:range))
>>[then x is in IP and y is in IC] and
>>[if, in addition,] <u,v> is in IEXT(x) then
>>v is in ICEXT(y)
>>If <x,y> is in IEXT(I(rdfs:domain))
>>[then x is in IP and y is in IC] and
>>[if, in addition,] <u,v> is in IEXT(x) then
>>u is in ICEXT(y)
>>The last call versions of these statements (i.e., this text
>>without the [...]-additions) seem to be
>>remnants from the April 2002 version of the RDF MT, where
>>IEXT as well as ICEXT had all of IR as their domain.
>>Herman ter Horst
>>Philips Research
>>[1] http://lists.w3.org/Archives/Public/www-webont-wg/2003Feb/0067.html
>>[2] http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0348.html
>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@ai.uwf.edu                         http://www.coginst.uwf.edu/~phayes
>s.pam@ai.uwf.edu   for spam
Received on Wednesday, 26 February 2003 11:09:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:15:20 UTC