W3C home > Mailing lists > Public > www-rdf-logic@w3.org > January 2001

Re: DAMl "Thing" should be Top, Universal class - including concrete types

From: Ian Horrocks <horrocks@cs.man.ac.uk>
Date: Tue, 30 Jan 2001 18:26:32 +0000 (GMT)
Message-ID: <14967.1880.156178.780535@galahad.cs.man.ac.uk>
To: "Tim Berners-Lee" <timbl@w3.org>
Cc: "RDF Logic list" <www-rdf-logic@w3.org>

I agree with a lot of what you say - it would clearly be "nicer" not
to separate abstract and concrete domains. As I understand it, the
idea behind daml+oil is that it provides clear semantics and potential
implementation paths (e.g., for reasoning services) for some
restricted subset of what can be written in RDF(S). If you want the
semantics and the services, the cost is the restriction. The proposal
simply suggests a way to extend daml+oil with (a restricted form of)
concrete domains while still retaining the above properties.

Regards, Ian

On January 30, Tim Berners-Lee writes:
> I am concerned about the suggestions that what DAML
> calls a daml:Thing, and RDF (unfortunately) a rdf:Resource
> should not include concrete types.
> I feel RDF should be fixed so that literal strings are regarded
> as particular resources, and I think even a mapping into URI space
> should be specified using the "data:" scheme which has been defined
> exactly for this purpose.  (<data:logic/rdf;10> = "10")
> But the main point of this email is to counter suggestions that
> concreete types and abstract types should be made quite distinct
> and properties only be allowed to hve a range and domain
> which are subclasses of one or the other.
> The basic fundamental raeson why this is bad is that it is not minimalist
> design.  It is fine for an individual project, but for the semnatic web
> it can't be an assumption you force in theunderlying infrastructure.
> Essentially this says, "All things, whatever they are are one of two
> distinct classes, at a more fundamental level than any other
> distinction".  This sort of statement must only be made when it
> is absolutely necessary to create an infrastructure which will stand up
> on its own feet.
> It is more difficult to give examples which will appeal to an arbitrary
> reader
> as to why one might need properties whose range or domain contain both
> abstract and concrete types.
> One example is the title of a book.  The property foo:title, say related
> an abstract work and something which is a human-oriented description
> of it.  A simple use is to say
> title(mybook, "The cat in the hat")
> A more complicated use is to say
> title(mybook, mybooktitle)
> english(mybooktitle, "The cat in the hat")
> french(mybooktitle, "Le chat dans le chapeau")   %%  or whatever
> Annother is that I might genericly want to write logic to deal with the
> values of fields in an address book.  I might want to talk about the
> validity and caretion date and author of fields and their
> values, when some values are concrete (date of birth, an xmldt:date)
> and some are complex (office, a location, which has properties
> such as address and phone number and so on).
> I actually find the idea so odd that I find it difficult to explain why it
> is
> weird.  It shows how different woldviews can be, I suppose. I hope this
> makes sense.
> If the logic is set up so that there is no set which includes both leaves
> and branches, we have an arbitrary constraint underpinning all our
> work, and I find that unacceptable.  Unless I have missed something.
> Tim
Received on Tuesday, 30 January 2001 13:18:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:33 UTC