W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > December 2003

Re: Semantics document, new rule 'gl'

From: pat hayes <phayes@ihmc.us>
Date: Tue, 16 Dec 2003 06:48:54 -0800
Message-Id: <p06001f02bc04c7155ebe@[192.168.1.11]>
To: Graham Klyne <gk@ninebynine.org>
Cc: w3c-rdfcore-wg@w3.org

>I'm just looking at recent changes to the semantics document, and 
>wish to (a) check my understanding, and (b) suggest a possible 
>clarification for the errata and next round.

Yeh, it would be nice to get the idea across more clearly. To do so 
would have needed a bigger rewrite that would have been acceptable as 
editorial, at this stage.

>
>I refer to rule 'lg' in the document at:
>   http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/
>at 15-Dec-2003, self-described as:
>
>[[
>RDF Semantics
>W3C Working Draft @@ November 2003
>
>This Version:
>     http://www.w3.org/TR/2003/WD-rdf-mt-@@/
>]]
>
>In section 7.1 
>(http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/#simpleRules 
>there is a new rule 'lg', which says:
>
>[[
>[rule name] gl
>
>[if E contains] uuu aaa _:nnn .
>where _:nnn identifies a blank node allocated to the literal lll by rule lg.
>
>[then add] uuu aaa lll .
>]]
>
>My first reaction was that this new rule is redundant, but now I 
>think that "[if E contains] uuu aaa _:nnn ." must refer to some 
>property URI aaa other than that which was used by the use of rule 
>lg to allocate _:nnn to lll.

It happens as follows:

p range class
a p "foo"     ;; now the literal "foo" has to be a class ;;

|=

_:x subclass "foo"  ;;because, being a class, "foo" is a subclass of itself ;;

Rule lg generates the _:x allocated to "foo" and then the RDFS rules 
will get you to
_:x subclass _:x
but then without something else, you are stuck. This ONLY happens in 
this case (and the similar one using property/subproperty) because 
the only rules that move a subject to object position are the 
reflexiveness rules on subclass and subproperty, so this is the only 
way you can get stuck in this corner. So you only need to use rule gl 
after applying rule rdfs6 or 10, in fact.

>
>I think this intent would be clearer if a different metavariable 
>were used in rules 'lg' and 'gl', e.g. 'gl' might read:
>
>[[
>[rule name] gl
>
>[if E contains] uuu bbb _:nnn .
>where _:nnn identifies a blank node allocated to the literal lll by rule lg.
>
>[then add] uuu bbb lll .
>]]
>
>...
>
>Responding now as an implementer, the new rule looks like a pain to 
>implement (which is maybe OK, but I have tried to create an 
>implementation that can do, say, proof-checking that is based very 
>closely on the specification).
>
>I'm thinking that I might take a slightly different approach, which 
>I think is equivalent:
>
>Rule: lg1
>If E contains: uuu aaa lll .
>Then:          uuu aaa _:nnn.  _:nnn foo:sameAs lll .
>(where _:nnn is allocated as described for rule 'lg'.)
>
>Rule: gl1
>If E contains: uuu bbb _:nnn .  _:nnn foo:sameAs lll .
>Then:          uuu bbb lll .
>
>(The 'foo:sameAs' property is intended to appeal to the owl:sameAs 
>property, without getting entangled with the owl semantic conditions 
>on owl:sameAs.
>I.e., a foo:sameAs b does not necessarily mean that I(a) == (b), just that
>    a p c . <=> b p c .
>and
>    d q a . <=> d q b .
>for all syntactically allowable c, d, p, q.)

Right, exactly. That is what is needed in an implementation: to treat 
the literal and its allocated bnode *in exactly the same way* 
wherever syntactically possible.  In fact, the best way to handle 
this would be to actually use the literal in subject position when 
applying the rules, if your implementation can handle that, and just 
ignore rules lg and gl.  Or, maybe, apply rule lg to everything, 
*including the proposed conclusion* which would be closest to 
standard computational-logic practice and would obviously avoid the 
need for that silly rule gl; in effect it would just eliminate 
literals altogether in favor of blank nodes.

You can get a clearer insight into the role of these rules by 
checking how they are used in the construction of the 'closures' in 
the appendix proofs.

Pat

>#g
>
>
>------------
>Graham Klyne
>For email:
>http://www.ninebynine.org/#Contact


-- 
---------------------------------------------------------------------
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 Tuesday, 16 December 2003 09:48:29 EST

This archive was generated by hypermail pre-2.1.9 : Tuesday, 16 December 2003 09:48:32 EST