a cunning plan (was: Re: On Consensus)

>
>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

Received on Friday, 27 September 2002 03:01:59 UTC