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

Re: DAML+RDFS: potentials for simplifications?

From: <Joachim.Peer@unisg.ch>
Date: Thu, 29 Nov 2001 10:09:32 +0100
To: tpassin%home.com%UNISG_EXTERN@unisg.ch
Cc: www-rdf-logic@w3.org
Message-ID: <OF3BD05687.26621287-ONC1256B13.002CB0B0@unisg.ch>

Hi Thomas,

thanks for your input!

> From my point of view,  there are two essential differences between your
> first (above) and second (below) example:
> 1) There is really no difference in the syntax between them except that
> second example does not use namespaces.  Therefore a processor needs some
> other way to understand how you want to process them.  It can't be
> to know without hints that your <Class/> is not the same as my
> <Class subject='physics'>Physics 7.01
>     <days>Mon,Wed</days><time>11:00 AM</time>
> </Class>
> If you don't use namespaces, you need some other way to say what system
> are using.

yes, i fear i oversimplified the example. moreover, i forgot to say that
- of course you should be able to use namespaces (e.g. to distiguish it
from XML schema declarations that could reside in the same file). this
would be no problem for today's xml parsers and parsing frameworks (e.g.
- and of course the file would be based on a DTD and / or XML schema  (for
syntax validation (btw. how do i this in RDFS??) and for giving information
about the TYPE of the document.)

> 2) You need a set of conventions so a processor would  know how to
> the various constructions.  It's not always obvious, as witness all the
> discussion on this list even though there are fairly developed documents
> defining the syntax, etc.  To create such a set of conventions would
> to writing a new spec to replace RDF, or DAML and RDF.  What is the
> of that, and how would you get widespread agreement on it?  And why would
> be more trouble free?

You say, a result of the simplified syntax is, that a processor would need
a "set of conventions". Yes, but how does this differ from the current
situation? Are you aware of any DAML interpreter which has no hardcoded set
of DAML specific instructions?

take for example the definition of the unionOf-construct of DAML:

<rdf:Property rdf:ID="unionOf">
    for unionOf(X, Y) read: X is the union of the classes in the list Y;
    i.e. if something is in any of the classes in Y, it's in X, and vice
    cf OIL OR
  <rdfs:domain rdf:resource="#Class"/>
  <rdfs:range rdf:resource="#List"/>

this definition tells an RDF aware application only half of the story... It
tells nothing about the semantic implications of this construct. So if one
wants to have a DAML aware agent, one will need to tell it explicitly what
e.g "unionOf" means.

this was a bit disapointing to me, and this was the point where i began to
ask myself: why all the complexity if the core problems (having to hard
code DAML aware agents) remains?

It would be a different story, if there would be a way to "dynamically
upgrade" an agent's knowledge/capability base by importing some RDF code
which marks up logic axioms. ==> Is somebody aware of such a development?
(If so, it would be a bad idea of mine to write RDF unaware DAML-agents,

> >
> > A benefit of this simplified syntax would be 1) that more people would
> > able to write ontologies and 2) that parsing DAML constructs would be a
> > very trivial process
> >
> The only simplification I see is not writing prefixes, and you give up
> knowing exactly what is intended by the various constructs and names.
> also give up the ability to easily call upon other systems (e.g.,
> jsmith:label vs. rdfs:label) when they might be useful.

hmmm... when would i want to specify jsmith:label, if i want to assign a
label (name) to a DAML class? who would make use of such information?

i think, the core question now is: is there a way to "dynamically upgrade"
an agent's knowledge/capability base by importing some RDF code which marks
up logic axioms? (or will this be the role of DAML ?) has anybody more
information on this?

thanks in advance!
Received on Thursday, 29 November 2001 04:09:35 UTC

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