- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 07 Sep 2020 17:58:26 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/08/12-wot-td-minutes.html
also as text below.
Thanks a lot for takin the minutes, Taki!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT-WG - TD-TF
12 Aug 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#August_12.2C_2020
Attendees
Present
Kaz_Ashimura, Cristiano_Aguzzi, Sebastian_Kaebisch,
Taki_Kamiya, Daniel_Peintner, Michael_McCool,
Tomoaki_Mizushima, Michael_Koster
Regrets
Chair
Sebastian
Scribe
TK
Contents
* [3]Topics
1. [4]Meeting schedule
2. [5]Issue #941
3. [6]PR #896.
4. [7]PR #938 about TDT
5. [8]PR #943.
6. [9]PR #945
7. [10]PR #944
8. [11]Issue #930
9. [12]PR #927 on OAuth2
10. [13]Meeting plan
* [14]Summary of Action Items
* [15]Summary of Resolutions
__________________________________________________________
<taki> scribeNick: taki
Meeting schedule
Sebastian: Next week, there is no TD call. on August 19, there
might be one.
... Sept 3rd, we are going to have one.
Issue #941
<inserted> [16]Issue 941
[16] https://github.com/w3c/wot-thing-description/issues/941
Sebastian: There are terms in Profile that not covered by TD
models.
... we have to clarify use case, and which terms need to be in
TD.
... not sure about serial number and revisions.
McCool: there is a geo-location use case.
... we should adopt existing standards.
McCool mentions a couple of standards...
McCool: accuracy etc. are discussed in use case.
... Consistency with Web API is important.
... wrt. installation location and data of returned value.
... note datatype issue string vs. number.
McCool points us to use case URL...
<McCool__>
[17]https://github.com/w3c/wot-usecases/blob/master/USE-CASES/s
martcity-geolocation.md
[17] https://github.com/w3c/wot-usecases/blob/master/USE-CASES/smartcity-geolocation.md
McCool: "smartcity-geolocation.md" is the file name.
McCool browses the use case.
McCool: there are standards mentioned.
... Basic Geo Vocabulary, WGS84, etc.
... This document needs to be updated with regards to
GeolocationSensor interface based on the Generic Sensor API.
McCool explains Geo-location API...
Sebastian: how about height and depth?
McCool: it is synonym with altitude.
... altitude is relative to sea level, which may be complicate.
Sebastian: Does it depend on stadards?
... ISO standard.
McCool: sparql also should be added to geo-location use case.
<kaz> [18]Geolocation Sensor API based on Generic Sensor
approach
[18] https://w3c.github.io/geolocation-sensor/#geolocationsensor-interface
McCool: any ontology we adopt needs to be consistent with
geo-location API.
Kaz: As I mentioned the other day, this is a good topic to
discuss with Devices and Sensors WG and Spatial Data on the Web
IG.
McCool: should we specify ontology or reference external one?
Sebastian: We can make a container at the top level.
McCool: we probably should not allow partial geolocation
Cristiano: geo-location is important to agriculture.
... altitude is from sea-level. Depth is from terrain.
McCool: height is useful, then. In addition to altitude.
... We can say "dig down 6 feet".
Cristiano: Local values are useful in reality.
McCool: In addition, we need o define units.
Sebastian added a comment in issue #941 to summarize the
discussion.
McCool: geo-location API is not in RDF form yet.
... Singapore people use the geo-location API.
Sebastian: serialNumber is in schema.org.
McCool: We should split issue #941 into two.
... serialNumber depends on manufacturer.
... The issue has privacy implication.
... we can make it optional. People may want to put into
database, however.
... "link" field. We can have "ref" and "url" type for that.
... Manufacturer also needs to be defined.
... Note there can also be "tracking number".
<kaz> [19]new issue 946 on serialNumber
[19] https://github.com/w3c/wot-thing-description/issues/946
Sebastian: HW/SW revision numbers. We already have VersionInfo.
McCool: version of TD vs HW/SW.
... We can put them in VersionInfo.
... We should create an issue for this.
... We need to be careful about fingerprinting based on HW/SW
versions.
<kaz> [20]TD spec - 5.3.1.6 VersionInfo
[20] https://www.w3.org/TR/2020/REC-wot-thing-description-20200409/#versioninfo
Sebastian: also related to security?
McCool: Yes. If you know version, you can exploit that.
... and there is a tracking risk.
... You can filter out information when TD goes out of
directory.
... and they should be optional.
<kaz> [21]new issue 947 on hardwareRevision and
softwareRevision
[21] https://github.com/w3c/wot-thing-description/issues/947
Sebastian summarizes #941 discussion...
<mjk__> [22]https://schema.org/GeoCoordinates
[22] https://schema.org/GeoCoordinates
Koster: How does it look like when you talk about container?
Sebastian: It is JSON container like securityDefinition.
Koster: It is a component of TD, as a stanza.
<kaz> [23]TD spec - 6.3.3 version
[23] https://www.w3.org/TR/2020/REC-wot-thing-description-20200409/#version-serialization-json
Koster: About the thing, not about TD such as manufacturer.
McCool: we can make geo-location optional by using container.
Koster: Location, manufacturer, etc. In Zigbee, there is
cluster. TD is missing those component-oriented mechanism.
... I am concerned about bloating TD too much.
<kaz> [24]geolocation information on schema.org
[24] https://schema.org/docs/search_results.html?q=geolocation
McCool: There are two use cases. Installation location and data
annotation. I mentioned earlier.
... I agree with component issue.
Koster: We can plugin at data model level.
... Where should we discuss this issue?
Sebastian: We are not inventing new geo-location.
... Where is the source that we can evaluate and use? We should
not introduce something others are doing in other ways.
... Has it been discussed in One Data Model?
Koster: Yes. OCF, OMA, etc. We have been in the process of
converging them.
McCool: RDF mapping may be a good start, given that there are
several well defined standards.
Sebastian: Do you have a reference to One Data Model
discussion?
<McCool__> McCool: specifically, the WGS standard and the ISO
standard based on it; although we may have to add things like
"height"
Koster: I agree that a good RDF base reference is needed if we
can provide it for others to use also and coordinate it with
the other groups
<mjk__> [25]https://schema.org/GeoCoordinates
[25] https://schema.org/GeoCoordinates
Kaz: Schema.org may be a good place to start with.
McCool: I will update the use case.
Koster: there needs to be a basic RDF ontology that One data
model can make a reference to for geo-location, temperature,
etc.
<inserted> scribenick: kaz
mjk: if some data type is super interesting like geolocation
data, it should be useful to the others as well
mm: right. not only for us
<inserted> scribenick: taki
Koster: we can define a profile, where we can define these for
interoperability.
McCool: We can define preferred extension there.
Koster: We need extension point defined.
Sebastian shows GeoLocation in schema.org, and check "geo"
container.
<kaz> [26]GeoCoordinates page (click "JSON-LD" tab within
Example 2)
[26] https://schema.org/GeoCoordinates
Cristiano: We can define extension for geo-location on top of
core.
... I saw that pattern in NGSI-LD.
McCool noted a comment from Ben.
<Zakim> kaz, you wanted to time check
McCool: Ben thinks it should not be in core.
PR #896.
<kaz> [27]PR 896
[27] https://github.com/w3c/wot-thing-description/pull/896
Sebastian: contentMediaType and contentEncoding were added.
... Cristiano, please check.
Cristiano: I will.
PR #938 about TDT
<inserted> [28]PR 938
[28] https://github.com/w3c/wot-thing-description/pull/938
Sebastian: I started to formalize TDT in #938.
... In definition section, I introduce TDT to reflect
discussion in architecture meeting.
... I added some examples to show TDT does not have some
fields.
... I also introduced placeholder concept.
... with an example.
McCool: "may not include" means "must not". We can clean up
normative statements.
... OAuth does not necessarily define URL. We want to say "may
not contain".
... we can simply say "may contain" in positive form.
Sebastian: OK.
... I will add McCool as a reviewer.
... Rendering tool still does not work correctly. Victor and
Daniel are working on this.
<mjk__> [29]https://tools.ietf.org/html/rfc2119
[29] https://tools.ietf.org/html/rfc2119
McCool: I will review.
Sebastian: Please everyone review #938.
PR #943.
McCool: we may need to wait till TD 2.0.
... Should we use extension point, or include in core TD?
... Hash function of content of TD, to avoid attacks.
... getting into version 1.1 would be great.
... I could not find in respec.
... for an entry for LD-proof.
... version 1,0 TD, people need to explicitly define extension
vocab for this.
... set vs array. Serialization needs to preserve order for
this to work.
... Set can be serialized into array.
... We should clearly separate set vs. array.
... This is still in WIP.
... For 1.1 FPWD, we may not ready to include this.
... We are going to discuss in Security TF first.
Sebastian: Let's discuss in September again.
PR #945
<inserted> [30]PR 945
[30] https://github.com/w3c/wot-thing-description/pull/945
McCool: Right now security is array of strings.
... We need compact form simple use case.
... we can allow inline security definition.
... Ege and Ben think this is good idea.
... Parsing may become a bit more complex.
Sebastian: Security definition becomes optional.
McCool: We can have one line with nosec.
... It does not have to be FPWD.
PR #944
<inserted> [31]PR 944
[31] https://github.com/w3c/wot-thing-description/pull/944
McCool: "and" in WoT, "or" in OpenAPI when multiple security
schemes.
... "and" is consistent with our purpose.
... We need "or" method.
... we can use "oneOf".
... I have not created ontology yet.
... We are going to review in Security TF first.
Sebastian: no impact on ontology.
McCool: It does.
... rendering script may need to be updated.
... type field is a string or security scheme, or array of
security schema.
... I do not know how to do that in ontology.
... and the script needs to interpret this.
Issue #930
<kaz> [32]Issue 930
[32] https://github.com/w3c/wot-thing-description/issues/930
McCool: In Digital Twin, "model" is used. "template" sounds
hacky.
... TDTD for directory of TDT?
Sebastian: Thing Model Description.
McCool: We can drop "description" for model.
<inserted> Kaz: yeah, and that ("Thing Model") implies it's an
abstract version of "Thing Description"
Sebastian: We use "Thing Description Template" in version 1.0.
Kaz: We can add a note saying we used to call it "Thing
Description Template" in TD ver. 1 and have renamed it to
"Thing Model".
Sebastian summarized discussion in issue #930.
Koster: "Model" makes sense.
McCool: Lagally saw other use cases for "template", and
proposed to change "model".
Koster: Thing fragments, etc. there are lots of templates.
... Model can define constraints description at model level.
<McCool__> mccool: probably each use case should be given a
distinct name: Thing Query Fragment, Partial Thing Description,
etc.; for future work, avoid reusing TDT to avoid confusion
Sebastian: In version 1.1, we are going to use this name. TDT
(i.e. model) is more important in 1.1. Any objectons?
McCool: Lagally would agree to this.
<sebastian> proposal: we will rename "Thing Description
Template" to "Thing Model" for the TD 1.1
RESOLUTION: we will rename "Thing Description Template" to
"Thing Model" for the TD 1.1
PR #927 on OAuth2
<inserted> [33]PR 927
[33] https://github.com/w3c/wot-thing-description/pull/927
McCool: PR #927.
... we have reviewed in Security TF.
... I propose to go ahead to merge.
... We can fix cosmetic problems later.
... password flow should use extension.
... there is an editor's note.
... I will create another issue addressing remaining small
issues after merging this PR.
Sebastian: It has been reviwed in security TF.
Sebastian merged #927.
Sebastian created issue #948.
<kaz> [34]Issue 948
[34] https://github.com/w3c/wot-thing-description/issues/948
Sebastian created issue #949 for vocabularies for implicit and
password flows.
<kaz> [35]Issue 949
[35] https://github.com/w3c/wot-thing-description/issues/949
Sebastian: We are done with today's agenda.
... something else?
Meeting plan
Sebastian: TK will decide about a meeting in 2 weeks.
... I will be back in September.
<kaz> [adjourned]
Summary of Action Items
Summary of Resolutions
1. [36]we will rename "Thing Description Template" to "Thing
Model" for the TD 1.1
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [37]scribe.perl version ([38]CVS log)
$Date: 2020/08/17 08:07:36 $
[37] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[38] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 7 September 2020 08:58:31 UTC