23 Jun 2017


See also: IRC log


Kaz_Ashimura, Danh_Le_Phuoc, Darko_Anicic, Dave_Raggett, Maria_Poveda, Michael_Koster, Michael_McCool, Sebastian_Kaebisch, Taki_Kamiya, Uday_Davuluru, Victor_Charpenay, Acille_Zappa, Masato_Ohura, Yongjing_Zhang, achille_zappa, McCool


Status of the current practice document for Düsseldorf

<kaz> scribenick: DanhLePhuoc


sebastian: TD has a slight change in comparision0

<kaz> slides on TD structure for Dusseldorf f2f

sebastian: the plural terms are now changed to single form
... the content is updated in the wot practice document

<kaz> Current Practices document again

sebastian: There are some subsections in the best practice document that mention on the how to annotate semantic data ...

<kaz> table on Thing, Property and Action below EXAMPLE 33

<MariaPoveda> http://uri.etsi.org/m2m/saref# vs https://w3id.org/saref# ?

sebastian: it's important to look into the list of "things" used in previous plugfests to give semantic examples towards these things and their properties

<kaz> Sebastian shows the PlugFest table from Osaka f2f

dsr: we should look into the use cases closely before coming up the semantic annotations

<McCool> regarding what Dave is saying: location information and scope information might be useful

<McCool> to say where the device is... this is useful metadata; does it belong in the TD?

dsr: based on the usecases, describe exactly what do you want to do, then choose the model/vocabulary to describe them

<McCool> but location is a pretty complex topic; best to look first at what else is being done in W3C

<McCool> for geolocation

sebastian: I would prefer to start with very simple example for the non-semantic developers in the plugfest

<McCool> it DOES apply to discovery though: "find things near me". But I could also find thing near me by guessing on physical proximity based on network topology

MariaPoveda: the uris of saref currently used are not the right one
... there is the second version of SAREF, just wanted to get everybody informed

<McCool> another point: location can change. Is the TD static or dynamic?

<McCool> might be better to make it a property...

sebastian: we should look into the future to be able to use other ontologies such as schema.org or iot.schema.org

DarkoAnicic: I'm working collecting terms for iot.schema.ogr

<yongjing> for the sake of interworking with oneM2M, it would be nice to also reference to oneM2M Base Ontology in the 'practice' document: http://www.onem2m.org/ontology/Base_Ontology/oneM2M_Base_Ontology-V_3_2_0.owl

<yongjing> for semantic annotation

DarkoAnicic: I'm trying to have something before the the plugfest...

<MariaPoveda> Sorry, I have lo leave. I'll have a look at the minutes.

<mjkoster> https://mjkoster.github.io/html/protocolbindings.html

<sebastian> ok

kaz: I agree with Sebastian that we should start with simple examples
... and think we should separate the abstract-level discussion on TD and detailed discussion on "how to map existing parameters to TD", because the second part is quite related to "Protocol Binding Template".
... Michael Koster has started initial consideration about Protocol Binding Template, so we should work with Michael as well.
... we should be able to integrate TD with several vocabularies, but the detailed discussion on mapping should be done in the second phase
... phase 1: thinking about the abstract level of TD
... phase 2: thinking about the binding template and how to map existing parameters (from OCF, oneM2M, Echonet, etc.) to TD.
... for the phase 2 above, probably geolocation/Point-of-view kind of information would be needed, because some devices can be moved and even static devices, e.g., air conditioners, can change the direction of the air flow

McCool: location is very important, esp. when the location is dynamic ... semantics of the location property is very for later phase ...
... the location data might be x,y,z coordinates that are important for the things moving around the building

<yongjing> I've created a PR to add the oneM2M Base Ontology ref.

<kaz> fyi, there are specs on Geolocation and Device Orientation

McCool: we don't need to have it ready by plugfest but we should mark it as a discussion item for the F2F discussion

<dsr> a device could be few centimetres away yet in another room!

Protocol Binding Template

<kaz> protocol binding template initial draft

<kaz> scribenick: kaz

mjkoster: gives update on the initial draft of Protocol Binding Template

<kaz> scribenick: DanhLePhuoc

sebastian: it would be great to show protocol binding of OCF in the next plugfest

victor: give me until next week to make the TD repository to online

sebastian: the repository can be searched via semantic API like SPARQL but can be done via full text format ...

<yongjing> i have to drop due to other business. bye

Plans for breakouts

<kaz> f2f agenda topics

victor: I would propose the topic: TD and links

<kaz> scribenick: kaz

sebastian: (updates the agenda topics)

Ongoing AIs

<kaz> scribenick: kaz

<kaz> Issue 9 href in DataSchema

sebastian: (shows p3 of https://www.w3.org/WoT/IG/wiki/images/9/9a/TD_version4Duesseldorf.pdf)

<kaz> Issue 3 Namespaces used in TD/WoT ontology

kaz: regarding the namespace discussion, we should refer to the decision we'll use https://www.w3.org/ns/td asn the experimental namespace for PlugFests until the final one is fixed (https://www.w3.org/2017/06/21-wot-minutes.html#ResolutionSummary

<kaz> Issue 5 Adding Semantic Annotations to JSON Schema

mjkoster: can create a pullrequest for the current practices document


Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/06/23 08:02:02 $