Re: [T2TRG] [Asdf] Representation issues and protocol bindings

[Henk Birkholz <[e-mail]>]

Heya,

in the scope of semantic interoperability it is not unusual to structure 
named types in taxonomies (a fancy word for basically categories of 
categories, etc). Maybe taxonomical tagging (associating with category) 
of various similar (e.g., "temperature"'esque) data model items renders 
the model close enough to an information model - and therefore 
remediates this... creative use?

But maybe the complexity of types and units is too big for such a 
simplistic approach?

Viele Grüße,

Henk

On 31.08.20 16:25, Carsten Bormann wrote:
> In today’s OneDM call, Bruce Nordman brought up the issue that, in the end, we’ll need concrete representations to talk to devices and use their data.
> 
> So if we have one ecosystem that uses 0..100 for describing the brightness setting for a lamp, another one that uses 0..254 (where 255 means something complete different), and a third with 0..65535, what do we do?  (And these might also differ whether they describe a emitted light power level or a perceptive luminous flux level.)
> 
> The underlying problem is that we are abusing data model level description techniques (in part borrowed from json-schema.org) to describe information models.
> That works reasonably well until we start taking these data model level descriptions at face value.  The fact that some converged model uses a scale based on the L component of Lu’v’ does not mean that everybody has to represent their ecosystem model the same way.
> 
> The obvious second problem is that we haven’t tackled a framework for describing protocol bindings (which, initially, will mostly be ecosystem bindings).  That would be the place where we say how the L component needs to mapped to the ecosystem specific concrete representation.  Since that mapping, in principle, can have arbitrary complexity, completely covering all cases requires Turing-equivalent functionality in a description language.  Or we could go for an 80 % solution and then, for the 20 %, register mapping components that are more complex in an IANA registry.
> 
> Let’s discuss this based on some real-world examples — it is easy to construct artificial ones that have more complexity than we actually need.
> 
> CCing T2TRG as well because quite a few people there are familiar with the problem; maybe we want to have the bulk of the discussion on [e-mail] though.
> 
> Grüße, Carsten
>