# WISHI online meeting

June 4th (Thursday), 6:00-8:00 PDT (15:00-17:00 CEST, 13:00-15:00 UTC)

Participants:

1. Michael Koster (MK)
2. Jonathan Beri (JB)
3. Ari Keränen (AK)
4. Carsten Bormann (CB)
5. Michael McCool (MM)
6. Milan M
7. Klaus Hartke
8.

Draft agenda:

* Identifiers, References, Paths, and Pointers (CB)

## Agenda bash
(no comments)

## Identifiers, References, Paths, and Pointers (CB)

CB: topic that comes up in many places. We should have a strategy. Three hard problems in CS: cache invalidation, naming, and off-by-one. Now talking about naming. Have more questions than answers

MM: WoT working on Decentralized IDs. Have presentation somewhere; will dig up.

CB: naming we use today is largely based in URIs/URLs. Five parts: scheme (what kind), authority (one place that defines the URLs), path, query, fragment. Basic idea: you invoke/dereference by talking to authority, using schema, and supply path and query parts. And then you get something back that can be further analyzed using fragment ID (local pointer).
We often generate URIs from URI references: context information. Allows for shorter refs. Easier to type, but also good to be able to infer part from context. Can make references between documents assuming there is context provided.
Two uses: easier to use but also indirection.
Since URI references are context-dependent, also makes the document context dependent. Sometimes a bug, sometimes feature.
Also URNs: not meant to be (always) dereferenced. Just unique naming scheme; no other implications -- except the scheme URN has implication you can parse that. Can infer semantics by parsing that.
What happens when you take deferencing part from URLs and just use as names? Fragment IDs lose their original meaning -- interpreted in the media type representation. In RDF had to to makes tricks to accommodate for this.
Some baggage we get but useful infra too when we use URIs.
Also IRIs for i18n; today modern URLs are actually IRIs.
XML has namespaces. QName: URI+local name. Problem with namespace prefixes: they leak out. The problem can't be contained to XML parsers but application needs the information for e.g., attribute values that are QNames.
One of the things that helped kill XML. Complexity of namespaces is so high and so many mistakes being made. Make things really hard to do.
RDF used XML namespaces as the inspiration for prefixes. Typical node in RDF identified by URL and fragment ID that points to a specific name in that URL. There concatenate the namespace name and local part. If want to go back to CURIE style, need to guess where is the boundary. Often to the right from fragment ID, but not always.
CURIEs essentially same thing, take outside of RDF. But not Qnames. But XML vocabulary can use QNames for CURIEs. Leads to weird specs. CURIEs use the colon, so can't be mixed with absolute URLs.

CB: also need a way to reference set of resources that only differ by parameters: URI templates. Usually in web mediated by forms; alternative to URI templates.
RFC6750 is arcane syntax. Important thing: components byh URI may be provided by server, just form of compression. Not very different from CURIEs. Just URI you can store without storing all of it. Need template only once. One variables from client, things get "intresting" (messy).

CB: pointers and paths; fragment IDs for strutured data and also path/query part for URIs. Representatin format specific; JSON Pointer and XPath for example.
Pointers are expressive enough to find something in an instance ("go to book page 62 middle part"). Path meant for adding some generality; many instances of class.

MM: good example of use of JSON Path for TD queries as well in LinkSmart

