Meeting minutes
Minutes review
<kaz> Feb-8
(Kaz walks through minutes)
Kaz: respec issues ...
McCool: can ignore for now
(minutes approved)
status of document checks
McCool: for discovery we still finish a big PR, will go over the whole document
terminology
McCool: mmc: there's a new terminology topic - we cannot use consumer, since discovery is optional in architecture
… we we are using d-client or d-consumer
Lagally: explorer?
McCool: already in use
Kaz: we should think about 2 levels of definitions: for device layer and software layer (i.e., real vs virtual)
McCool: some confusion on devices that have multiple things
… is node-red a consumer?
… need a word for entities that have a network interface and are not described with a TD
Lagally: why not use a TD for devices with a network interface?
McCool: different descriptions for outgoing connections. It is redundant from a security perspective. IETF works on MUDs.
… we could work on that in the next round.
… a consumer reads a TD
Kaz: we need to describe the two layers first, and then can discuss how to deal with "producer" vs "consumer"
McCool: we should define a device, which may have a network interaction.
Lagally: proposed definition: a device is a thing with a network interface
McCool: RDF can be used to describe entities, SSN describes features of interest.
Lagally: these are out of the scope we describe in WoT
McCool: thing is used in wide sense for entities
… we should not duplicate RDF
Ege: entities that do not have a TD, what do they have?
… script running in a computer or browser - we can have a description format, you can start with metadata, if you describe code we go into domain specific languages.
… if we have a TD with only metadata, who consumes it?
… I don't think we must have TDs for all entities
McCool: purpose of use cases is to narrow our scope
… need to be very precise, should not extend the scope
<kaz> oneM2M Definitions and Acronyms
<McCool> (to capture my point: suggest that Things are entities described by Thing Descriptions. Full stop.)
Lagally: we should not overcomplicate the discussion, not include further ontologies
Kaz: we should consider definition of entities, and we might want to look at oneM2M's definition and borrow some concepts from that :)
(detailed discussion about mqtt, endpoints, ...)
Kaz: we should distinguish 2 layers, physical and virtual. and those 2 layers should include at least device/application and Thing/Consumer.
McCool: agree before diving into detailed discussion about concrete definition, we should use a device and application
Lagally: can a TD only describe devices?
McCool: a SW service could also be a thing.
… the word device is useful, things are more broadly
… virtual thing / real things are used confusingly
Lagally: changing terminology will have a lot of ripple effects
McCool: we should avoid inconsistencies in terms
Kaz: we should start with a small set of definitions, may need to extend based on use cases
… in these discussions we can define what a thing can be. for example, how to handle a management Thing implemented as a software application for several physical devices.
McCool: two definitions are lacking: device, services
Lagally: can you please come up with 2 MRs for architecture?
<McCool> https://
Ege: would still prefer to distinguish virtual things, digital twin is a service, shadow for a physical device
McCool: a shadow is a class of entities that simulate other things
Ege: non-device things?
Kaz: let's start with this model and extend it based on our concrete use cases before considering theoretical variations.
McCool: virtual thing is a kind of service that represents another thing
… let's also define digital twins and shadows
<McCool> https://
<McCool> https://
<kaz> kaz: let's continue the discussion during the Architecture call
<kaz> [adjourned]