More questions on Delivery Context Ontology

Background:
I'm looking at the Delivery Context work to model work I need to do re: describing capabilities on production-level systems, e.g., mail finishing systems.  Given the constraints of the area and the amount of investigation relative to time available, I've tried to recast the overall model into XML Schema (see http://www.openmail.us.com/DeliveryContext.html for more justification of this foolishness)  with the idea that should OWL become effective for production systems, that we could easily (automatically) translate the XML docs into OWL docs. The schema files can also be reviewed from the link above. Eventually, I will try to specifically document where I diverged from the models in the official version of the ontology. For now, I need to ensure that what I have is usable in the context of the openmail project.

Questions:
Here are a few more questions in addition to the three questions appended below. Please note that some of the questions may arise from my unfamiliarity with the intricacies of OWL - I'm still getting comfortable with the language... Also, re: the rigors around the W3C last call...  My intent is not to be disruptive. Rather, I think the work has progressed REALLY well. Just wanted to let you know how it looks to a relative newbie.


4.       The idea of a location provider should be generalized, IMHO. For example, I can foresee other types of external (third party) network services emerging for mobile devices. For example, the function of smart cards could migrate into more universal mobile devices, and so the idea of a funds provider and/or authentication service may emerge.

5.       Why is estimatedPosition part of LocationProvider. How does it differ from currentLocation and LatsKnownLocation?

6.       General comments on types. (I'm asking this because processing of information will - for some of us anyway - likely be in a strongly-typed language):

a.       Is there a reason you use floats and doubles? For example, the notions of Northing, Altitude, PixelAspectRation, etc at floats. The notions of a position's Course and Speed are doubles. Is there something about position that required the added precision of a double?

b.      Is there a reason you use both int and unsignedLong for countables? I.e., integer makes sense over unsignedLong when negative values needed. However, there is another issue here. If unsigned longs are being used for countables that can get really large, e.g., CPU Frequecy, the gain of unsigned long (which can count up to 4,294,967,295)  over integer (which can count up to 2,147,483,647) is limited. Float may be better, with reasonable 2009 units. For example, assuming that the units of CPU Frequency are in units of Hz, even an unsigned long may not be enough. Also, memories of 8GB (with advent of 64 bit machines) are now coming out. Unsigned long is not enough. In addition, the use of int for bandwidth may be a problem. There are networks (e.g., OC192 at 9.6 Gbit/s) that already exist, according to Wikipedia.

c.       Should typicalResponseTime have xs:duration as the type?

d.      Why are LongitudeZone and LatitudeZone different types? This is counterintuitive to geo-novice.

e.      What are the assumed units of battery? Charge or energy? Is this obvious?

7.       From what I can see, an Aspect is something (specifically components) for which the ideas of "supported," "default," and "active" make sense. Why are DeliveryContext and Device Aspect subclasses? ... And Environment not? Also, why is Proxy listed directly, and indirectly via SoftwareAspect/Program?

8.       The existing property definitions seem to make the nuances of 'supports' explicit, ie. things can be supported, but not available (e.g., you might need to download and configure to make a supported item available), things can be available but not active. Of the things that are available, some may be part of a default configuration for the device, some may be a part of the preferred configuration of the device. However, there appears (to me) to be some inconsistency, re: sub-classing the notion of supports. Available is a sub class of supports (makes sense to me). Default is also a subclass of supports.  Seems like default should be a subclass of available. Also, there are components that have the notion of preferred. Shouldn't there be a subclass of available called preferred.

9.       soundMode is an object property with device as a domain...  Why is this needed over and above the mute property provided for sound-oriented I/O devices (e.g. Microphone and Speaker).

10.   Are you assuming there can be only one operating system on a device, as suggested by the fact that there is no currentOperatingSystem property? PCs can now run multiple operating systems (both via dual boot and virtual machines). This feature could conceivably move "down" to mobile devices.

11.   There are properties that do not have domains that seem like they should, e.g., height (which should have the same domain as width) and version (which, to me, should be a peer to name). Also, I would think that there should be properties that link things like PageMarkup, StyleLanguage, ScriptLanguage, and WebBrowserFeature to WebBrowser.  If there is - my apologies, I missed it.

12.   Why is the domain for totalMemoryForJavaApps Device? Shouldn't it be JavaRuntimeEnvironment?

13.   Why is inputCharacterSets a peer to input device, in DeviceHardware? Couldn't the Char set be dependent on the input device? Ditto with outputCharacterSets.

14.   Both Content Type and Format are provided for in the model.  Seems like these are redundant notions to me and there is an inconsistency that arises.  For example, MIME_TYPE_GIF is a ContentType individual while gif87, gif89a, jpeg, png, etc. are individuals for ImageFormat.  There is no appearance of content type in the individuals I looked at for specialized formats.


Things I can't yet figure out
I'm having problems with the whole modeling of networks, network bearers, and location providers. Right now, they seem to be modeled as a part of the device, with a special emphasis for currentNetworkBearer (as opposed to currentNetwork).  My model is that from the delivery context perspective, there are networks available in the physical environment that may have associated network bearers. The device can use these networks based, in part, on available hardware components and the internal configuration of those components and what the user wants/needs to do.



Hope you find at least some of the above useful. Again, my hope is too work "in spirit" with the standard by maintaining the basic informational model (as opposed to technological model) and so be able to move to the OWL representation for the information when/should OWL make sense for production machines.

Cheers,
Deborra Zukowski


From: JOSE MANUEL CANTERA FONSECA [mailto:jmcf@tid.es]
Sent: Friday, July 03, 2009 3:25 AM
To: Deborra J Zukowski; public-uwa@w3.org
Subject: RE: Questions on Delivery Context Ontology

Dear Deborra,

Your questions are indeed useful and needed. We are in last call now and it is our duty to provide you formal responses about all your questions

We will respond soon to your questions

Thank you for your feedback,

Best Regards

De: public-uwa-request@w3.org [mailto:public-uwa-request@w3.org] En nombre de Deborra J Zukowski
Enviado el: martes, 30 de junio de 2009 22:11
Para: public-uwa@w3.org
Asunto: Questions on Delivery Context Ontology

Greetings,
I'm trying to understand the underlying assumptions about the structure of the Delivery Context Ontology as a framing for work that I need to do, re: describing capabilities of head-less devices for transformation of web-based content. I'm trying to work through the document, though am a newbie wrt OWL...  From what I can see, there has been a good deal of progress from the initial version, though there are still a few things that I do not understand, and may be based on the notion that this is for mobile devices...


1)      Characteristics about the notion of a Display seem to be scattered throughout the ontology, e.g., usablePixelsX and usablePixelsY have Delivery Context class as a domain while characterColumns and characterRows have Device class as a domain. Is there a reason why these properties do not have Display class (and only Display class) as their domain?

2)      Bluetooth stuff is similarly spread across the ontology. My recollection of Bluetooth (from 10 yrs ago) is that it is a type of Personal Area Network (as is ZigBee, etc.). If there a reason why Bluetooth is considered part of the Hardware Aspect rather than part of the Network Aspect of the device?

3)      Here's a nitpick...  Why does Device have a Width property, but not a Height property? Also, is this the width (and height) of the overall device or the width (and height) of the display on the device. If the latter, how do you handle devices with 2 displays, like my cell phone?

I am going through the Ontology very slowly and will likely have more questions along these lines. Are these useful to you, i.e., do you want me to send a more comprehensive list of questions?

Cheers,
Deborra Zukowski

PS. David, I have a cut and paste error re: the W3C working group address above. Please use this one, should you want to join the conversation.