Re: a cunning plan (was: Re: On Consensus)

Pat,

So, if I understand correctly, by your suggestion:

    Jenny age "10" .
    Film title "10" .

does not entail

    Jenny age _:x .
    Film title _:x .

but

    age rdf:type rdfs:weakDatatypingProperty .
    title rdf:type rdfs:weakDatatypingProperty .
    Jenny age "10" .
    Film title "10" .

does entail

    Jenny age _:x .
    Film title _:x .

?

Then, as you say, adding:

   rdf:Property rdfs:subClassOf rdfs:WeakDataTypingProperty .

allows all the tidy-literal entailments.  Thus, any engine that draws such 
entailments should include the above assertion (or corresponding assertions 
about the particular properties used) so that software that doesn't 
"believe" this can be alerted to possibly-inconsistent results?

It seems feasible.  My biggest concern is that this represents a new piece 
of design rather late in the day.  But if it can break the deadlock 
here...?  Can the semantics be specified easily?

#g
--

At 02:02 AM 9/27/02 -0500, pat hayes wrote:


>>I'd like to try casting this issue in terms of equality/identity 
>>operations rather than entailments for a bit.  It seems to me 
>>(corrections welcome) the basic issue is that current RDF implementations 
>>interpret the literal equality operation as string matching, and we'd 
>>like to "grandfather" that, so that existing implementations can continue 
>>to implement that operation, and existing applications that depend on 
>>that interpretation can continue to work (I don't believe RDF M&S 
>>actually defined an equality operation;  this is just the way RDF 
>>implementations worked).  At the same time, we'd like, in conjunction 
>>with the datatyping facility, to have RDF implementations support "value 
>>equality" based on datatypes (so age 10 isn't the same as movie-title 10 
>>according to value equality).  Even with value equality, string equality 
>>still seems a reasonable (and useful) operation to support (you can think 
>>of it as a "cast to string" if you want).  So why can't we have 
>>both?  That is, define as part of the datatyping facility something like 
>>a "value equality" operation and require people to indicate which 
>>equality operation they are using.
>
>The snag is, indicate how?? I have a cunning plan.
>
>Suppose we make the distinction by saying that we will have two kinds of 
>properties.  Weakly datatyping properties can impose a datatype on a 
>bnode, but they can't force a bare literal to be anything other than a 
>string; so that
>
>ex:age rdf:type rdfs:WeakDataTypingProperty .
>ex:age rdf:range xsd:integer .
>Jenny ex:age <_:x :10> .
>Bill ex:age 10 .
>Joe ex:age _:y .
>_:y rdf:lex 10 .
>
>has Jenny and Joe being ten but is a syntax error on Bill. In other words, 
>they use literal equality. But if we had said
>
>ex:age rdf:type rdfs:StrongDataTypingProperty .
>
>then Bill's age would have been ten as well, because those strong guys use 
>value equality and can re-interpret a bare literal. This would allow users 
>to set generic preferences, eg you could say that all the properties in 
>some collection or some namespace were strongly typing properties, and 
>then just work with bare literals but do semantic datatyping.
>
>This allows the interpretation of the literal node to depend on the triple 
>its seen in, so we can have syntactic tidyness and still have the nodes 
>look semantically untidy when seen through strong-datatyping glasses, as 
>it were.  For example suppose ex:age is strong but ex:ageish is weak, then
>
>Jenny ex:age 10 .
>Joe ex:ageish 10 .
>(tidy syntax, 3 nodes total)
>
>says that Jennys age is ten and Joes ageish is '10' even though theres 
>only one literal there.
>
>This also lets a Dan C. protect his turf if he wants to stop people 
>drawing the wrong conclusions about his literals, because he could say
>
>rdf:Property rdfs:subClassOf rdfs:WeakDataTypingProperty .
>
>which is a kind of 'keep out of here if you don't think literals are 
>strings' (or maybe 'I don't believe in strong datatyping') notice, since 
>it would be *inconsistent* with anyone trying to use a strong-datatyping 
>property to override his conventions on his data. So this lets people 
>declare their preferences and be sure that everyone will get the 
>conclusions they want them to have.
>
>Hey, this might actually work.....
>
>Pat
>
>
>>We ought to be able to cast this idea in terms of entailments for formal 
>>definition purposes.
>>
>>--Frank
>>
>>
>>
>>--
>>Frank Manola                   The MITRE Corporation
>>202 Burlington Road, MS A345   Bedford, MA 01730-1420
>>mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875
>
>
>--
>---------------------------------------------------------------------
>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

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Friday, 27 September 2002 12:25:11 UTC