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

> -----Original Message-----
> From: ext Pat Hayes [mailto:phayes@ai.uwf.edu]
> Sent: 14 November, 2001 20:16
> To: Stickler Patrick (NRC/Tampere)
> Cc: w3c-rdfcore-wg@w3.org
> Subject: RE: ACTION 2001-11-02#02: Datatyping use-cases from CC/PP
> 
> 
> >  > >I'm not saying it's false. I'm saying the test of the constraint
> >>  >fails. Those are very different things.
> >>
> >>  Then please define the second one (in terms I can understand?).
> >
> >I'm trying... believe me...
> >
> >>  RDF(S)  makes assertions; as far as I can tell, that is 
> all it does.
> >>  An assertion is true or false in every interpretation. 
> Where in this
> >>  picture are there any 'constraints' other than assertions?
> >
> >What you suggest is that if we have
> >
> >   someProperty rdfs:range someType .
> >
> >and
> >
> >   someResource someProperty _:1:"foo" .
> >   _1:"foo" rdf:type someOtherType .
> >
> >we end up with
> >
> >   someResource someProperty _:1:"foo" .
> >   _1:"foo" rdf:type someOtherType .
> >   _1:"foo" rdf:type someType .
> >
> 
> Yes, that could be inferred if we allow literals as subjects, and 
> using the extended model theory.
> 
> >since RDFS only "asserts" things.
> 
> Well, not 'only'; it could be inferred because that would be a valid 
> consequence according to the semantics of RDFS.
> 
> >Now, if someOtherType is not a subClassOf someType, then
> >we should flag some sort of error about the incompatible
> >data types, right?
> 
> If those assertions are inconsistent then I would expect an RDFS 
> engine to tell me that, yes, and maybe such a report ought to be 
> taken seriously as a sign that something is wrong somewhere, indeed. 
> But exactly what is wrong, and what should be done about it, are 
> questions that lie outside the scope of RDFS meaning.

No argument there.

> However, in this example, I would note that there is no way to 
> express in RDFS that one class is *not* a subclass of another, so 
> this situation could never arise, in fact. This may be just a 
> technical quibble, but it does illustrate the general point, since 
> the implied clash between someType and someOtherType will only be 
> visible to an engine that knows more about those types than RDFS can 
> or should know.

Yes, but a given system can require that the subClassOf relation
exist and if it doesn't can adjust its behavior accordingly.

> (BTW, there is an ongoing divergence of opinion in this field about 
> quite what 'verification' ought to constitute. The DAML+OIL group for 
> example has been having some internal discussions about whether a 
> verifier should flag conditions which are semantically correct, 
> strictly speaking, but which are very likely to indicate an error, in 
> practice, eg using a class name which has no definition (which is 
> legal in DAML+OIL), or a very long subClassOf loop. Clearly, this 
> notion of 'verifying' is somewhat flexible, and different notions are 
> useful in different contexts. I think this debate might be relevant 
> here. 

Certainly sounds like it is relevant.

> It seems to me that there are several clear distinctions that 
> ought to be observed, most notably between flagging something 
> syntactically illegal/something contradictory (impossible in RDFS, by 
> the way)/something which violates an external criterion of 
> correctness/something'odd' according to some external criterion. As 
> far as I can see, RDFS (unlike DAML+OIL) simply is unable to express 
> a direct contradiction, so all normative flags, other than syntax 
> errors, have to be of the 'external' variety. For example, something 
> that was using RDFS to record datatyping information might well barf 
> if RDFS delivered it both someType and someOtherType; but I would say 
> that was it's business, not RDFS's business.

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.

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

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?

If so, then I guess I can see that as an acceptable way to go.
 
The question, then, arises about *when* such assertions are made.

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?

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

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

> >I didn't say that *RDF* makes those decisions. A computer
> >*SYSTEM* operating on RDF encoded knowledge makes those
> >decisions.
> 
> Right, exactly. So all these distinctions that you insist must be 
> imposed on RDFS, actually belong in this external SYSTEM. Some of 
> them will interpret some information prescriptively, maybe. Others 
> may not. Either way, its up to them , not to us.

It's not as simple as that, as hopefully outlined immediatly
above.
 
> >I'm an engineer, not a mathematician, but then, this group
> >needs all types, right?
> 
> Right. I didn't mean to stop you using your vocabulary, but we all 
> have to be ready to translate for one another.

Quite so. 
 
> >  > Validity
> >>  means preservation of truth;
> >
> >As in an XML instance being Valid? ;-)
> 
> Touché. I was using the logician's terminology maybe too carelessly.

I'm sure I'm more guilty than you on the charge of poor choice 
of words...
 
> That term 'closed world' has a very particular meaning. I think that 
> you are using it informally, but that is a very risky usage, as 
> anyone with a computational logic background may well misunderstand 
> you.

You are probably right, and apologies for cross-discipline
vocabulary abuse.
 
> 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 ;-)

> >The benefit of RDF is that it allows for transparent progression
> >along the sequence of temporally distinct closed worlds without
> >modification to the software logic.
> 
> The fact that the logic is monotonic - transparently progressible, an 
> elegant way to put it - is why the worlds cannot be taken to be 
> closed.

I agree. I was trying to capture an idea that perhaps cannot
be expressed using the terminology I was using. But I think
(hope) that you understand the gist of what I as trying to
say:

 "When it comes time to make decisions, 
  what you know is all that counts."

(actually, I kinda like the sound of that axiom,
 ahem... (C) 2001 Patrick Stickler  ;-)

> >local type
> >
> >         A data type associated directly with an occurrence of a
> >         property value serving as the object of a statement
> 
> That doesn't define it, since obviously 'local' means just as much or 
> as little as 'directly' means, and you don't define that either.
> I presume you mean these terms to be understood in a syntactic sense, 
> so that 'local' means something like 'syntactically close to'. But in 
> RDFS there is no notion of name scope, so the usual CS local/global 
> contrast has no precise meaning (everything is 'global' in this 
> sense, strictly speaking.)

I get your point, and yes, I was thinking in terms of graph
proximity, really. Such that we talking about a data type
URI which is associated with a specific node in the graph
representing a specific occurrence of a literal. 

> BTW, I perceive that you use the word 'philosophy' as a rhetorical 
> tool to undercut an opponent, a common tactic among engineers. I 
> would advise against getting involved in a game of rhetorical 
> oneupmanship, however.

That was not my meaning or intent. I actually try very hard
to "play nice and fair" (though that might be questioned given
the past few days posts ;-)

I was trying to stay down closer to implementational details
rather than abstractions -- though both are important.

> >Please stop philosophizing these issues.
> 
> I am not 'philosophizing' anything. I am simply being 
> minimally precise.

;-)

> >We are not dealing with
> >the "UNIVERSE", we are dealing with a set of explicitly reified
> >statements about some universe which are intended as input to
> >software applications which execute instructions that accomplish
> >some useful result.
> 
> Thank you for your insightful lesson in semiotics. I marvel at your 
> grasp of these basic principles, so elegantly expressed (for an 
> engineer).

OK, I deserved that ;-)


Patrick

Received on Wednesday, 14 November 2001 13:54:55 UTC