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

> >  that one could not know for
> >sure that the type absolutely was not a subtype, ever,
> >but insofar as the knowledge present at hand, it would not
> >be and the test of the constraint should fail.
> 
> That would not be a valid assumption. In general, you should not make 
> any closed-world assumptions; more information can always arise 
> later. If something follows from the knowledge presently at hand, 
> then it must also follow from any larger set of knowledge; so if a 
> later addition *could* consistently assert a subClassOf relation, 
> then you cannot assume that such a relation is false.

I'm not saying it's false. I'm saying the test of the constraint
fails. Those are very different things.

At any given time, a system must be able to make decisions
based on the knowledge it has. It determines the validity
or sufficiency of the knowledge relevant to that decision
at the time the decision must be made. It may make a different
decision later, if the knowledge changes or expands, but
the validity or sufficiency of a given statement is not
the same thing as truth or falsity.

Any knowledge based system, at a single point in time, is
a kind of closed world. 

> >This is of course, presuming that the type is defined locally
> >and a range is defined, otherwise the test can't even be made.
> 
> What sense of 'locally' do you have in mind? (Local to what?)

See my glossary at the start of the X proposal I just sent out.
 
> >So the constraint fails
> 
> Why? Nothing 'fails' here; you just have incomplete information. 

Right, sorry for sloppy language. The constraint cannot be satisfied
and therefore the test fails. I.e., insofar as a system that needs
to make a decision, inability to confirm the validity of a value
is the same as an invalid value.

 
> >as it should, since in this case, an RDFS
> >processor cannot satisfy that foo:bar is a subClassOf xsd:integer
> >and the data is rejected as unreliable.
> 
> NO!! Absolutely not. You cannot 'reject' data as unsuitable just 
> because it is incomplete. New data might arise at any time.

YES! YES! YES! ;-)

If my system needs to make a decision, and it can't determine if some 
value is acceptable, then it has every right to reject that value
as suitable for the task at hand. Rejection doesn't mean deleting
the knowledge from the knowledge base. It just means not using it
(or knowing what to do with it) at a given point in time.

I think you are being a little to philosophical in your views here.

Real world systems must make real decisions in real time with
real knowledge.

Yes, that knowledge may change, but inability to verify a critical
test due to insufficient knowledge is the basically the same as the 
test failing on sufficient knowledge insofar as real time decisions 
are concerned.
 
> >That's what constraints
> >are for. Right?
> 
> Who mentioned constraints?

Ummm... the RDFS Spec.

> >If I later load some schema that says that foo:bar is a
> >subclass of e.g. xsd:decimal, great, now the constraint is
> >satisfied and I know both that the value is a valid xsd:integer
> >(since xsd:decimal is a subClassOf xsd:integer) and I know that
> >the lexical form follows decimal notation. OK, now I can use it.
> 
> But you have already 'rejected' it, right? (What has happened to it? 
> Did it get erased, or sent back as incomplete, or what? I presume 
> 'reject' didn't just mean 'ignore', did it?)

I didn't imply any action, only a decision about its usability
for a given task.
 
Patrick

Received on Monday, 12 November 2001 14:23:40 UTC