CB: no hard boundary between these. Strong traction towards Turing equivalence (e.g., XPath). We don't want to run XPath on constrained server.
In JSON ecosystem have JSON pointer (RFC6901). Syntax for navigating a JSON doc (but can't say "give second half of string"). Also syntax for fragment ID component. Many examples in OneDM.
JSON Path simplified XPath and used subset. Escape expressions for scripting language. But tying to specific scripting environment. Something we could decide is good idea to standardize. (see https://goessner.net/articles/JsonPath/)

CB: How about Thing web. We can use for modeling big web techs. But opportunity to define something without text-based baggage, e.g., provide separation between URL and URN uses. What other things should be fixed here? Still need white-board form to talk about these things.

MM: +1 for looking at standardizing JSON path. Struggling with that in WoT discovery.

### JSON path and WoT TDs

https://raw.githubusercontent.com/wiki/linksmart/thing-directory/presentations/thing-directory-wot-call-2020-4-15.pdf

MM: Fraunhofer had project using TDs. Have database for TDs, URI templates for creting, querying. Conceptually database is big JSON file. Search to discover multiple TDs. Can also return fragments/parts of TDs. Could search TDs with certain title and return just titles. Uses JSON path expression. Basically key-word based search. JSON path assumes template and key-word based approachs. Does not subsume SPAQRL like searches.
Struggling how does this relate to JSON-LD. Understands contexts, etc? Fragments have still context?
Relatively small number of operations needed, like date-string comparison for getting TDs for certain time.
One candiate for directory design for WoT plugfest. Problem that JSON path is not standard. XPath is and recently updated to support JSON.

CB: looked at JSON component of Xpath. Looks like
someone filled just a checkmark of what's missing.

Michael Koster15:51
I would like to point out the difference between returning a pointer with a fragment identifier vs. returning part of a document
Michael Koster15:52
Fragments are typically processed on the client
Michael Koster15:53
ointing to a node in a document isn't enough information to inform how to construct a representation for part of a document
Michael Koster15:53
(pointing to...)

MM: TDs are JSON-LD so need to figure out LD part. But use JSON so prefer JSON path. Don't want arbitrary scripting support but things like numeric comparison and regex. But how complicated expressions are OK?

CB: standardization will get stuck when you need to decide which flavor of regex to use.

MM: certain functionality needed for searches.

KH: JSon path / -LD: if doc is using JSON-LD, title is like [...]with #title. How too put to URI?

MM: need concept of context added. "@" implies context of document.

KH: in CoRAL had similar discussion. Use URIs for IDs in vocabulary. Wanted filter list of CoRAL elements. Would need full URI in Query strings. But becomes too big with constrained devices. Better to use CoAP FETCH method. In payload can provide context. In query string could have limited set known. If have different namespace have to use POST/FETCH.

MM: 3 different levels of directories. 1) self identifying 2) intermediate level with keyword and template queries, GW level devices, large computer with GBs of memory 3) full SPARQL queries.

KH: can use JSON path for JSON-LD? Or need to extend JSON path?

MM: for title can insert URLs, maybe use quotes. Expansion should be feasible. Might be uggly. Haven't thought deeply. Will be playing with at plugfest.
If JSON path would be standardized in a year, would fit WoT timeline for standardization. Need to make decision soon.

CB: havent talked how does RDF pointer look like?

MM: also GraphQL on the list of things to look at.

CB: also (MJK said) pointing a node is not enough to make reference

MK: TD content format requires fields not in document. Maybe just requirement issue for content format. You get pointer to node in doc but client decides how to look at doc. Having server send part of doc in response to query -- if have reference variable, response currently undefined in web protocols (?).

CB: problem when take things out of context, semantics not clear anymore. For SDF spec we have alternating levels [...] need to know which you have.

MM: in JSON-LD have framing...

### DIDs
https://github.com/w3c/wot-discovery/blob/master/presentations/2020-02-WoT-DID.pdf

MM: looked at WoT for looking for IDs for TDs. Can also be resolved to TDs. Basic idea: URN scheme and method. After method ID, method specific string. DIDs are fixed, can be put to QR codes etc. Also resolution mechanism to look for DID docs that are JSON-LD docs. List of typed links; can point to service endpoints of certain types. Also proof section with signing.
[...]
Relevant to IoT: accessing service endpoints. Interesting to use to find and discover things. Resolve too URL to access device. DID doc can be updated e.g., if devices moves. Can keep the same ID. Level of indirection.
Can use frag IDs to refer to specific service endpoints.

CB: got scared of infra needs to make this happen. Lookoup services, security stuff etc.

MM: there are like 40 implementations. DNS and blockchain back-ends the main ones. Can also use directory server.

CB: interesting to extract various points of indirection and understand the architecture behind.

MM: spec does not specify resolution mechanisms. Still active WG (not standard yet).
Will talk at Monday WS more about discovery. DID might be considered one possible way to find WoT directory service.

CB: any docs describing DID methods? (see presentation references)

CB: lot of this thinking will need some digesting. Would like to pick up standardization of JSON path. W3C or IETF?

MM: similar issue with JSON schema. Would prefer to have both in same place. IETF fine. W3C could do it. Would like to rationalize XPath and JSON path to have a mapping (not necessarily bi-directional). IETF spec makes most sence; take current spec and bring over. Need to resolve things like arbitrary scripts. And JSON-LD issue

CB: IETF can't help with JSON-LD

MM: could start with pure JSON. And then think of extensions for -LD. Could assume everything is expanded, at least conceptually. Blog post "the holder" of JSON path. LinkSmart guys have implementation.

