RDF related comments on DPF

Hi

this is the third of four related messages:
   - editorial comments
   - substantive comments
   - RDF related comments
   - brief biographical introduction



This message contains comments on

http://www.w3.org/TR/2004/WD-DPF-20041122/

This set of comments are informed by Semantic Web work, and are
intended to explore the possible relationships that could be
found between DPF and RDF (and possibly RDFS and/or OWL).

This comment is made jointly with my colleague Mark Butler.


Summary:

In our view the DPF provides a framework for device manufacturer's
to use a proprietary and unpublished interface into their device,
and does not clearly articulate interoperability goals, nor does
it achieve an appropriate level of interoperability. Without some sort
of schema language to publish property definitions
it is severely hampered. The W3C already has a recommendation, CC/PP,
which in turn builds on RDF and RDFS, for describing properties in such
situations. The Device Independence WG is currently exploring the use of
OWL to enhance such descriptions. Therefore we think it is important 
that DPF
should be compatible with CC/PP and RDF, RDFS and OWL, and use them when
appropriate, and there probably needs to be some coordination between
these groups on the best way to do this.


Also Dynamic Properties are not inherently different from
(more static) Resource Descriptions, and hence it seems
insufficiently motivated to not define a mapping between DPF
and RDF.

r1. Properties with both values and child properties?

The specification of a DPFProperty allows for a property
to have both a value and to have children.
No examples of the use of this feature is shown.
It would be less confusing to have two different
subinterfaces of DPFProperty: one that had a value but
no children, the other that has (possibly 0) children,
but no value.
In the latter case, it then seems that the collection
of children of a DPFProperty describe an (unnamed) resource
that is the value of the parent DPFProperty,
e.g. in Figure 2, the property "GPS" has a (resource) value that
is described with two properties "IBM:GPS" and "NOKIA:GPS"

r2. DPFProperty hierarchies as RDF Graphs

We redrew fig2 as in the attached PDF file.

We simplified the lines, so that they just show
parent/child relationships, and not sibling relationships.

We added arrows to the lines rather than relying on the
vertical convention of parents above children.

We clarified that the labels (except DPF component) were
describing the relationship between parent and child,
rather than describing the child

We also added a little bit more, to show how a value
could be drawn in the picture, as a leaf node, with the
value labelling the node.

This picture then is an RDF graph, and conveys much of the
information of fig 2.

The (implicit) resource values of the properties are made explicit
as unnamed circles, and the property names are used to appropriate
link the ovals in the diagram.

This diagram does not suffer the problem of figure 2 that the labels
GPS and IBM:GPS and NOKIA:GPS are used to show the relationship between
the parent node and the labelled node, whereas the label "DPF Component"
does not, which is visually confusing.



r3. Is the order of children important

Our RDF graph  differs from figure 2 in that no ordering is
given between the sibling IBM:GPS and NOKIA:GPS elements.
This seems to us to be a better design.

Most of the time ordering is artifactual. e.g. an x,y coordinate
pair
   <x>4</x>
   <y>5</y>
describes the same point as
   <y>5</y>
   <x>4</x>
since the ordinates are labelled.

Application code that relied on the x coordinate coming before the
y coordinate, by for example, getting the first and the second
children, rather than the x child and the y child, would, in our
view, be broken. (e.g. it would not work if there was a new
child labelling the point with a string given as the first sibling)

In the (relatively few) cases where ordering is important then
making the tree deeper to express this seems appropriate.
e.g. an rdf:Seq construct can be used, with properties
rdf:_1 rdf:_2 rdf:_3 ... for the first, second, third values


r4. Tree or Graph?

I am currently using a Microsoft Windows OS, it gives me a tree like view
of my computer hardware, under the device manager.
I can choose between two views of the devices
   Devices by type
   Devices by Connection

My understanding is that when I look at the properties of my DVD drive 
it is
the same drive whether it's parent is a USB Mass Storage device whose 
parent
is the USB Hub, or if its parent is DVD/CD-ROM drives whose parent is my 
computer.

So I am presented with two different trees whose leaf nodes are the same 
sets.

This seems to be a highly desirable feature if the goal is to allow
different applications integrating devices from different manufacturers, 
since
the different people involved with the development of the various 
applications
and devices will have different views of the world. These different views
will be reflected in different choices about how to structure their
representation of the world, yet ... some of the concepts being used
are the same and do represent the same devices.

We note that even in the more tightly controlled world of a Microsoft OS
it is helpful to have  multiple views.

In the XML world, it is natural to try to describe the world using tree
like views. However, as RDF is a graph, it is possible to have a
flexible representation where leaf nodes can be reached by multiple
routes, accomodating different views of the world. Being able to
accomodate such multiple views may be important as the goal here is to
allow different applications integrating devices from different
manufacturers. These different views will be reflected in different
choices about how to structure their
representation of the world, yet ... some of the concepts being used are
the same and do represent the same devices.

RDF also stresses the idea that such representations should be designed
from a semantic, rather than a syntatic viewpoint, and uses URIs to
unambiguously identify subjects and properties. This approach should be
used when designing representations in DPF.

Specifically DPF can gain some of these advantages if two small changes
are made to DPFProperty:
  - permit multiple parents (not simply one or zero)
  - add a label, either a URI or a locally scoped identifier
    which identifies the instance which is the value of this
    property (when no literal value, string or other is given)



r5. Interoperability aspirations

As far as we can tell, DPF does aspire to providing interoperability
between devices and applications developed fairly independently rather
than having a tight coupling between devices and applications.

However, no mechanism is provided for publishing the description
of the properties supported by a particular device, or for publishing
a description of the properties needed by a particular application.
Without such mechanisms, functioning systems will require close
cooperation between the device and application developement teams.
There has been work both in CC/PP and within the OMA in UAProf
on this problem, so there needs to be some coordination to ensure
these approaches are compatible.


r6. Property definitions etc.

RDF Schema and the Web Ontology Language OWL provide mechanisms
to define properties, including:
   - labels for the property in multiple language
   - giving the types of the subject and the object of the property
   - relationships such as subPropertyOf between this property
     and other properties.

The Device Independence Working Group have been working on using
OWL to describe properties collaboration and coordination should
be explored.


r7. Constraining the use of properties to certain types
(Open world/closed world issues)

A basic assumption in RDF and OWL is known as the open world assumption.
This is that all descriptions are regarded as incomplete and extensible
in any way not explicitly prohibited.
One of the unfulfilled aspirations of DPF is for some sort
of type constraints in the use of properties. While such constraints
can be expressed in OWL it is quite difficult.
An example of the difficulty can be given using RDFS (which is a subset
of OWL).
In RDFS it is possible to describe the domain of a property (i.e. the
type of resources to which it is applicable) and the range of a property
(i.e. the type of resource which may be the value of that property).
However, a resource can have many types, so that having superficially
conflicting domain and range rules does not actually cause a conflict,
merely multiple typing. So if we had a property that was only applicable
to nokia GPS's and (mis)used it on an ibm gps, we would (unfortunately)
conclude that the ibm gps was also a nokia gps. This can be
addressed in OWL by, in one way or another, saying that no resource
is both an ibm gps and a nokia gps.

For an explanation of the often misunderstood relationship between RDF
Schema, OWL, inference and validation please see
http://esw.w3.org/mt/esw/archives/000048.html


Jeremy Carroll
Mark Butler