Re: Feedback request

>At 21:28 31/10/2002 -0600, pat hayes wrote:
>
>>Quick request(s) for feedback. There are 5 parts to this message.
>>
>>Please say if you think that any of the following entailments 
>>should NOT be valid in RDF or RDFS, or have any problems with the 
>>reasoning sketched. Obviously "10" can be any string.
>>
>>1. (RDF)
>>aaa ppp "10" .
>>-->
>>aaa ppp _:xxx .
>>
>>2. (RDF)
>>aaa ppp "10"^^datatypefoo .
>>-->
>>aaa ppp _:xxx .
>>
>>3. (RDF)
>>aaa ppp "10"@lang .
>>-->
>>aaa ppp _:xxx .
>
>Oh dear, I knew this would come up sometime.  This will get into the 
>are resources literals issue and pretty much allows literals as 
>subjects:

No, we don't need to go there. Relax, I wasn't planning to open that can.

>   aaa ppp "10" .
>   aaa ppp _:l .
>   _:l rdfs:type rdf:Literal .

Er.... yes, that would be valid. Is that a problem? I don't see any 
literal subjects there. The _:l denotes the *value* of the literal; 
the fact that this *is* the literal in this case hasn't anything to 
do with the logic of the example.

>Blank nodes come from anonymous resources and a lot of folks, not 
>all, read M&S as Frank did that literals and resources are disjoint.

Oh. To accommodate that we would need to ban entailments 1 and 3, 
then. There would be no way to infer a bnode from a bare inline 
literal, because they might not denote anything? But they denote 
themselves, what could be clearer than that? Seems like a crock to me.

>  I'd rather we stayed away from these, but I suspect its too late in 
>that we have test cases of this form, e.g. the tidy entailment.
>
>>From the above, and assuming bare literals denote themselves, then 
>>IR must contain all bare literals (cuzof 1) and all values that any 
>>datatype can map them into (cuzof 2) and maybe all pairs of all 
>>those things with lang tags (not yet sure about that last one). So 
>>we might as well say that IR contains all of LV, seems to me. In 
>>which case we would get
>>
>>4. (RDFS)
>>rdfs:Literal rdfs:subClassOf rdf:Resource .
>
>Ha!

So? Nothing up my sleeve. Do you want to make sure that this is not 
an entailment? I could, but I guess I was suggesting that there was 
no longer any point in being so persnickety. But OK, I'll go on being 
persnickety if you want me to. This amounts to allowing for the 
semantic possibility of there being literal values that cannot be 
denoted by any URI or any RDF literal. Which seems kind of, well, 
pendantic.

>>5. (RDFS)
>>aaa rdf:type rdfs:Datatype .
>>--->
>>aaa rdfs:subClassOf rdfs:Literal .
>
>I'm tempted not here as it gives us vocabularly to talk about the 
>old style literals.  Folks who wrote
>
>   aaa rdfs:range rdf:Literal .
>
>won't suddenly find that integers are now allowed as property 
>values.  There again maybe they would want that.
>
>This is the sort of question where I'd want to hear Danbri's 
>judgement as he has a good feel for how such changes might go down 
>in various sections of the community.
>
>
>>------
>>
>>Terminology question: now we have lists, should the term 
>>'container' be understood to include lists as well as seqs, bags 
>>and alts? If so, does anyone have an suggestion for a generic term 
>>for the older containers? (Simple containers? Open containers? 
>>Bushy containers?)
>
>Broken containers?  Leaky containers?
>
>
>I've been using the forms:
>
>   Containers for the old style containers
>   Collections (based on the parseType term) for lists and explaining 
>that a collection is represented as a list structure.
>
>But I'm not wedded to it.  I do need to know by next Thursday 
>though, a deadline for something else I'm writing.

Thanks. Im fine with this. No change, I'll use this in the MT docs.

>
>
>>------
>>
>>Can anyone fill in the blank for
>>
>>rdfs:comment rdfs:range ??? .
>
>rdf:Literal
>
>>------
>>
>>Er..sorry, I ought to know this, but I am honestly unable to recall 
>>where the hell we are now. Have we decided to NOT allow property 
>>datatyping, ie the use of a datatype URI as a property to link a 
>>node to a bare literal, with the datatype implication that the node 
>>denotes the resulting value? Or to ALLOW it? That is, should
>>
>>6.
>>aaa ppp "10"^^datatypefoo .
>>--->
>>aaa ppp _:xxx .
>>_:xxx datatypefoo "10"
>>
>>or not? If so, how about the reverse entailment??
>
>My understanding is we took this out when we simplified datatyping 
>back in the summer.  I think the deal is that WE are not 
>standardizing this but a future WG likely will, so we don't do it 
>now, but we also don't do anything that would break it.
>

OK. So there is NO provision for using datatypes other than in typed 
literals, is that right? In particular

aaa rdf:type rdfs:Datatype .
bbb rdf:type aaa .

does not enable one to utilize datatyping information to conclude 
anything about bbb; the first triple adds nothing to the content of 
the second triple. Not meaning to start an argument, I just want to 
be quite clear about this so that the MT doesn't miss anything.

If datatyping is this simple then we probably could incorporate it 
into basic RDF, by the way. Whatever.

Pat

-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   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 Friday, 1 November 2002 11:48:19 UTC