Re: test case: Test case A and reification

>The discussion at Friday's telecon reminded me why I was keen to 
>have test case A still in.  I've tried to raise this point a couple 
>of times and just wanted to put it more formally.
>
>It is suggested that, even with untidy literals:
>
>   _:a <p> "lit" .
>   _:b <p> "lit" .
>
>entails:
>
>   _:a <p> _:l .
>   _:b <p> _:l .
>
>Consider a statement and its reification:
>
>   <s> <p> "a" .                       (1)
>   _:s rdf:subject <s> .
>   _:s rdf:predicate <p> .
>   _:s rdf:object "a" .                (2)
>   _s: rdf:type rdf:Statement.
>
>Does the object of statement (1) denote the same thing as the object 
>of statement (2)?
>
>Given the model theory as it stands (Pat - is this right?) the 
>answer to this question is yes.

As it stands, that is correct. (I have to admit that I was thinking 
of urirefs rather than literals when I wrote it, but that is what it 
says even in this case.) But notice that the current MT assumes tidy 
literals, so case A is a non-issue: the answer has to be Yes.

>
>Now consider:
>
>   <jenny> foo:age "10" .                   (3)
>   <film>  dc:title "10" .                  (4)
>   foo:age  rdfs:range xsdr:decimal .
>   dc:title rdfs:range xsdr:string .
>
>and two reifications:
>
>   _:a rdf:subject <jenny> .
>   _:a rdf:predicate foo:age .
>   _:a rdf:object "10" .                    (5)
>   _:a rdf:type rdf:Statement .
>
>   _:b rdf:subject <film> .
>   _:b rdf:predicate dc:title .
>   _:b rdf:object "10" .                    (6)
>   _:b rdf:type rdf:Statement .
>
>
>Then the objects of statements (5) and (6) cannot denote the same 
>thing as the objects of statements (3) and (4) respectively.

Er.... why not? In the current stake proposal, they all denote the 
string "10" (which conforms to the lexical form requirements of both 
xsdr:decimal and xsdr:string, so everything is fine.) Reification 
works OK, I think. What we cannot do would be to conclude from the 
following:

_:a rdf:subject <jenny> .
_:a rdf:predicate foo:age .
_:a rdf:object "10" .
_:a rdf:type rdf:Statement .
_:a ex:composedBy ex:BirthdaySource .

that the string "10" was composed by that source. But we couldn't say 
that anyway :-).

>I confess I find this rather bizarre.  In the case where the object 
>of a statement is a literal, then the value of the rdf:object 
>property of the reification of that statement denotes a syntactic 
>entity, otherwise it denotes a semantic one.  (Sorry that doesn't 
>sense to a logician, but Pat'l know what I mean.)

Well, it is bizarre, but the bizarritude arises from the fact that we 
have made these pieces of syntax denote themselves, thereby neatly 
confusing the syntactic and semantic domains by putting the former 
into the latter.

>
>Is that what we mean to say?
>
>If the answer to test case A is yes, then we need an non-entailment test:
>
>   <s> <p> "a" .
>   _:s rdf:subject <s> .
>   _:s rdf:predicate <p> .
>   _:s rdf:object "a" .
>   _s: rdf:type rdf:Statement .
>
>where _:s is a reification of the first statement
>
>does not entail:
>
>   <s> <p> _:o .
>   _:s rdf:object _:o .

Again, I think this is valid in the current 'stake' proposal (for 
literals and urirefs). And if literals were semantically untidy, then 
any entailment from distinct literal nodes to common bnodes would be 
invalid. In other words, I don't think reification introduces any new 
issues. The issue is: If we allow untidy literal nodes, when can we 
assume that two literals denote the same thing? Answer: when they are 
the same *node*. It's the nodes that do the denoting, not the labels. 
Then it all works coherently, including reification and containers 
(that is, containers are weak; eg datatyping a container doesn't 
datatype its contents. But we knew that already, right?)

Pat


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Monday, 8 July 2002 20:09:03 UTC