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

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

But it may be a good idea to clearly document that in cases
where no local type is specified and all knowledge about
type is determined from rdfs:range properties, that if
literal objects are separated from the context of their original
statement by inference based on subPropertyOf relations, that
the lexical form of the literal may not be a member of the
lexical space of data type defined by the rdfs:range of
the inference bound superordinate property.

I.e, there is a potential for "BOOM" and implementors of
RDFS based inference engines should be made aware of it.

Eh?

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

Yes. AND ;-) in addition, if there are no local types defined, and
all type information is defined in terms of rdfs:range, and
a literal which is a member of the lexical space of the data
type of the range of the property of the original statement
(yikes, what a clause! ;-) which is subsequently bound by inference
to a superordinate property which has a different range and
the data type of that different range has a different lexical
space, then the literal may not be properly interpretable as
it does not denote a lexical form that is a member of the
lexical space of the non-original data type.

I.e., the pairing of literal to data type is per the original
statement and cannot change. If that pairing is defined by
rdfs:range, then the assertion of data type for that literal
must be made *before* any inference process can separate 
the literal from the data type defined for the property of
the original statement.

Boy, I hope the above is clear ;-) and I'll keep trying to
re-explain it until it is, because it's really, really, 
really, important.

Patrick

Received on Thursday, 15 November 2001 06:04:09 UTC