<inserted> scribenick: acimmino

Agenda and guests

Kaz set the agenda link in the chat

Christiano Aguzzi is invited as a guest for OAuth2 discussion

meeting starts, looking at the agenda

Review of PR is first issue

then, a propose resolution about pagination

then, a discussion about first draft will take place

also, added to the agenda Fujitsu directory implementation discussion and UPM UC

Previous minutes

May-4 minutes

McCool explains how the minutes of the meeting work

correction of attendees names for meeting of 04th of may, "Cristiano_Cimmino" should be "Andrea_Cimmino"

identification of other typos in point 5 of the index, same meeting minutes

another typo "addition use-case" should be "additional use-case"

no comments on last meeting minutes

therefore, they are approved to be published

<kaz> [typos are just fixed]

Use cases

Meeting keeps with discussion of ongoing UC

first, the Fujitsu UC

a link to prior work has been added

a new subdirectory as been added with UC information

included a diagram for the UC of Fujistsu

the UC will be merged

<kaz> PR 19

no objections about merging the Fujitsu UC, therefore, approved for merging

now UC of UPM

problem with pull due to the account of requester

<kaz> PR 20

markdown format problem due to template

adding note to discovery UC template so in future UC will rely on the template updated n the wot-arquitecture

UC must follow the template specified in the wot-architecture git repo

commiting UPM use case

Andrea explains the UC

<inserted> scribenick: kaz

Andrea: the idea is having distributed network
... offering data for different domains
... in this case, you want to solve discovery task
... relying on SPARQL query
... you'll have a lot of meta nodes
... there would be some trouble

McCool: delegate queries to other SPARQL end points?

Andrea: yes
... only to one-hop middle node
... just the one with direct connection

McCool: sounds reasonable
... capturing the requirements is important
... we can merge this PR 20 itself

<acimmino> trying to merge UC, despite technical problems

McCool: and then create another PR for architecture

<inserted> scribenick: acimmino

andrea needs to merge his account with the W3C

McCool suggest how to solve it in the comment of the pull request

andrea must change a word and re-commit

Follow, meeting proceed checking the Fujitsu UC

Suzuki explains the UC

human discovers directories, which contain the TD of smart appliances

some requirements are derived from the UC, they are specified in a subsection of the UC file

some implementation clarifications are specified in a subsection of the UC file

<kaz> Fujitsu's discovery implementation

Diagram with discovery performed in this UC is explained

McCool: comments about the UC, the protocols used DHCP, and the diagram for registration

McCool asks about Thing discovery diagram

McCool: seems unclear how the mDNS is performed

McCool suggest some changes

McCool: it would be really useful to have specification for REST API (diagram consume phase)
... suggest to use standardised URL for describing entities in REST API
... likely not all devices will be able to implement it
... question about query support, do this UC actually has it?

Suzuki: in this example query language was the one supported by MongoDB

McCool: how keyword search can be done?

Suzuki: maybe query search is not supported

McCool: ...in general, here we have three things WoT name space, Device, and Directory
... ...which is a reasonable structure
... ...next time deeper discussion about UC to catch requirements

skip the propose resolution about pagination

jump into the requirement document due to time left is not much

Requirements document

need to capture requirements from design phase

<kaz> Requirements (so far)

McCool suggest to have a design document, from which capture design decision and link them back to resolution

approved the creation of design document in the git repo

document has two subsections within Design section: Two-Phase Architecture and Standardized Directory Service

McCool provides description for Two-Phase Architecture

authentication plays an important role during the discovery

McCool adds this to the Two-Phase Architecture description

no objections to include Resolution link in the notes

<McCool> proposal: The discovery process should have two main phases: an introduction phase and an exploration phase. The introduction phase can use existing discovery mechanisms and its main output should be a pointer to an exploration service, but it should not provide detailed metadata for actual devices. Instead, the exploration service should provide detailed per-device metadata after authentication.

no objections in making this resolution

RESOLUTION: The discovery process should have two main phases: an introduction phase and an exploration phase. The introduction phase can use existing discovery mechanisms and its main output should be a pointer to an exploration service, but it should not provide detailed metadata for actual devices. Instead, the exploration service should provide detailed per-device metadata after authentication.

in future meetings something similar will be done for specifying the Standardised Directory Service

<kaz> newly created (preliminary) design note

no objections in merging the design file

no more issues for this meeting

meeting is end

<kaz> [adjourned]