<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> Issue 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__> 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> Geolocation Sensor API based on Generic Sensor approach

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> new issue 946 on serialNumber

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> TD spec - 5.3.1.6 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> new issue 947 on hardwareRevision and softwareRevision

Sebastian summarizes #941 discussion...

<mjk__> 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> TD spec - 6.3.3 version

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> geolocation information on schema.org

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__> 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> GeoCoordinates page (click "JSON-LD" tab within Example 2)

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> PR 896

Sebastian: contentMediaType and contentEncoding were added.
... Cristiano, please check.

Cristiano: I will.

PR #938 about TDT

<inserted> PR 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__> 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> PR 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> PR 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> Issue 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> PR 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> Issue 948

Sebastian created issue #949 for vocabularies for implicit and password flows.

<kaz> Issue 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]