Re: HA Object Model or Taxonomy?

[Gavin Sallery <gavin@xxxxxxxxxxxxx>]

Much to reply to, here! I will get round to it soon, but in the
meantime... am I being daft, or is the upload mentioned in this post
somewhat elusive?

Cheers,

Gavin


On 20 Mar 2012, at 10:48, alan.trevennor@xxxxxxx wrote:

>
>
> --- In ukha_d@xxxxxxx, Gavin Sallery <gavin@...> wrote:
> >
> > And now to the detail...
> >
> >>> There are very few general questions which could be asked
of any object in an automation system and generate a meaningful, uniform
response across all participants
>
> Indeed, a getState() method would probably have general applicability
in all appliance objects, so it could be inherited by everything that falls
under there, but only be applied patchily elsewhere. The cushion would not
be under appliances, it would probably be somewhere under
\fittings\furnishings\accessories or some such.
>
> >>> better to break things down and have a getPlumpness
method for the cushion, and a getIntensity for the light.
>
> Yes.
>
> >>> The model should definitely be able to represent (or
codify) any object which is likely to become involved in a home automation
system; for practical reasons, this is likely to be limited to that subset
of objects which can be controlled remotely via some sort of electronic
means.
>
> Yes, but a lesson of the last couple of decades is that technology
appears in previously unexpected realms. For examples, heated gloves,
clothing with built in power collectors, motorised seating, pens with
cameras in, digital paper etc etc. To me, that means that although it may
not be a current requirement, nothing should be out of scope for an HA
object model, even though it may not be made explicit in current versions.
I think that's pretty much what you meant too?
>
> >>>Representation of these objects should include exposing
attributes which can be queried or manipulated, for any properties of the
object which are relevant to a home automation use case.
>
> Agree again, with the same reservation, that things that previously
were out of scope could be brought in to reflect developments we may not
even be able to guess at now. Someone designing this in the 1970s would not
have given a phone a currentGPSLocation property for example - we used to
call places, now we call people.
>
> >>> The question of ontology is less straightforward. Does an
object in an automation model have significance (or indeed reality?) only
because of its relationships with other objects in the model? For some
items such as light switches, these are clearly meaningful only once you
know to which light they are connected - so perhaps a reference to the
light should be included in the model of the switch.
>
> Yes, there is a tightrope to walk in this regard, and falling either
side of it means certain death to the model! Like all object models, I
think the trick is to focus much more on what things ARE, not what they
currently DO. This maxim seems to me especially true for HA objects.
>
> To continue your example, an instance of a dumb light switch should
really only have a few properties such as canOperateManually, currentState
physicalLocation and perhaps if it's a fancy fitting, stuff like
switchSurroundIlluminationState.
>
> It should generate just a few events such as manualStateChangeRequest
(when a human presses the button to make it go on or off), lightOn (a
response to a setOnState method invocation to automatically turn on the
lights) and lightOff.
>
> It should have minimal methods like setOnState(true or false),
setSwitchSurroundIlluminationState and perhaps setManualOperationEnable
>
> >>> ...in a real home automation system based upon the object
model there would probably be a need for something to maintain a list of
objects which were "listening" to the state of the light sensor,
but I would argue that this is a property of the implementation, not of the
model itself.
>
> Yes,in a lot of HA kit at the moment relationships between elements
are hard wired or handled in highly proprietary ways. If an object model
like the one we envisage existed, compliant HA devices from multiple
manufacturers would generate and respond to model-compliant messages which
could be dynamically coordinated by open source management applications
(probably some of the already existing ones). This would mean that the only
relationship between an instance of the light switch and the light (or
lights) it controls would be in the control application's database.
>
> The object model would have nothing to say about whether this
particular light switch object type was for controlling one or multiple
lights. The management application would essentially map event
notifications from objects into calls to other object's action methods.
>
> >>>This is particularly true given the language-agnostic
nature of the model; different mechanisms may be used for communication in
different (machine) languages.
>
> Yes.
>
> >>> Back to ontology - I'm also not sure that the
relationships are as clear-cut as you are imagining. In the case of your
illuminated house sign, is it clear that this belongs in
"fittings.illumination.lighting.outdoor", rather than
"fittings.lighting.signage" or even
"fittings.outdoor.lighting"?
>
> No, it's not 100% clear - and neither can it be; however, a model must
try to take a view on these kinds of issues. I would say, applying the
maxim of classification by what things ARE rather than what they DO, an
illuminated house sign is just an outside light he fact that it for a sign
is immaterial for the purposes of the object model. But, if the sign light
has a on/off timer that can be remotely set by software, then that makes it
a different object type.
>
> Where there is genuinely no single right classification (and, once you
apply the maxim, the incidence does diminish) it should be permissible to
have identical (or mostly identical) objects in different locations in the
ontology hierarchy - but it should be fairly rare.
>
> >>>This is before we even consider the problem of
composition; take the Logitech Squeezebox (a fine music player). This is a
music player (which is clearly an object which we would like described in
our model), but it is also an alarm clock. Modelling an alarm clock also
seems like a sensible thing to do, but then do we build a Squeezebox model
under "media.players.music" or "timers.alarm"? The only
sensible answer is that the Squeezebox is an instance of both an alarm
clock and a music player, which forces us away from a simple hierarchy and
into a more complex inheritance-based graph. This is not a problem, and in
fact suggests that we should be thinking in terms of traits rather than
objects.
>
> I see no problem with single devices registering themselves as
instances of multiple object types provided, in the implementation, there
is a mechanism for them to pre-declare a nailed-up relationship between
those objects. Alternatively, provision could be made in the model
(probably at the top level) for "compound object" types, which is
pretty much your suggestion, I think?
>
> >>>This would be the case with all the various TV
implementations - the model's representation of a TV would contain only a
common subset of the features of all televisions, but a TV manufacturer
would be free to extend their implementation of the TV object with their
own particular bells and whistles - though the hope would be that once a
feature became common, it would be incorporated back into the model...
>
> Yes, as well as providing the means for custom extensions (which would
not be part of the standard, just per-manufacturer expediencies) the model
would be totally open to properly justified new additions. That more or
less dictates that it would have to be maintained by a single entity of
some kind.
>
> IMO this is precisely the sort of thing that an organisation such as
DLNA should have been doing - and to some extent they have, but in a highly
exclusive paying-members-only kind of way; but that's not what the HA
market needs to allow it to attain universal take-off - as previously
discussed 8-)
>
> Anyhooo - I'm uploading with this post, the top-level view of the
object hierarchy that I have developed so far. Don't get too excited, it's
only my incomplete start point! It has all the major areas that I envisage
would be needed, and I have assigned node codes to it for reference.
>
> I'd be very happy to received any comments from you, Gavin, or anybody
else on this.
>
> One comment of my own, after much agonising I decided it was sensible
to differentiate between things that are fittings (i.e that which would
remain in place if you moved out) and appliances, things that would
disappear if you moved out. This means that central heating, for one
example, sits in a different branch than portable space heaters. I still
can;t definitively decide if that is a worthwhile distinction?
>
> Best regards
> Alan T
>
>



[Non-text portions of this message have been removed]



------------------------------------

<*> Join the Automated Home Forums
http://www.automatedhome.co.uk/vbulletin/