Subject: [core] 🔔 WG Last Call of draft-ietf-core-links-json

From: Jaime Jiménez <[email-masked]>
Date: Sat, 9 Jul 2016 07:26:25 +0000

Hi all,

This is the Working Group Last Call for the "Representing CoRE Formats in JSON and CBOR” document.
https://tools.ietf.org/html/draft-ietf-core-links-json-06

Due to the IETF meeting, the call is planned to end three weeks from now by July 30th. If possible, comments should be provided early so that we can discuss this during the CoRE sessions on IETF96.

BR,
- - Jaime Jimenez

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 18 Jul 2016 01:21:59 +0200

Hello Michael, hello group,

> Due to the IETF meeting, the call is planned to end three weeks from now by July 30th. If possible, comments should be provided early so that we can discuss this during the CoRE sessions on IETF96.

Sorry this is a bit late, I've only now come around to review all my
unread mails on the topic.

It is my impression from the mails on links-json that the attempts to
get a semantically parsable JSON representation were moved into the
hypermedia approaches because JSON-LD could only do something meaningful
with a list of rt (if, ct etc.) values, while links-json should stay
simple and 1:1 take over link-format's whitespace separated strings.

Michael, do you concur with the above? (The question goes anyone, but
you were most active in the discussion.)

The objectives section mentions has a "Consider other work that has
links in JSON, e.g.: JSON-LD, JSON-Refernce" paragraph. If the above
holds, JSON-LD was considerered and deemed unsuitable. Of
JSON-Reference, I couldn't find a mention -- it was not adopted for
links-json, so it was either not considered or also considered and
deemed unsuitable.

Shouldn't the results of these considerations be reflected in the text?
I think so, because otherwise readers could be led to conclude from the
mention that JSON Link Format would work with JSON-LD.

To keep "code locality" in the text, my suggested course of action
(assuming JSON-Reference was considered) is adding an additional bullet
under "Consider":

  * Both JSON-LD and JSON-Reference were considered, but supporting them
    in JSON Link Format would have introduced too much complexity in the
    conversion to be practical.

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Michael Koster <[email-masked]>
Date: Mon, 18 Jul 2016 08:51:50 +0200

Hi Christian,

I believe that it is a requirement for core-links-json tobe a 1:1 bidirectionally lossless mapping to CoRE Link-Format. This has been my assumption anyway.

As I remember the earlier discussion, we considered using a JSON-LD context file to process a core-links-json representation and map keywords and values from the link-format representation to descriptive URLs. We were discussing whether this was meaningful for high level applications that want to comprenend the content of the links, i.e. relation values, attribute values, etc.

I don't think it was fully resolved, and would like to continue the discussion. I think for the draft, if the use case and requirements are clear about lossless mapping of CoRE Link-Format, we could set the context for the comments about JSON-LD.

Perhaps we could discuss JSON-LD mapping separately and involve any other interested parties?

Best regards,

Michael

> On Jul 18, 2016, at 1:21 AM, Christian Amsüss <[email-masked]> wrote:
>

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 18 Jul 2016 18:26:03 +0200

Hi Michael,

(Context for the rest of the mailing list: We've just spent >2h trying
to figure out how to save JSON-LD-ability of the draft, and came up with
an almost viable solution that would allow not only semantic
interpretation of the link-format but also CURIEs in there.)

On Mon, Jul 18, 2016 at 08:51:50AM +0200, Michael Koster wrote:
> I don't think it was fully resolved, and would like to continue the discussion.

when I was writing up the results of our session, I noticed two possibly
critical issues:

* If we translate 'core.s' to 'core:s' for currie-ability, the
  back-conversion is not given. We could attempt something like 'if
  there is exactly one colon and no slash in the URI' (which is bad by
  itself), but even that would have at least theoretical
  non-roundtrippabilities.

* In JSON-LD documents that are lists, there can't be a common context
  without wrapping the whole document in a {"@context":...,
  "@graph":DATA} container -- otherwise, the @context (in which we'd
  store any information obtained from a <http://../>;rel="curie";
  curie="foaf") would need to be duplicated for every entry in the list
  (see JSON-LD example 51[1]).

  The only workaround I'd see is to rely entirely on the default context
  to provide CURIEs for all registered prefixes.

