Should the S3I Directory entry reflect the structure of the real Thing?
As we discussed in todays S3I weekly, we should reconsider what information should be stored in the S3I directory and specifically if nested Objects are the way to go.
I believe there is general agreement, that the S3I Directory should contain the interface specifications of Things. That is their available Values/Services/Events with information on how to access them like protocol, dataformat, schema and Endpoints.
Current
The current directory data model encourages modeling the directory entry after the physical or logical structure of the real Thing by requiring at least one object. We also encourage this via the usage of ml4.0 and its mapping to the directory data model. This practice:
- exposes the Things physical or logical structure, which I consider implementation
- makes the directory entry more verbose and I would argue more convoluted
We also run into these technical issues:
- Ditto imposes a document size limit of 100kb. Entries describing forest things currently exceed this limit. This is not due to the nested object structure, but to the granularity of modeling the structure.
- Addressing of nested documents can be problematic, due to list indices.
Request for Feedback: Is this a fair assessment of the status quo? Am I missing issues?
classDiagram
class Event
Event : TBD
Event *-- Endpoint : endpoints
class Link
Link : association string
Link o-- Thing : targetThing 0..1
Link *-- Object : target 0..1
class Thing
Thing : name string
Thing : identifier ID
Thing : ...
Thing *-- Object : thingStructure 0..1
Thing o-- Thing : childThings
class Object
Object : class string
Object : identifier ID
Object *-- Endpoint : endpoints
Object *-- Value : values
Object *-- Service : services
Object *-- Event : events
Object *-- Link : links
class Endpoint
Endpoint : uri string
class Value
Value *-- Endpoint : endpoints
class Service
Service *-- Endpoint : endpoints
Flat data model without S3I::Object
I suggest that a flat directory data model, i.e. without nested objects, is a simpler yet sufficient way to describe Things. In my mind a Thing is something that is individually addressable.
- If for some reason a component of a large system, like the engine of a harvester, should be individually addressable, i.e. with its own data processing system that is connected to the S3I, it can be modelled as a seperate thing with
"thingType": "component"
and linked to and from the parent. - If a component is not individually addressable there is no reason to model it separately, as all requests go the parent system.
Note that the properties "defaultHmi"
and "childThings"
can be normal Link
s now.
classDiagram
class Link
Link : association string
Link o-- Thing : targetThing
class Thing
Thing : name string
Thing : identifier ID
Thing : ...
Thing *-- Value : values
Thing *-- Service : services
Thing *-- Event : events
Thing *-- Link : links
Thing *-- Endpoint : endpoints
class Endpoint
Endpoint : uri string
class Value
Value *-- Endpoint : endpoints
class Service
Service *-- Endpoint : endpoints
class Event
Event : TBD
Event *-- Endpoint : endpoints