CC/PP, RDF, DAML and Knowledge Representation

(If you want to unsubscribe from this list, send email to
www-mobile-request@w3.org with unsubscribe in the subject header)

I think our recent discussions on www-mobile have been very interesting so
I'd like to thank everyone for their comments. I would like to outline my
current thinking on CC/PP, based on what I have learnt from the Sowa
book[6]. Note I'm still getting to grips with some concepts here but I'm
interested in discussing my ideas if you will forgive them for not being
fully formed. 

As I mentioned before, I think CC/PP needs a clear data model or
interpretation. I don't think we have this at the moment and I think it is
causing confusion. Specifically there seems to be misunderstanding that as
RDF is the basis of the Semantic Web, that simply using RDF adds "semantic
understandability". RDF provides well founded model-theoretic semantics [1]
i.e. an abstract mathematical account of how to interpret RDF model but it
does not automatically provide real world semantics i.e. an interpretation
of the model as statements about the external world. So even when we use RDF
we need to give some though to our data model so I'll try to outline my
current thinking.  

I think the data model needs to consist of two things. Firstly it needs
attributes (or properties depending on your terminology) e.g.

SoundCapable -> No
Accept -> [text/html, image/gif, image/jpeg]
AcceptLanguage -> [fr, en]

i.e. single valued, set valued or sequence valued respectively (we'll ignore
the issue of data typing for the moment). A couple of points here i)
attributes are 80% of the functionality of CC/PP ii) it's pretty easy to
represent attributes in XML or RDF, which I guess makes people question why
we need RDF. 

However attributes are not the whole story. I think the other thing the data
model needs is contexts (see John Sowa "Knowledge Representation", p.268).
Sowa defines contexts as "Complementary ways of describing the same object
can be mixed, but only when the contexts are explicitly distinguished. ...
(For example) Tom was a baby in 1976 but an adult in 1997". Graham has done
some work on contexts - see [2]. In CC/PP we already encounter examples
where we describe the same object in complementary ways e.g.

1) The device has the set of capabilities X, and X contains capabilities V,
then the proxy allows capabilities Y but blocks capabilities Z. 

2) The device has the default set of capabilities A and the standard (i.e.
non-default) set of capabilities B.

So are X, Y V and Z in 1 and A and B in 2 talking about the same object?
Well it depends on your interpretation. I'd argue they are talking about the
same object i.e. the constraints that a server must meet when returning
content to a device. 

In CC/PP, these situations are represented by preceding the attributes with
a resource and a property to differentiate the attribute i.e. set its
context. There are three examples of this in CC/PP: components (see Figure
2-1b in [3]), defaults (see Figure 3-4b in [3]) and proxies (see figure
3-11b in [3]. Components though, as I have previously noted, not really
required as generally an attribute can only occur in a single component. 

However representing contexts requires careful thought. If you process an
RDF graph, essentially you have to identify the attribute, then move
backward through the graph to determine its context(s). In DELI[5], to
simplify matters, I process the graph and convert it into a different data
model so the user does not have to deal with RDF. I deal with context partly
by "resolving" multiple instances of the same attribute i.e. merging
defaults and non-defaults them together. In other cases the context is
recorded in the attribute i.e. component is a property of the attribute.
Hence in DELI, contexts are not first order citizens like attributes.
Perhaps DELI is using the wrong data model?

Also, one of the things I'd like to see in CC/PP is the ability to AND and
OR attributes as you can do in Media Feature Sets [4]. CC/PP already has an
implicit interpretation of profiles as ANDs and ORs: all the attributes in a
profile are ANDed except for complex attributes where the individual values
are joined by ORs. It would be good to able to use ANDs and ORs in a more
general way, e.g.

if portrait then 
	ScreenWidth -> 240
	ScreenHeight -> 320
if landscape then
	ScreenWidth -> 320
	ScreenHeight -> 240

However this requires contexts! So perhaps if we had a general way of
representing contexts, we could use them to provide AND / OR conjunctions
also. 

I'm sorry if the concept of a context seems abstract (I still don't fully
understand it myself) but I think we need to be able to discuss issues like
this without dropping down to the XML or XML serialisation of RDF as having
a clear data model will help regardless of the format we use.

As ever, suggestions / comments / criticisms are welcome. 
   
[1] Hayes, P., W3C Working Draft, RDF Model Theory, 29 April 2002,
http://www.w3c.org/TR/rdf-mt/

[2] Klyne G, Contexts for information modelling,
http://public.research.mimesweeper.com/RDF/RDFContexts.html

[3] http://www.w3.org/TR/CCPP-struct-vocab/

[4] Klyne, G. IETF RFC 2533: A Syntax for Describing Media Feature Sets,
March 1999 http://www.faqs.org/rfc/rfc2533.txt

[5] DELI, http://delicon.sourceforge.net/

[6] Sowa, J. F. Knowledge Representation, Brooks/Cole, 2000. ISBN:
0-534-94965

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 Friday, 7 June 2002 10:57:20 UTC