AK: something we can bring to OneDM / CoRAL discussions from here?

CB: people need to invent something up to harvest that fruit

Milan: will post preso?

CB: already in wishi slides repo
https://github.com/t2trg/wishi/blob/master/slides/2020-06-04-references-names-pointers-paths.pdf

## Meeting planning

### Helsinki meeting

https://github.com/t2trg/2020-06-helsinki

AK: welcome to join; please register (even if not strictly needed)

MMC: goes through Monday agenda
Use cases, Lifecycle, Discovery
EdgeX retail PoC; Smart City PoC

Hypermedia Controls (vs. RESTful design); what happens when an Action returns links for following up (e.g., canceling)
Also, discussion of URL templates
Using OneDM semantics in TDs

### Meeting planning

AK: OpenAPI discussion
MMC: call for papers for OpenAPI-sponsored conference

Likely Future Agenda items:

* Data definition (JSON Schema, DTDL)
* DTDL in general
* Further OneDM oriented
* Implementation oriented ("Hackathon")
* OpenAPI/AsyncAPI and CoRE/WoT techs
* JSON Path standardization

MM: also conference https://sessionize.com/api-specifications-conference-2020/

MM: the conference open discussion beyond OpenAPI. Hope for MSFT to contribute on DTDL. Online conference; 9th and 10th of September. CFP closes in June.

JB (Chat): I'd be interested in contributing to a proposal. You can see last year's ASC agenda: https://events19.linuxfoundation.org/events/asc-2019/program/schedule/

MM: great to get someone from MSFT to present DTDL. Also useful to have a look at other DT specs, how they overlap and how are useful. IIC had testbed for water management for smart cities. Idea to minimize the number of sensors by estimating flow. Can predict leaks in parts of network without sensors. Combination of simulation very powerful.
Issue on DTs good to have. How relates to IoT and role of standards, including DTDL. Overlap with API spec languages. Same category as WoT TDs and OpenAPI specs. Also to understand licensing, IPR arrangements, etc.

AK: very interesting to have DTDL discussion. Could combine forces to make that happen. Some open fora.

MM: DTDL is JSON-LD so things like OneDM would apply. Even if have separate specs, we use same semantics which is interesting.
Could base talk on people here today or spend time inviting. MSFT talk one option or JSON path/schema option. Hard to predict when available. Good to spend time inviting before setting session time.

AK: could be hackathon session; like OneDM hackathon

MM: also WoT hackathon coming; can invite. See workshop page. Call-in information available by request.

MK: looking at Node WoT extensions

MM: due to time zones have full week event, one hour daily to synch. Week of 15-19th.

MK: OneDM semantic proxy good to include there

MM: JSON path standardization; can invite the folks to discuss IETF standardization.

CB: good to have predictable rhytm for WISHI calls. Every 4 weeks or so. Could ask folks when they have time. For JSON path, will mention the need to standardize to people who are looking at OneDM proposal. Can trigger this this week. Will have to line up support and having original author might help a lot :)

...

Milan: having map of areas of semantic data definitions. Scope of what trying. Digital Twin, DT, OneDM. Quite many don't articulate what they are defining before going to minutiae. Number of people ask me who should I follow. Some map of where efforts are useful. Some basic assumptions that the techs do. Spec / development time technology. Rest of group interested?

AK: yes

MK: also work flows, venues, how fit together. Also who is using for what now and how fit. Could be addressed with blog posts.

Milan: we all have image but not sure if it's same image. Good to have common understanding.
Can take assignment to make a provocative statement and we can discuss.

CB: great outcome of the RG to collect material like this

Milan: will do informal draft and share with group. Just get basic idea articulated. Takes a week or two.

MK: will contribute with my spread-sheet with 13 techs

AK: how about June 30th for next WISHI call

Milan/CB: OK

MM: OK; WoT people busy with f2f until 26th, but week after OK.

AK: late time as suggested?

MM: sounds OK. Should evaluate and alternate on demand.

AK: also AsyncAPI/OpenAPI topic for next call?

JB: a few people have reached out; could have a look offline.

MM: great we have different formats but if can converge on patterns and idioms, will get us far

JB: proposal on how to look at different formats, set of lang/spec neutral aspects to identify. Understanding methods like observe/fetch/ipatch that are not considered by other specs.

AK: (wrapping up); good topics for the next WISHI call on 30th. See you all on Monday in the WoT joint meeting and on 30th in the next WISHI call.