W3C home > Mailing lists > Public > www-mobile@w3.org > June 2002

Re: DAML/RDF and CC/PP (Was -- Re: Validation in CC/PP)

From: Ron Lake <rlake@galdosinc.com>
Date: Thu, 06 Jun 2002 08:16:32 -0700
Message-ID: <3CFF7CD0.ADE18819@galdosinc.com>
To: Anupam Joshi <joshi@cs.umbc.edu>
CC: "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>, "'Tayeb Lemlouma'" <Tayeb.Lemlouma@inrialpes.fr>, www-mobile@w3.org, ebiquity <ebiquity@cs.umbc.edu>

Remember too that RDF provides only the semantics of E-R diagrams.  We can do much
of this XML Schema as well - it is just that you need to add the interpretation on
to the syntax. In GML (geography Markup Language) we do something like that.
Features have properties. Features are global elements and their properties are
their child elements.  I can write for example:

    <abc:Road gml:id = "r1">
        <abc:numLanes>3</abc:numLanes>
        <gml:centerLineOf> .. </gml:centerLineOf>
    </abc:Road>

So I can read this like RDF, i.e. numLanes(Road) = 3, centerLineOf(Road) = ...
and so on.

The RDF/S behind this would look different than the supporting XML Schema - e.g.

    <rdfs:Class rdf:id = "Road">
        <rdfs:subClassOf rdf:resource = "... gml:AbstractFeature" (in GML
namespace) />
    </rdfs:Class>

    <rdf:Property rdf:id = "numLanes">
        <rdfs:domain rdf:resource= "Road" />
        <rdfs:range rdf:resource = " .. #Literal" />
    </rdf:Property>

    <rdf:Property rdf:id = "centerLineOf">
        <rdfs:domain rdf:resource= "Road" />
        <rdfs:range rdf:resource = " .. #LineString" />        (defined in GML
namespace)
    </rdf:Property>

whereas in XML Schema we would have:

    <element name = "Road" type = "abc:RoadSchema" />

    <complexType name = "RoadSchema">
        <complexContent>
            <extension base = "gml:AbstractFeatureType">
                <sequence>
                    <element name = "numLanes" type = "integer" />
                    <element ref = "gml:centerLineOf" />
                </sequence>
            </extension>
        </complexContent>
    </complexType>

Note that the global element declaration is like the <rdfs:Class> declaration in
RDF, and the associated complexType definition is like the Property assignments in
RDF.  Of course we cannot take this too far - RDF expresses a class relationship
(subClassOf) which is NOT the same as the syntactical extension in XML Schema.
Furthermore RDF provides an open-ended mechanism to define more properties for
Road in different name spaces without ever changing the class.  Then again you can
mimic this in XML Schema as well (as we have done in GML 3.0 by introducing RDF's
about attribute.


Cheers

Ron Lake



Anupam Joshi wrote:

>   Hi Mark,
>          RDF does give some more semantics compared to raw XML or XML
> schema. You are, however, correct in asserting that if we really want to
> use a semantically rich representation then DAML+OIL (I believe the
> www-ont group is proposing to call it OWL -- Ontology Web Language) is
> probably the correct choice. DAML+OIL has well grounded semantics -- for
> instance a group at Stanford has provided axiomatic semantics using KIF
> for DAML+OIL. DAML+OIL also provides richer constructs than RDF, for
> instance it will let us express cardinality (this device has n screens),
> disjointedness (this is an iPAQ 3875 which is not the same as Jornada),
> or even Union (iPAQ 3875, iPAQ 3870 are all iPAQs). The latter for
> example could explicitly provide device categories -- you have presented
> your recent work on that here, and we had a paper about it at an ICDCS
> Workshop last year.
>
>   As an aside, we are one of the groups in DARPAs DAML program, and have
> created DAML ontologies for service discovery and composition in mobile
> (infrastructure and ad-hoc) networks. While these are different from
> CC/PP profiles, some of the things they talk about (device capability
> for instance) are common. Similary there is a DAML-S effort from
> Stanford. If folks are interested, they can find our ontologies at
>   http://www.daml.org/ . For description of our research efforts, check
> out http://research.ebiquity.org/
>                                                                 Anupam
>
> Butler, Mark wrote:
>
> > Hi Tayeb
>
> >
> > What exactly are the "semantic advantages" of RDF?
> >
> > Recently I've been reading John Sowa's book on Knowledge Representation. In
> > my opinion there is currently a misunderstanding that if we use RDF we
> > automatically adopt a well founded semantics. This is simply not true:
> > simply using RDF does not influence the semantics of data in any way as
> > semantics are determined by observers i.e. how the RDF model maps on to the
> > real world (in fact, there is a extreme position that says computers CAN
> > ONLY process syntatic structures - for more details see John Searle's
> > Chinese Room scenario[3]). The Model Theory for RDF has helped matters, but
> > I don't see that the model theory is particularly helpful for CC/PP as CC/PP
> > has it's own (unfortunately implicit) intepretation of what is meant by a
> > CC/PP profile.
> >
> > Furthermore IMHO RDF is a rather confusing starting point for establishing
> > well founded semantics as it operates below the ontology level i.e. RDF may
> > be regarded as "machine code" for knowledge representation as there are a
> > lot of similarities between RDF and conceptual graphs, a method of mapping
> > different ontology representations onto a common framework developed by John
> > Sowa[1]. Ideally we should be working at a higher level of abstraction e.g
> > using DAML+OIL[2] as a basis for knowledge representation rather than RDF.
> >
> > For more details see
> >
> > [1] Sowa, J. F. Knowledge Representation, Brooks/Cole, 2000. ISBN:
> > 0-534-94965
> >
> > [2] About DAML, http://www.daml.org/about.html
> >
> > [3] Chinese Room arguement, http://www.ptproject.ilstu.edu/pt/chinovrv.htm
> >
> >
> >>The problem is in XML serialization of RDF.
> >>Why don't we think to adopt another XML serialization of RDF for
> >>CC/PP, or for general purposes?
> >>
> >
> > Currently it is very difficult to introduce changes to CC/PP i) because we
> > (the CC/PP Working Group) are constrained by the charter ii) we are at a
> > stage in the process where it is not possible for people to submit comments.
> > We are currently trying to move the CC/PP structure and vocabulary document
> > to candidate rec, to overcome problem ii) but I would like to see problem i)
> > addressed as soon as possible.
> >
> > regards
> >
> > Mark H. Butler, PhD
> > Research Scientist                HP Labs Bristol
> > mark-h_butler@hp.com
> > Internet: http://www-uk.hpl.hp.com/people/marbut/
> >
> >
> >
Received on Thursday, 6 June 2002 11:17:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 13:00:01 GMT