Re: DAML+RDFS: potentials for simplifications?

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
the
> 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
expected
> 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
you
> 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.
Sun's JAXP/JAXB)
- 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
interpret
> 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
amount
> to writing a new spec to replace RDF, or DAML and RDF.  What is the
benefit
> of that, and how would you get widespread agreement on it?  And why would
it
> 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">
  <rdfs:label>unionOf</rdfs:label>
  <rdfs:comment>
    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
versa.
    cf OIL OR
  </rdfs:comment>
  <rdfs:domain rdf:resource="#Class"/>
  <rdfs:range rdf:resource="#List"/>
</rdf:Property>

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,
indeed!)

> >
> > A benefit of this simplified syntax would be 1) that more people would
be
> > 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.
You
> 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!
Joachim

Received on Thursday, 29 November 2001 04:09:35 UTC