JSON-LD

<kaz> Agenda for JSON-LD joint meeting

<kaz> preesnt+ Harold_Solbrig

<kaz> scribenick: McCool

Agenda

seb: two major topics, related to TD and related to Discovery
... will start with TD
... going to go straight into issues and assume attendees know what WoT is
... but would like to know the current status of JSON-LD maintenance situation

JSON-LD WG status

beny: maintenance mode is lightweight working group
... to keep an eye on JSON-LD iterate them if there are emerging needs or minor issues
... but not currently pushing for a major update at this point
... but group is willing to consider new work items, but nothing pressing at the moment
... we just published the 1.1 document, now the rest period after that

ivan: there isn't another working group; JSON-LD CG does exist
... but don't currently have formal meetings, etc.
... but incubation can happen in CG
... and if the CG comes with new proposals, then formal work would happen in WG
... by having the WG, we can keep the IPR framework in place

(yvon -> Ivan Herman)

seb: thank you for the clarification
... few words on our status; we have released our first docs, specifically TD 1.0
... now working on next version, and various other new work items

<inserted> WoT Thing Description Recommendation

seb: let's start with TD

mm: sure, but please reserve at least 20m for discovery

<victor> https://github.com/w3c/wot-thing-description/issues/988

<victor> https://github.com/w3c/wot-thing-description/issues/967

victor: I see two new issues that did not get labelled with the JSON-LD label

seb: are these urgent?

victor: well, I think we should ask the JSON-LD editors for advice

seb: issue 932, versioning
... would like some advice on how to best identify versions

<kaz> Issue 932

seb: probably going to have a new ontology context with a new URL, victor is that right

victor: yes

seb: my question is how to distinguish JSON-LD 1.0 and JSON-LD 1.1

beny: can trigger 1.1 processing in context file; forward-pointing API
... or rather, there is a way to specify it is a 1.0 document

seb: question pattern of context URL... same pattern, just change the year?
... were looking at other standards to see how they did it, eg XML Schema

daniel: but for some reason XML Schema did NOT change the namespace

beny: I think they wanted an update-in-place

<kaz> JSON-LD 1.1 Recommendation - processing mode

daniel: well, they added new types, so potentially breaking change...

ivan: JSON-LD spec is silent on these issues
... I know the VC group or DID group may have some strong feelings about this
... because there are probably security implications
... one thing we did look at but postponed was adding a hash to context URL
... this is still an open issue, flagged for future work

<victor> ack

seb: ok, let's bring up with DID

