W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2002

Re: Monotonicity

From: Sergey Melnik <melnik@db.stanford.edu>
Date: Tue, 05 Feb 2002 10:37:39 -0800
Message-ID: <3C602673.AD30A609@db.stanford.edu>
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
CC: w3c-rdfcore-wg@w3.org
Jeremy Carroll wrote:
> >
> > I thought monotonicity was a feature, not a bug. As far as I remember
> > what logics etc. was about, if we drop monotonicity things become really
> > hairy and computationally impractical even for small data/knowledge
> > bases. Please correct me if I'm wrong...
> Agree - monotonicity is a very high want.
> >
> > Does TDL require non-monotonic reasoning?
> No.
> >
> > Sergey
> >
> >
> We seem to be very near to closure now, so I think for now we can drop the
> topic and only come back to it later if necessary.

Sure, dropped. Just a small clarification below...

> If interested ...
> The point of the original message was meant to indicate a subtle difference
> between S-P and TDL at the model theoretic level, roughly: TDL is monotonic
> in datatypes, and S-P isn't.
> The difference was that in S-P the MT representation of rdf:value was
> defined with a finite known set of datatypes, and TDL used the same
> definition but with arbitrary unknown datatypes added. The resulting final
> TDL and S-P definitions of rdf:value looked very different but that was
> superficial.

The wording of the first sentence in

(Notice that for the above definition to be well-formed, we need to be
able to enumerate all datatype mappings. This can be done using special
vocabulary e.g., xsd:date.map rdfs:subClassOf rdfdt:DatatypeMapping). 
is misleading, sorry about that. In the next sentence there is some
clarification. What it says is that datatypes should be explicitly
identified as such somewhere in the interpreted RDF graph (using special
vocabulary). This requirement does not presuppose a finite known set of
datatypes, i.e. new datatypes can be user-defined, no problem...

Received on Tuesday, 5 February 2002 13:07:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:09 UTC