WoT Discovery

Minutes review

vF2F Day 1

Oct-18

McCool: would like to review the minutes and see the actions

Fragment identifiers

McCool: (goes through the vF2F Day 1 minutes)
… use of fragment identifiers in IDs to resolve "is ID that of TD or of Thing?"

Kaz: right
… we discussed that during the joint meeting with DID on Oct 28 as well

McCool: right
… need to search for the related GitHub issues

McCool's comment on ID of TD vs Thing for wot-discovery issue 190

McCool: fragment identifiers do NOT address the question of objects which are different versions of a "living" object, nor of expressing the relationships between different versions and the living object.

McCool: (goes through the wot-discovery issue 190)
… the discussion started with @type
… but related to @id
… (adds the URL of the issue 190 to the Discovery call wiki agenda)

Discovery call wiki

McCool: think we can't apply this change to the TD 1.1 spec due to the potential uncompatibility
… (adds comments to the wot-discovery issue 190)
… unfortunately, I think we want a compatible solution so it can go into the TD 1.1 spec
… during the F2F (on Oct28, during the T2TRG/DID session) the idea of using "fragment identifiers" on IDs came up
… I need to think more/research more about this, but this is an outline of my thoughts:
… 1. Extend IDs with a fragment identifier (or maybe a query parameter) providing a "view" identifier.
… This would distinuish different TDs that refer to the same Things.
… In this case, dropping the extension gives the IDs of the Thing.
… With the extension, it's the ID of the TD.
… 2. For backward compatibility, an ID without an extension would be considered to be the "primary" TD and in a 1:1 relationship with a Thing.
… A thing should only have ONE "primary" TD.
… 3. Any "derived" TD, e.g., for a proxoy, or for changing the default language, etc., should add an extension to the ID.
… 4. Note this means we can easily add different "views" (different TDs for the same Thing) to a TDD since the IDs will be distinct.
… 5. We still have the problem of creating unique extensions. Perhaps extensions could *ALSO* be UUIDs.
… (adds some examples)

Kaz: yeah
… that's fine as the initial starting point
… but we need to think about how to generate the UUID
… and how to manage that as well

McCool: yeah
… the question is how to guarantee the uniqueness

Kaz: right

McCool: anyway, we've capture the problems on this issue

JSONPath and XPath

McCool: another point for today is Issue 156

Issue 156 - JSONPath and XPath response data models

McCool: Toumura-san might want to describe his use case on this issue

<McCool> https://github.com/w3c/wot-discovery/issues/156

McCool: will add a comment to the issue 156, and let's continue the discussion

[adjourned]