- 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>
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 UTC