Need model for color lights

[amedranogil]

Device/physical world ontology must be updated to include color (maybe compatible with web colors), and color changing devices.

[cstockloew]

Just some thoughts:

Can there be only one generic color ontology that is used in different domains? Or should there be different ontologies? If so, how can there be a mapping?

What are domains in which a color play a role? For example: Light generation by light sources (lamps), reflection of lights from objects, mixture of lights, printers/screens...

What color models are available? RGB, HSV, CMYK..

Apart from the color model (like RGB), there are concrete, named colors (red, pink). Some colors are specific for certain domains, e.g. "blonde" is only used for hair color.

What about color groupings / moods? Some colors have a positive "effect" on humans (yellow, green), some are more a warning signal (red).

Colors from the same light source have different effects when mixed with different surrounding colors (e.g. screens that get darker in the evening to have always the same perceived brightness).

What exactly do you want to do, i.e. what device are you talking about? What functionalities does it have, how do you set/get a color for this device? What about other, similar devices? How is the change parametrized, e.g. can you set a speed? Can you set a color scheme (making a change only in a certain group of lights)?

What is related work?

[amedranogil]

The main issue is with colour lights (philips hue) and LEDs (typical strips), universAAL currently is not compatible with colour, and colour changing lights. But the idea is that the concept of colour is generic so it fits many domains. We will need a hiearchy of colour, which defines colour modles (such as RGB, the others you mention together with the webpallet, so we have "red","pink", etc; and light temperature), as well as services to transform between each model. In fact this reminds me of a semantic service defined in the measurement ontology to transform measurements from one unit to another. Is colour a MeasurableDimension? and do the "color models" represent different units of measurement of this dimension?

You are right, we need define colour changing functions for devices, but this issue is the same with light brigthness change. I have seen some APIs of colour changing lights (chinese, IDK the name, I don't even know if they have a name) for which half of the serivces are used just to define colour and brightning change effects. As for colour moods, I think the best option here is to propose a "emotion" ontology, where one concept is "emotion-inducing-thing" that can be then addded as super class of devices/colours in a mapping ontology as the specific domain/deployment requires.

[amedranogil]

what does make more sense semantically ?

A

a new "colour device" which has the properties colour and colour unit. then let those sensor that use colour implement both their native class and this new class (eg: a colour light would be modelled by lightController and ColourDevice; same with light sensor).

B

a sub class of Light actuator/controller with the properties colour and colour unit. If we had a colour sensor then it would either be a new sensor or a subclass of light sensor.

[Alfiva]

I don't see much sense in having a "colour device". The benefits would mostly be "programmatical", I think. Which may be a good thing for its own reasons, though.... Anyway, I would go for B, from a not-very-confident position.

[amedranogil]

quick question en_EN or en_US? i.e: "colour" or "color". I'm currently moving towards en_US as most programing languajes use that spelling.

[Alfiva]

fair enough

[amedranogil]

Please check branch issues/2 before merging. Check:

• [ ] the semantics of color are as agreed
• [ ] the added restrictions (specially on ont.device) make sense
• [ ] there is no other stupid mistake (like forgot to rename some colour)

[Alfiva]

Perhaps the COLOR property could be a Color object with a proper ontology, but for now I guess it will do.

[amedranogil]

This is a good suggestion! Maybe for that it would be best to create a new ontology ont.unit.color where the color spaces, units, abstract color object (wich forces a color unit) and subclases of the color object for each of the color spaces, each defining the properties it needs, maybe even helper methods (for example to easily create an RGB object from a static method). This would also avoid having to have 2 layer restrictions, and it may be easier to map and reuse.

[amedranogil]

done, Please review again. @cstockloew please review specifically UnitOntology.java@346 and sucessive.

[amedranogil]

Merged.