>
>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.eduhttp://www.coginst.uwf.edu/~phayes