davel: from security perspective, reason to have a year is an additional signal
... to consider how old the spec is
... what other groups have tended to do is to increment a single number
... in other words, consider it always a major change
... also, consider it "fixed", and publish a hash
... so that processors can embed it in their applications (and don't have to download it dynamically)

seb: ok, conclusion is we will talk with other groups, but it sounds like we should use the same pattern and just change the year
... but will have to follow up

issue 643

seb: base direction considerations
... note there are new terms for base direction
... but we also have a balancing act in that we also want to be compliant with JSON Schema
... and they already have some terms defined
... there are also some multiple language options, not allowed to define a container for title, etc.

<kaz> i|baes direction|Issue 643|

seb: which is why we also defined the map "titles" that can give multiple string values tagged by language
... then define default language in context block
... use case is TD might be used to generate a UI, user might want to pick a different display language
... so would like to harmonize, align with JSON-LD, but conflict with JSON Schema is a problem
... probably can't fix in TD 1.1, but we would like to discuss what to do for TD 2.0

beny: what is the JSON Schema limitation?
... I actually like the title/titles approach

seb: JSON-LD approach seems to be to keep the title, but make it array value
... but "title" is special in JSON Schema
... and a TD is also a JSON Schema...

beny: Multilanguage string is actually an object in JSON-LD...
... so also includes direction for each language

ivan: we have language maps, but you can't add direction to them
... remember we had this problem
... it was a long and hard to solve problem

beny: the margin of error is high and the value is low
... there is a verbose solution, but is it worth it?

ivan: what we are doing here is actually a hack...
... in fact this is a problem in the RDF specification itself
... really the direction should be incorporated alongside language in the RDF string model
... but it would cause problems with already-deployed SW, etc.
... we could not really solve the direction issue in a completely satisfactorily manner
... we knew in advance this was coming, and geninely tried to solve in it collaboration with the internationalization community, but
... as another option, rather than using a plain literal in titles
... instead of using a plain literal, use stripped-down HTML markup
... allowing only a very small number of tags
... shied away from it, complicates things like search and editing, not ideal, but an option

issue 988

<inserted> Issue 988

victor: json schema round trip

issue 967

<inserted> Issue 967

issue with "type" property

victor: problem with "compacting" property affordance
... fails to round-trip
... type in particular does not pick up the right definition
... something in the particulars of the syntax is causing a problem
... is this an expected behaviour, or a software bug?
... expectation is that when compacted again we just get "type", not a URL

davel: when you are doing this round-tripping, noticed
... that you defined terms so they are expected to be URLs
... so I'm wondering if you have defined a base URL

victor: context file has bases defined, so it should be interpreting that as a term

<kaz> i|devel:|Context file|

davel: there is an inline context also... will have to look at this in more detail

<sebastian> https://github.com/w3c/wot-thing-description/issues/967

victor: the other round-tripping issue is of the same kind
... issue 933
... hard to find answer, so your help would be appreciated

Discovery

<kaz> mm: (explains what wot discovery is like)

ld-proofs

<inserted> PR 943

ivan: can't give an answer on when the WG will be created...
... we are in the process of creating the minimum requirements, davel and I
... at this point, two algorithms known to sign linked data
... goal is to create a working group with two inputs, and reconcile
... core problem is normalization, and since security, has to be carefully checked
... one of the proposal is just mathematical
... other proposal is the other way around, there is an implementation, but math needs to be checked
... right now we are waiting for reviews

<victor> could you put links to these pubs here?

ivan: if we have some proofs of correctness, THEN we can do a proposal for a WG

davel: I think we are close to getting some report from the mathematicians very soon
... so certainly can't refer to it in a normative fashion right now...
... and others have done that

ivan: chartering process may not be a smooth ride... expect some objections

<inserted> [kaz: also agree we should be able to add a reference at least informatively]

lagally: what about existing work, eg. JSON web signature?

ivan: JSON web signature is JSON specific
... but they don't define normalization
... JSON-LD is more fluid, and the missing normalization is a problem

davel: that is a very long discussion... JOSE went in an opposite direction from JSON-LD, avoid normalization completely

<kaz> JSON-LD related issues for wot-discovery

quick summary of other issues

<inserted> @@url here

mm: main one in discovery are queries that can return partial results
... are these JSON-LD or not?

closing

seb: let's use the issue tracker, maybe follow up in Nov in a TD meeting

This is scribe.perl Revision of Date 
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Solbrig/Harold_Solbrig/
Succeeded: i/two major/topic: Agenda
Succeeded: i/maintenance mode/topic: JSON-LD WG status
Succeeded: s/yvon:/ivan:/
Succeeded: i|let's|WoT Thing Description Recommendation
FAILED: i|baes direction|Issue 643
Succeeded: s/marging/margin/
Succeeded: i|round trip|Issue 988
Succeeded: i| issue with "type"|Issue 967
FAILED: i|devel:|Context file
Succeeded: i|can't|PR 943
Succeeded: i|lagally:|[kaz: also agree we should be able to add a reference at least informatively]
Succeeded: i/main/@@url here
Present: Kaz_Ashimura Hazel_Kuok Michael_McCool Pierre-Antoine_Champin Victor_Charpenay Ivan_Herman David_Lehn Sebastian_Kaebisch Dave_Longley Kunihiko_Toumura ivan pchampin Tomoaki_Mizushima Christian_Glomb Daniel_Peintner Ogiso dlongley Benjamin_Young Erich_Bremer Cristiano_Aguzzi Michael_Lagally
Found ScribeNick: McCool
Inferring Scribes: McCool

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)