<kaz> scribenick: andrea_cimmino

Guests

christian from MongoDB is present

meeting starts with christian presenting himself

<kaz> (Christian has read the W3C Patent Policy and understands the RF commitment)

Previous minutes

McCool: minutes from last meeting are reviewed

<inserted> August-3

McCool: PR for anonymous TD was created, as stated in the minutes
... remind McCool to create issue for the spec issues/43
... remind McCool during MongoDB discussion to create an idempotent issue
... minutes proposed for publication with no further comments

minutes reviewed and publish, changing topic now to MongoDB

MongoDB

McCool: Does MongoDB supports JSON-LD? and XPath?

Christian: it supports Json-LD
... regarding XPath, MongoDB supports a similar query language

McCool: it would be good to have the spec of such language
... the place to collaborate is to have a second implementation based on MongoDB

Farshid: current implementation is not based on MongoDB
... instead the implementation uses LevelDB

Christian: how does LevelDB is used?

Farshid: the key is the ID and the value the TD

McCool: the TDD have an API to register, and then someone can filter the TD. TDs have an id field, which is optional, therefore sometimes the ids must have a created on the fly id
... there could be other meta-data, also not included. Therefore we rely on a wrapper object to support such information
... ids can be updated, they are not immutable
... the general idea is that authorized devices can receive notifications, so basically, when the TD changes de id it has to be deleted first, re-created, and then notify those devices
... when created on the fly, maybe, ids should not be changed if TD is updated
... bottom line, the draft needs to include how to deal with this stuff
... implementation time should be until January 2022
... candidate recommendation July 2021 (CR)
... final for December 2021
... ideally, July 2021 we should have two implementations that satisfy the requirements

<kaz> (Implementation report plan by CR transition; Implementation Report with concrete results by PR transition)

McCool: implementations do not need to be Open Source, but they must pass the tests

farshid: our implementation is based on the requirements of a project, from which we got involved in this initiative
... there are things outside the specifications, like how the data is stored, and instead, the specification details the APIs
... in this way someone can implement internally the spec with the desired technologies, but still implement the same spec

McCool describes how the current draft is structured

McCool: the draft does not specifies the internal functioning
... one of the issues are the type of search supported: XPath, Json Path, and SPARQL
... we will need a SPARQL-based implementation if SPARQL is included
... Xpath and Json path are still under discussion

<kaz> (Kaz's note: basic expectation is all the features including optional features should have more than one implementation; but there should be multiple implementations given SPARQL is also a W3C Recommendation.)

McCool: clarification, the project of Farshid was originally LinkSmart, from which other projects were derived and this component enhanced
... having an open SPARQL can be dangerous, therefore, it will be used for advanced implementation
... the baseline is Json Path and XPath
... in general, regarding the architecture, privacy is a concern
... since distributing data can be used to infer information and also track people
... in the discovery there will be two steps: introducing first (only informative), and then the exploration mechanisms
... even if christian does not implement a version, your contribution and experience will be very valuable
... for instance, in the idempotent issue

Christian: the problem here is how to identify anonymous TD
... a hash could be calculated, but the order of the keys is important
... the full td should be used for the hash, so two TD are identical only if their whole content is the same

McCool: here the thing is that the same device could create different TDs that are the same, exactly the same content

Farshid: some UC may include this beahviour
... for these cases maybe a short life span may help
... two devices are identical, and publishing the same TD, and only their payloads are different
... these, once registered, get a unique ID. But this ID is unknown during registration. Everything should work fine

McCool: maybe we should register a special TD, get the ID, and then register the right TD with the ID
... let's further discuss this
... let's create an issue and discuss (assigned to farshid)

<FarshidT> Issue to discuss how to handle anonymous TD and avoid duplicates: https://github.com/w3c/wot-discovery/issues/48

PR 38

<kaz> PR 38

discussion about last befrancis issue, farshid already replied

Farshid: the comments are outside the scope of directory
... like, having a TDD that automatically creates TDs from adapters

McCool: maybe we could approach this creating micro-services that perform different tasks
... nevertheless, McCool agrees with Farshid

McCool replies in the PR

McCool proposes merging the PR, since no objections are done, PR is merged

PR 47

scribenick: kaz

<kaz> PR 47

<kaz> diff

<kaz> changes

McCool: (captures several issues as comments)

McCool's comments

<Zakim> kaz, you wanted to suggest we use <h2> with <section> for ReSpec. Please see also: https://github.com/w3c/respec/wiki/section

<kaz> (<h5> surrounded by <section> and </section> is OK, though)

[adjourned]