RE: ACTION 2001-11-02#02: Datatyping use-cases from CC/PP

>....
>If you mean that it is OK to define contraditions using the RDFS
>ontology, and leave the "validation" of that knowledge to applications,
>then sure, I agree.
>
>But it should be clear IMO from the semantics of that RDFS ontology
>when contradictions do in fact occur.

The odd thing is, that in fact RDFS is so logically weak that it is 
impossible to express outright contradictions in it. If RDFS is told 
both of
aaa rdf:type thisType .
aaa rdf:type thatOtherType .
then it will just happily assume that aaa has both types. (Why should 
it not? How could it know (or be told) that two types are 
incompatible?)

This is a particular weakness of RDFS, however; more expressive 
languages like DAML+OIL can say such things and notice genuine 
contradictions.

>
>>  >What this means is that, if rdfs:range is used in
>>  >a descriptive sense, you end up with the above
>>  >un-flagged conflict.
>>
>>  No, that does not follow. Saying that the language is descriptive
>>  does not imply that contradictions or conflicts must not be flagged.
>>  It only says how the language sets about identifying them (by
>>  inference.)
>
>Fair enough.
>
>So, you're essentially treating rdfs:range as some kind of
>rdf:aboutEach like mechanism that actually asserts statements
>about all resources occurring as a value of the property for which
>the range is defined. Eh?

Er....well, not like aboutEach. Not quote sure what you mean by 'mechanism'.

rdfs:range is just a property, and you make assertions about ranges 
by using that property in a triple, right? Its not just any old 
property, though: its meaning is 'fixed' to some extent, eg you can 
infer from

eg:prop rdfs:range aaa .
bbb eg:prop ccc .

that

ccc rdf:type aaa .


>And then it's up to some application to note the conflict if
>e.g. a given literal "A" is defined as both xsd:integer locally
>and xsd:lang via an rdfs:range definition.
>
>Right?

Right.

>
>The question, then, arises about *when* such assertions are made.

Ah, that is a question about an RDFS inference engine. One kind of 
engine might maintain all the RDFS consequences of everything it 
knows, for example, like the closures in the (newer version of the) 
MT. Uses a lot of memory, I guess, but it will quickly find any 
problems and give you all the type information you could possibly 
want or need. Other strategies are also possible.

>Per my examples previously, if the assertions are only implicit
>and applied after a non-locally typed literal is bound to a
>superordinate property of the original statement predicate,
>problems can ensue.
>
>No?

Right. I would expect that anything that undertook to check types 
would do an exhaustive search for any consequences of the form
<literal> rdf:type <some datatype name>  . (in P++) or
_:x <some datatype name> <literal> . (in S)
before delivering any firm conclusions to a type-checking engine. It 
would be irresponsible not to, right?

>
>>  >If  rdfs:range is used in a prescriptive sense, as
>>  >a true constraint, it doesn't add the statement
>>  >
>>  >   _1:"foo" rdf:type someType .
>>  >
>>  >but provides the means for determining whether the
>>  >statement
>>  >
>>  >   _1:"foo" rdf:type someOtherType .
>>  >
>>  >is acceptable within the scope of the given property.
>>
>>  But what is the difference between those two cases, for RDFS ?
>
>There are no differences for RDFS insofar as "validity" are concerned
>(catching contraditions, etc.) between this prescriptive (non assertive)
>and descriptive (assertive) interpretation.

Ah, that is a relief. :-)

>The problem is in the case of non-locally typed literals when
>it comes time to map them to values in some computer system's value
>space. If, by inference based on subPropertyOf the literal gets
>bound to a superordinate property with a superordinate data
>type different from that of the original statement, the mapping
>could be erroneous or even fail (with a parse error), if the
>binding of literal to data type is based on the superordinate
>property's range definition rather than the original statement
>property's range definition.
>
>So, if a range definition asserts a binding of data type to literal,
>when does that occur, and how can that binding be preserved throughout
>common query and inference processes?
>
>That is my concern. I hope it is clear (given my batting average,
>I won't be at all surprised if it isn't ;-)

Ah!! [Light goes on above head...]

Maybe I see what is bothering you. The purely descriptive model we 
currently have can deliver all inferable typing information to an 
external type-checker, and if it finds any contradictions then it can 
report those, or deliver enough information so that the checker can 
notice them. But that alone doesn't say which one of these 
type-assertions is the local one and the other is the global, or 
distant, one.  So if a type-checker wants to use the *local* 
information to make its decision - if it wants to treat THAT 
information as prescriptive rather merely descriptive, if I have this 
distinction right now - then it will be stymied, because the purely 
assertional nature of the RDFS reasoning process treats all sources 
of information as having equal claims on the truth, as it were. It 
doesn't enable the external type-checking engine to use a 
local-preferring default procedure to make its decision in the face 
of a conflict between local and global information about types, 
because it doesn't even have the distinction available. It can report 
a conflict, but it only does do neutrally; it doesn't take sides; 
whereas in this case you *want* it to take sides, in order that the 
external process can more rationally decide what to do.

Is that more or less right? because if so it raises an interesting 
issue about RDFS generally, in fact, which I think goes beyond just 
data-typing: there may be more information 'in' an RDF graph than 
just the content of the triples that make it up.
....

>  > If you really do mean to use it in the technical sense, then you
>>  really are plain knock-down wrong.
>
>Then I'm not using it in the technical sense ;-)

:-)

Pat
-- 
---------------------------------------------------------------------
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 Wednesday, 14 November 2001 21:21:22 UTC