W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

RE: [sysinfo] draft ready for review

From: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>
Date: Wed, 23 Dec 2009 18:38:49 +0100
To: Max Froumentin <maxfro@opera.com>
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>, "public-uwa@w3.org" <public-uwa@w3.org>
Message-id: <93AA9E47B82F684A868C217766F489053A97843D72@EXCLU2K7.hi.inet>
Hi,

Although I understand your position I would like to have some mechanism to ensure there are no inconsistencies between the ontology and the API. 

What about having some kind of automatic generation of API properties from a branch in the ontology? Ensuring, for example, that the name, data type and description (precise semantics) of the properties in the API should be the same as the name of the properties in the ontology. 

However there is an issue as the ontology has not created a property for everything, as there are some properties which can apply to multiple entities, for example 'vendor', 'model' or 'version' can apply to multiple entities, CPU, Battery, Camera, whatever. 

Also if this mechanism is sufficiently documented will allow third parties to extend the API taking as input other properties present in the ontology. 

By the way, the ontology does not include all the CPU properties you are considering. They will be added for the next version. I think your API specification can indeed provide a very good input for the ontology. 

I just want to be sure there is consistency between the specs.

Best R. 

-----Mensaje original-----
De: Max Froumentin [mailto:maxfro@opera.com] 
Enviado el: lunes, 21 de diciembre de 2009 14:30
Para: JOSE MANUEL CANTERA FONSECA
CC: public-device-apis@w3.org; public-uwa@w3.org
Asunto: Re: [sysinfo] draft ready for review

On 21/12/2009 13:10, JOSE MANUEL CANTERA FONSECA wrote:
> Hi,
>
> the spec looks good but my concern is that you are duplicating the
> work already done in the Delivery Context Ontology specification.
>
> I think it is needed to have cross-reference between this API and the
> DCO specification whenever possible, in order to have a normative
> definition of each property in only one specification

I think that this specification rather selects a few properties, which 
you should be able to find in the much more exhaustive DCO 
specification, and incorporates them into a self-contained document, 
IMHO following the simplicity principle mentioned in the charter of this 
WG.

As noted in an issue of the draft, we need to map its properties to 
DCO's, if possible, and perhaps add that the other properties from DCO 
can be used in get/set/watch, if corresponding callback objects are 
defined. Perhaps you can help with that. Just now I looked for where in 
DCO is the CPU's current frequency but couldn't find it, so I obviously 
need assistance.

Max.
Received on Wednesday, 23 December 2009 17:39:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:04 GMT