To you have thoughts on how we could fix that?

I'm all for keeping trying to find a working solution, but if that gets
worse, we should consider defining an RDF mapping of link-format that is
not coupled to links-json.

Until later
Christian

[1] http://www.w3.org/TR/json-ld/#named-graphs

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 18 Jul 2016 18:52:07 +0200

It may be a bit unusual for an author to send WGLC comments, but I do
have three:

-- We could use the same three-part CDDL structure that we used in SenML
for covering both JSON and CBOR with the same main CDDL spec.
(This would also provide an opportunity to fix a bug with the Figure 2
[finding which is left as an exercise to the reader].)

-- We need to ask IANA for Content-Format numbers for the two new media
types.  No idea how this got lost...

-- I agree that we should not claim to have solved JSON-LD interworking;
maybe we should simply remove some of the material that goes beyond
objectives 1 and 2 in section 1.1, because these are really the ones we
did focus on.

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 19 Jul 2016 01:36:55 +0200

Hello Michael,

> not coupled to links-json.

I'll only arrive at the venue tomorrow around 1030 / 1100, I think it
would be advisable if we could talk this over before or over lunch. Do
you have an hour unplanned before the core session? The changes for
JSON-LD compatibility would be something that (from my limited
understanding of the processes) would hold up the last call, and we
should be confident about that to do it.

See you tomorrow
Christian

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 19 Jul 2016 18:22:54 +0200

> objectives 1 and 2 in section 1.1, because these are really the ones we

As pointed out in the WG meeting, I'd like to add a bullet in the
'Consider other work' section to address this issue:

* Adaptions to make this suitable for JSON-LD consumption would have
  conflicted with the above goals (rt/if/ct values would have needed to
  be made repeatable instead of space-separated and turned into CURIEs,
  link-format extensions and default values could not be covered).

<skip unless="trying to understand what the obstacles were">

Just to have things documented somewhere (doesn't fit in the draft, but
should give the rationale for people who look up the rationale for the
above), here are some more details:

* Whitespace separated properties like rt/if/rel/rev/ct would need to be
  split into a JSON array to avoid producing semantically nonsentical
  statements like `</temp> core:rt "temp outside-temp"`. As the
  conversion process would need to be comprehensively specified for the
  RFC, we'd need to recommend link-format extensions to not use the
  whitespace separation at all and make everything into repetible
  attributes, compromising the compactness of link-format.

* Resource type values and similar would need to be JSON-LD @id
  properties in order for ext-rel-type URIs to be correctly represented
  as URIs and not literals. For reg-rel-type (like "core.s"), best thing
  we could do would be provide a prefix (could be a CURIE) that would
  need to be prepended to every value in rt etc. For example, rt="core.s
  core.b" would have for example become "rt":[":core.s",":core.s"] and
  rely on the @context to provide a central default CURIE in which then
  all registered types would reside. That'd be very inflexible URI
  design, and would only work for the few properties we define this
  beforehand. Worst of all, while the string-splitting could have been
  argued to be practical for JSON in general too, this would be a change
  exclusively introduced in order to satisfy this use case.

  (We did consider that we could start swapping dots and colons around
  to have core:s style CURIEs, but that would be equally intrusive,
  non-roundtrippable, and couldn't be done with ad-hoc CURIEs because
  JSON-LD that's a top-level list can't have a global list of
  document-defined CURIEs without even more intrusive changes to the
  document structure).

* For some properties, default values are specified (eg. rel=hosts
  unless specified differently), which could not be inserted by the
  @context (which at least could be remotely updated for every new
  registered extension), but need support from the links-json
  conversion.

</skip>

As having a semantic view on the link format information is still an
interesting thing to have, the most promising direction to continue in
is to describe the semantics we'd like to obtain from a link-format
file, which is something that should be coordinated with the T2T people.
The semantic statements should be derivable from any link-format
representation, but as opposed to json-link-format, where any
intermediate node like a HC proxy could do the conversion, only the
consuming client or the origin server (that know which link-format
extensions they are interested in or provide, respectively) could do
that conversion.

Best regards
Christian