W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2000

RE: CC/PP, RDF and trust issues

From: McBride, Brian <bwm@hplb.hpl.hp.com>
Date: Tue, 2 May 2000 16:46:51 +0100
Message-ID: <7686E88F1253D311A867006008CD059F010B1D72@0-mail-1.hpl.hp.com>
To: Graham Klyne <GK@Dial.pipex.com>
Cc: www-rdf-interest@w3.org, CC/PP WG list <w3c-ccpp-wg@w3.org>
Graham,

As I understand it, the problem you have stated is:

1) There is an application involving the description of device
capabilities using RDF.

2) It would be good to include in that description an 'assurance',
i.e. a statement that some entity is asserting that these are
the true capabilities of the device.

3) There is a concern about the complexity of reification in RDF
and you are asking whether there is way to represent this assurance
without using reification.

4) You are not asking about ensuring the truth of the RDF;
you believe that is covered elsewhere.

I wonder whether the following would meet these needs:

Consider a resource which is a DeviceCapabilitiesDescription.  It has
three properties:

	o device - the device being described
	o capabilities - an anonymous resource which collects the properties
of the device
	o assurance - the entity asserting that these are the correct
properties

This is a simple model and might be represented as an RDF serialization of
the form:

<rdf:RDF
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:ccppX="...">

   <ccppX:DeviceCapsStatement>
      <ccppX:device>...</ccppX:device>
      <ccppX:assurance>Brian Says This</ccppX:assurance>
      <ccppX:capabilities>
	  <ccppX:colours>2</ccppX:colours>
	  <ccppX:keyboard>12 digit pad</ccppX:keyboard>
	  ...
	  ...
      </ccppX:capabilities>
   </ccppX:DeviceCapsStatement>
</rdf:RDF>

I think this is pretty close to your original suggestion.   I don't know of
anything wrong with it, but I know about as much about knowledge
representation
as I do about cryptography (not a lot).

Brian McBride
HPLabs
Received on Tuesday, 2 May 2000 11:47:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:43 GMT