Re: datatypes and MT

At 01:17 PM 11/8/01 -0600, Dan Connolly wrote:
>Graham Klyne wrote:
>
>>At 08:59 AM 11/7/01 -0600, Dan Connolly wrote:
>>
>>> > In which case, I think you're flying in the face of existing RDF
>>> > practice.
>>>
>>>Well, yes, I'm aware that folks say things like
>>>         the string "Dan Connolly" wrote a mail message
>>>and I hope we can show/convince folks that this is
>>>not a good idea.
>>
>>I think it's fine to educate people that it's not a good idea, but with 
>>the current understanding and use of RDF I think we should allow it to be 
>>legitimate RDF which *can* be interpreted as the designers intended.
>>I think it's a fair trade-off that a fully-generic RDF processor 
>>(reasoner?) cannot access the intended meaning without supplying some 
>>additional information, which may be awkward to do.
>>So the statememt:
>>    <http://www.ninebynine.org/> dc:creator "Graham Klyne" .
>>should be allowed to be consistent with:
>>    <http://www.ninebynine.org/> dc:creator
>>        [ a foaf:Person ; foaf:name "Graham Klyne" ] .
>>even if it doesn't, of itself, convey the same information.
>
>
> From my experience, there lies madness. I wonder if I can
>convince folks who haven't walked in my shoes for the last
>few years...

Your size 10 shoes?  Or should that be size "10" shoes?  ;-)

>In this case, there's just one author of that web site;
>let's presume we've communicated that formally...
>then we have something that's both
>an rdfs:Literal and a foaf:Person. I would
>think those classes are disjoint.

I don't see that has to be.  Under a suitable datatyping scheme, is it not 
possible for I("Graham Klyne") and I(_:someResource) to be the same thing?

>Then there's the "turtles all the way down" problem...
>if literals work that way in the case of dc:creator,
>do they also work that way in the case of foaf:name?
>i.e. is
>
>   [ a foaf:Person; foaf:name "Graham Klyne" ]
>consistent with
>   [ a foaf:Person; foaf:name [ rdfs:value "Graham Klyne" ] ]
>or something? can I do it again with rdfs:value? when
>do we get to the bottom?

I don't see that arises in this case.  Or maybe it can arise, but doesn't 
add any new information, hence is pointless.

(Though I do see this is a problem with the general idea of saying:
   _:a ex:prop "abc" .
SHOULD be treated as:
   _:a ex:prop [ rdf:value "abc" ] .
)

In the foaf: case, foaf:name could be understood (through appropriate 
schema, or other means) to have a range which is just a literal string, and 
in such a case an identity datatype mapping would provide all needed 
information.  In effect, the regress can "bottom out" by application of:

   I("Graham Klyne") = "Graham Klyne"

And here, I think, is my point.  If some statement like:

   <http://www.ninebynine.org/> dc:creator "Graham Klyne" .

provides all the information that an application desires (presuming some 
suitable interpretation of this which is compatible with a more complete 
description of the creator), then why require more?  An application, for 
example, whose sole function is to answer questions like:  "who created 
?page" with a string that can denote the creator.

Here's my parting shot, for now.  When I said:
[[[
So the statememt:
    <http://www.ninebynine.org/> dc:creator "Graham Klyne" .
should be allowed to be consistent with:
    <http://www.ninebynine.org/> dc:creator
        [ a foaf:Person ; foaf:name "Graham Klyne" ] .
]]]
Note that I said "allowed", not "required".  It would be something 
specifically licensed in the case of dc:creator and foaf:name (by means not 
yet defined, but I imagine some form of application-domain-specific closure 
rules).  Such licence would, in my view, provide the migration path from 
"naive" RDF descriptions to the "rich" RDF descriptions you advocate.

#g


------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
------------------------------------------------------------

Received on Thursday, 8 November 2001 15:16:04 UTC