<DarkoAnicic> Lindsay's slides
<inserted> scribenick: kaz
Lindsay: goes through the slides starting
with p11
... [example: entity "vehicle" and its context in NGSI-LD]
... based on json-ld
... [p13: WoT: Thing Descriptions (LINK)]
... [p15: WoT Examples 2: Thing Description as JSON-LD 1.1
Serialization]
... data models for various connectivities with industry
... "writable" for putting information to devices
... "actions" and "events" as well
... would like to see the usage
Darko: are you familiar with our definition of "events" and "actions"?
Lindsay: maybe Martin is
Martin: yes
Darko: representing the current
state
... and then use actions for kind of changing the internal
state
... not obviously visible from outside but can be changed
<inserted> scribenick: DanhLePhuoc
Darko: we actions to change a couple of
properties
... events are used to notify the changes
Martin: our assumption is a bit of
information-centric
... we're implementing our interfaces to focus on data
elements/information
Lindsay: rather than information/data on
lower level services
... the sensor level can be done as well...
Darko: do you assume that you only read information from the gateway or also writing as well?
Martin: we can query the data but we can do other way around...
Martin: it's up the endpoints to do the great thing
Koster: it sounds like in the scope to what we are doing?
Lindsay: we assume that concepts/units can
be pointed to message...
... regarding to specific entity, we use uri..., then we describe
the relationships among them
... regarding WoT, we can use proxies to routing messages...
... we expect all kinds of systems, legacy, database, ...etc
... that they can push messages to the system...
<inserted> mjkoster: if we use zigbee-based light ball, etc., would the connection with your system via oneM2M?
Lindsay: we need to understand WoT TD to see how to integrate with oneM2M
(Danh has trouble with audio connection, and Kaz takes over the scribe)
<kaz> scribenick: kaz
Darko: we have some proxy
... would it make sense to see what standard connect your NGSI
system and provide services?
... what would make sense?
Martin: how reasonable to explore?
... we work for TD and NGSI resources
... could be explored
... the other way around could be making assumption of specifying
something
... general translation model
... at the moment don't have a good idea
Koster: you have an information
model
... could be done by semantic annotation from our viewpoint
... TD translates to your model
Martin: exactly
... you're allowing semantic annotation
... what kind of data we can get from devices
... then we could make some bridge
... there is no way you can create NGSI model directly
... if I have the information, we can translate it using semantic
annotation to get reasonable translation results
Koster: TD has the whole annotation
mechanism
... iot.schema is external schema mechanism
... iot.schema would like to provide small set of definitions
... few simple relation types
... we can refer to other ontologies for industry details, e.g.,
GENIVI for automotive
... other semantic connectors for other concepts could also be get
from outside
... so we would like to do this based on a 2-layer model
Lindsay: same as us
... starting with a different point, though
Martin: do we have any resources?
Darko: TD Editor's draft includes some examples
[[
Example 19: MyLampThing with semantic annotations based on a valid JSON-LD 1.1 representation
{
"@context": ["http://www.w3.org/ns/td",
{"iot": "http://iotschema.org/"}],
"@type" : "Thing",
"id": "urn:dev:wot:com:example:servient:lamp",
"name": "MyLampThing",
"description" : "MyLampThing uses JSON-LD 1.1 serialization",
"security": [{"scheme": "psk"}],
"properties": {
"status": {
"@type" : "iot:SwitchStatus",
"description" : "Shows the current status of the lamp",
"writable": false,
"observable": false,
"type": "string",
"forms": [{
"href": "coaps://mylamp.example.com/status",
"mediaType": "application/json"
}]
}
},
]]
Lindsay: why do you have "observable" as false here?
Koster: observable means asynchronous
event generation
... a bit different from "can be observed", etc.
Lindsay+Martin: ok
Koster: some more comprehensive examples as well
<DarkoAnicic> FESTO TD: https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/TDs/Siemens/FestoLive.jsonld
<DarkoAnicic> Siemens example: https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/TDs/Siemens/FestoLive.jsonld
<kaz> Panasonic example: https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/TDs/Panasonic/airConditioner_p1.jsonld
Darko: goes through the Siemens example
above
... capability of pump
... like "PumpStatus"
... you see "festoPA" which is another ontology
<DarkoAnicic> https://github.com/w3c/wot/tree/master/plugfest/2018-bundang/TDs/Siemens
Darko: it's currently just an example, though
Lindsay: ok
Darko: we explain the capability of pump
using this "properties" notation
... also "Tank102LevelValue" capability below
Koster: here you can get the instance of
tank
... what the equipment is like
... also what the tank would do
Martin: ok
Lindsay: we'll take a look at those examples
Martin: we'll have our meeting next week, so quite busy now
Lindsay: goes back to ETSI slides
... [p19: Information Model]
... you should be able to do query and monitor the
relationship
... the spec is nearly done
... and would like to similar systems
Koster: was wondering
... your use of RDF is different from our usage
... interesting observation
Martin: we have base model
... and different level models
Lindsay: this week Open GSI had a
meeting
... observation space and coordinate space for geoJSON
... absolutely minimum model to be defined
... we could rely on other standards instead of our own
... we want to know about reliability
... when to get modified, etc.
... for error correction, etc.
... systems should work without interoperability issues
Darko: tx
... we had a bit more detailed discussion than the one during the
main call
... interoperability between different ecosystems
... definition over abstraction layer
Lindsay: if we can relatively easy
import/export
... maybe we could use the same ontology commonly
Darko: right
Lindsay: we could start from iot.schema rather than from scratch
Kaz: we identified that both ETSI ISG
CIM and W3C use layered model
... and refer to external ontologies/schemas for actual
definition
Lindsay: we should keep in touch and continue discussion
Darko: if you need some additional
information, please drop us emails
... thanks very much for the discussion
... talk with you in 2 weeks
Lindsay: wondering about Open GSI work
Darko: we're aware of that work
... esp. Danh Le Phuoc
Koster: SSN workshop in October in California
Lindsay: thank you very much for giving us time!
[adjourned]