Here's a thought experiment: Can the linkset specification be made JSON-LD compatible with little or not changes to the linkset format itself? Can a JSON-LD @context document define everything required for linkset documents to be interpreted as RDF?

If such a thing is possible, would having an official linkset.jsonld that can be references with @context or within the Link header be something that can be baked into the linkset RFC?

@asbjornu I think that having this media type does not prevent people from using JSON-LD for the same purpose. The fact that some people prefer a different approach is not a reason to drop this one. Other people will prefer this approach. Or they won't, and it will go unimplemented. None of that impacts those who would rather use JSON-LD.

@handrews: I haven't argued for dropping linksets, I've argued for making linksets JSON-LD compatible out of the box, instead of tagging that on later. If it's easy to do, is there any good reason not to do it?

@asbjornu as long as it does not make things awkward for non-users of JSON-LD then I have no problem with it, but it's up to @dret. While I'm a fan of semantic web technologies, many projects avoid them, so there are use cases where tying something to JSON-LD/RDF (as opposed to optionally supporting it) are problematic.

Seeing how the JSON-LD context would just be a URI that can optionally be added via @context or Link header, I don't really see the harm. But yea, it's up to @dret to decide and @stain to hopefully help out defining such a context document.

that would require everybody to reference that context, and for the vast majority of users, it has no effect or utility.

I wouldn't make it required. It wouldn't have any other effect on linksets for non-RDF people than this suggestion:

define an RDF model, and then come up with media types for the preferred serializations, JSON-LD and possible others as well.

What I would like is just that this is done normatively in the RFC instead of bolted on externally by possibly many different contexts defined by many different parties.

if you supported JSON-LD with a content, wouldn't making it optional defeat the purpose of allowing all linksets to be consumed as RDF?

Yes. I suppose it's possible to inject a context on consumption, but since it's opt-in, people would have to opt-in at the producer side, just as with a non-normative, externally defined context.

and that's not even looking at the extension issue: linksets can represent extensions that are not defined in web links. the JSON syntax allows those to be represented. would those need to be covered by additional contexts?

I don't know enough about RDF to say anything concrete about this, but I'm sure there's ways to represent something alike xsd:any in RDF. Ideas, @tpluscode?

As for the initial comment by @stain, would a single link relation within a link set be equivalent to a triple? So that this snippet from the spec

{ 
  "href"   : "http://example.com/foo",
  "anchor" : "http://example.net/bar",
  "rel"    : [ "next" ] 
}

would become <http://example.com/foo> :next <http://example.net/bar> ?

If that is the intention then it looks like linkset+json and RDF are not as compatible as it superficially seems. At least without some processing it won't be as simple as slapping a @context to make this represent a triple.

From what I can tell, the linkset+json is closer in its structure to reification. This is what you get by applying rdf (the vocabulary) terms to the above:

_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#object> "http://example.com/foo" .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#predicate> <https://json-ld.org/playground/next> .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#subject> "http://example.net/bar" .

Notice how the "next" becomes based under playground. For consumers it would be a necessity to either provide a base URI (in parser or context) or add custom contexts. Published could do that easily by array-ing multiple:

{
  "@context": [
    "linkset.jsonld",
    {
      "next": "http://my-link/next"
    }
  ]
{

Is this we're talking about here? Am I missing something?

To be clear. I'd have nothing against providing the JSON-LD context for linkset+json as long as it's clear that the resulting RDF is not what people might expect. Reified statements would be just as useful

the start of this thread suggested to drop the JSON media type and use some RDF serialization instead

I agree. IMO reification is that representation in RDF model. Actually it seems to fit perfectly with minimal effort which keeping the same JSON structure you currently have

I am glad this discussion showed some thoughts on overlaps or not with RDF!

As for the relations like next, they can be made absolute under http://www.iana.org/assignments/link-relations/ using the JSON-LD @vocab mechanism as discussed in mnot/I-D#140

I prefer the idea of restructuring the application/linkset+json, JSON so it is also valid as JSON-LD, using the suggested context Link header, content negotiation to application/ld+json or this RFC could even say a @context that is implied if no Link header is present.

What makes http links not-straightforward as RDF is that the link relation itself can have additional properties, and it can be unclear if those properties relate to the subject, object or the link relation itself. In most of the cases they seem to describe the object.

If you want to keep the concept of a Link, then you would need to "reify" it somehow; RDF modelling would typically put those additional attributes on either subject, object or on a new intermediate N-ary relationship resource.

• The rfc5988bis-08 title seems to me to be an attribute of the object of the link - not very different from well known properties http://schema.org/name or http://purl.org/dc/terms/title
• type is kind of http://schema.org/fileFormat or http://purl.org/dc/terms/format but using http://www.iana.org/assignments/media-types/ as base (JSON-LD 1.1 can do that with @vocab)

Agree with @dret that pure RDF reification is not generally desirable; it is meant for statements about statements - @tpluscode example works - but does not actually imply those statements.

So then it might be just as well to make a new RDF representation of RFC8288 links; either using a new "links" vocabulary (with 1:1 mapping of #rel, #href etc); or re-using an existing model - Web Annotation Model comes to mind; which already have a specified JSON representation that addresses almost exactly the same things as this RFC:

{
  "@context": "http://www.w3.org/ns/anno.jsonld",
  "motivation": "describing",
  "body": {
    "id": "http://example.org/analysis1.mp3",
    "format": "audio/mpeg",
    "language": "fr"
  },
  "target": {
    "id": "http://example.gov/patent1.pdf",
    "format": "application/pdf",
    "language": ["en", "ar"],
  }
}

(This says that the French audio analysis1.mp3 is describing patent1.pdf which is in English and Arabic - admittedly it is more verbose, but also more extensible)

Here we just need to add our link relations under motivation.

I played a bit with how you would rather do the "expected" RDF statements in JSON-LD -- you would then turn the linkset upside-down and make the rel links primary as keys, and the href secondary; allowing any extra attributes there:

[
    {"anchor" : "http://example.net/bar",
     "next": { 
          "href"   : "http://example.com/foo",    
          "type": "application/pdf", 
          "title": "Santa Claus",
          "title*": { "@value": "Weihnachtsmann", "@language": "de" }
     },    
     "license": {
       "href": "https://creativecommons.org/licenses/by/4.0/"
     },
     "author": [ 
         {"href": "http://orcid.org/0000-0001-9842-9718"},
         {"href": "http://orcid.org/0000-0002-1267-0234"}
     ],
     "http://example.com/relations/baz": { 
       "href"   : "http://example.com/foo"
     }
   },
   {"anchor": "https://datatracker.ietf.org/doc/rfc8288/",
    "describes": {
      "href": "https://tools.ietf.org/html/rfc8288"
    }
   }
]

Here we have outgoing links for http://example.net/bar with rel values of next, license, author and the custom http://example.com/relations/baz. author shows example of multiple href link targets - allowing each of them to have their own title and so on.

Above I also used the JSON-LD syntax for language tags - I don't see any additional benefit of saving bytes of the shorter ["Weihnachtsmann", "de"] syntax as the whole point of this separate linkset file is that it was too big to include in the HTTP headers.

I parsed it with this JSON-LD syntax:

{ "@context": {
  "@vocab": "https://www.iana.org/assignments/link-relations/",
  "anchor": "@id",
  "href": "@id",
  "dct": "http://purl.org/dc/terms/",
  "link": "https://www.iana.org/assignments/link-relations#",  
  "title": {
      "@id": "http://purl.org/dc/terms/title"
   },
  "title*": {
      "@id": "http://purl.org/dc/terms/title"
   },
  "type": {
    "@id": "dct:format",
    "@type": "@vocab",
    "@context": {"@vocab": "https://www.iana.org/assignments/link-relations/"}
  }
 }

(Tip: to fake the JSON-LD context header you can paste the [ .. ] into a @graph attribute added to the above)

Using http://rdf.greggkellogg.net/distiller (which supports the recently introduced JSON-LD 1.1 scoped context) I got the RDF statements (in Turtle):

@prefix dc: <http://purl.org/dc/terms/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<http://example.net/bar> <http://example.com/relations/baz> <http://example.com/foo>;
   <http://www.iana.org/assignments/link-relations/author> <http://orcid.org/0000-0002-1267-0234>,
     <http://orcid.org/0000-0001-9842-9718>;
   <http://www.iana.org/assignments/link-relations/license> <https://creativecommons.org/licenses/by/4.0/>;
   <http://www.iana.org/assignments/link-relations/next> <http://example.com/foo> .

<https://datatracker.ietf.org/doc/rfc8288/> <http://www.iana.org/assignments/link-relations/describes> <https://tools.ietf.org/html/rfc8288> .

<http://example.com/foo> dc:title "Weihnachtsmann"@de,
     "Santa Claus";
   dc:format <http://www.iana.org/assignments/media-types/application/pdf> .

Now that I think this is much more like what you would expect in RDF land -- the license and author data is given directly just like with http://schema.org/license and http://schema.org/author; relations between the two rfc8288 pages are shown directly, and format links to an actual IANA registration.

So that would have been my preferred solution -- just modify the JSON structure slightly so that such a context could be applied. No more wheel reinvention..

I have to say, I like @stain's proposal very much. Both the bare JSON structure and its out of the box JSON-LD compatibility.

Irrespective of the JSON-LD issue, @stain's proposed JSON syntax is elegant indeed. It would probably good to evaluate how/whether it can handle all the cases summarized in #80

Hi friends. 😁

i've had some discussions with herbert and the one thing i want to avoid is to create mandatory behavior as a result of JSON-LD support that seems odd for the vast majority of plain JSON users.

@dret could you elaborate on what you see as "mandatory behavior as a result of JSON-LD support"?

Given that both specs are serializations of a graph model, it'd be great to harmonize them in some way.

Additionally, the title* property might benefit from using a structure similar to JSON-LD's language map approach:

{
  "title": "unknown language",
  "title*": {
    "en": "the english language value",
    "jp": "...if I knew Japanese...this would be in kanji..."  
   }
}

Checkout ActivityStreams JSON format (based on JSON-LD and in use in Mastodon and friends) for a similar approach: https://www.w3.org/TR/activitystreams-vocabulary/#dfn-name

Let me know how I can help!
🎩

requiring a context. afaict, JSON-LD requires you to specify a context, because without it, it's not defined at all what RDF the JSON represents, right? for JSON users, that context serves no purpose, and they shouldn't get into trouble for ignoring it.

Developers will have to understand the JSON somehow the context in JSON-LD is that "how."

For instance, to properly understand/utilize/process an application/linkset+json file, you have to know what the terms anchor, rel, href (etc) mean in that context (see where this is headed? 😉).

The simplest, no-additional-parsing-needed JSON-LD @context looks like:

{
  "@context": {
    "@vocab": "https://tools.ietf.org/html/draft-wilde-linkset-02#"
  }
}

If that were (or could be) added to an application/linkset+json file or (more likely right now) served as a Link header-based context (see Interpreting JSON as JSON-LD), then href would have the globally unique identifier https://tools.ietf.org/html/draft-wilde-linkset-02#href (based on the @context above)--i.e. the value of @vocab is string concatenated to the terms used throughout the document.

Even if the developer receiving the data doesn't yet know what the terms mean--or even that the @vocab concatenation happens in a JSON-LD processor, they still have the benefit of receiving an absolute URL (or even just a more verbose/meaningful identifier) to use in figuring out what things mean in the document.

The other things expressible via the @context object (or file) build on that to provide even clearer "meaning" to the data included--what things are strings, what things are language values, what things are URLs, etc.

Here's an article I wrote awhile back that explains a bit more of the value proposition (even if you don't do RDF): https://blog.codeship.com/json-ld-building-meaningful-data-apis/

one very simple question for the proponents of supporting JSON-LD: does the recently published JSON-LD 1.1 still mandate that a context must always be specified? i am not quite sure how to make things work otherwise, but i simply don't know enough about 1.1 to know the answer. thanks!

@dret it isn't JSON-LD without a context specified. 😃 However, you can specify a context in either the content (via @context) or in a Link header (see Interpreting JSON as JSON-LD).

However, picking up from where we were earlier:

Developers will have to understand the JSON /somehow/ the context in JSON-LD is that "how."

that's true for JSON-LD users, which is a tiny subset. the usual way is to read the spec. it may not be what you like of prefer, but it's the reality of today's API space.

In the JSON linkset spec, the "how" JSON developers understand what's in the JSON is via a unique media type for linksets and looking up that meaning by finding the RFC for the linkset media type.

In a JSON-LD document, the context provides that "how". JSON-LD processors can use that context to create full URLs to each term--which can (at the discretion of the vocabulary owner) load documentation for each term (see https://schema.org/Article and https://schema.org/articleBody etc). This can be accomplished completely without knowing about RDF.

Additionally, with a very minimal understanding of the intention of @context and @vocab a developer can create such dereference-able term URLs using a context as simple as:

{
  "@context": {
    "@vocab": "https://tools.ietf.org/html/draft-wilde-linkset-02#"
  }
}

The @vocab value can be concatenated with any term (key name) found in the document resulting in URLs like: https://tools.ietf.org/html/draft-wilde-linkset-02#anchor Those URLs could be page anchors within the RFC, and you'd have provided in context references to documentation as well as globally unique identifiers for the key names used within the format.

To accommodate this sort of "value add", the current linkset spec would first need to be reshaped as an object containing an array--as arrays provide nearly no extensibility mechanism...if any, really...

So, something like...

{
  "linkset": [
    {
      "href"   : "http://example.com/foo",
      "anchor" : "http://example.net/bar",
      "rel": [ "next" ]
    }
  ]
}

With that in place adding some contextualization is a trivial addition:

{
  "@context": {
    "@vocab": "https://tools.ietf.org/html/draft-wilde-linkset-02#"
  },
  "linkset": [
    {
      "href"   : "http://example.com/foo",
      "anchor" : "http://example.net/bar",
      "rel": [ "next" ]
    }
  ]
}

Even if you don't (yet? 😉) see the value of what JSON-LD provides, reshaping the linkset data into top-level JSON objects (instead of arrays), give JSON-LD folks (and many others...including your future self), the opportunity to extend the format further. So I'd start there at least. 😁

i know all of the mechanics. we just disagree on how to balance mandating those mechanics, and the subset of people actually using them.

I know you know the mechanics, of course. 😃 Just restating them for clarity (for others) and for my own rethinking value. Every media type presumes a similar set of required understanding, parsing, and intended use. JSON-LD just happens to be a widely used and quickly growing flexible overlay on top of "raw JSON" and the plethora of on-off +json media types each with their own semantics and intentions and use cases.

It's ground to build up from vs. unique, one-off media type "house." Any option out there will require additional parsing/processing/understanding, JSON-LD is just an increasingly common foundation for building JSON-based things.

/me gets off soapbox. 😉

I've filed #105 which should help everyone. Do let me know if you need/want anything from the JSON-LD WG or the in-progress 1.1 spec. Help welcome! https://www.w3.org/2018/json-ld-wg/

I'd also like to show support for @stain 's proposal re closer alignment with JSON-LD.

The only thing I'd like to raise here is whether there is a possibility to rename the "anchor" term to "id". I don't know if I'm overlooking anything, so let me know. I personally find "anchor" and "href" too close semantically at first glance.

To build on the JSON-LD-readable approach, while still being JSON-readable, I'd propose to use the term "@id" or ("id" with context) replacing "anchor". Using id may be more clear in terms of fixing the primary subject of the expression in which everything else is in relation to. So, "right away" we know that next or license is about that id. With "anchor" and "href" it is not particularly intuitive (IMHO!) .. and if rev is used anywhere, it gets confusing.

In the case where anchor is optional as per:

Each link object MAY have an "anchor" member with a value that
represents the link context. If this member is not provided, the
link context is the link set resource

( also mentioned in #80 (comment) )

"@id" value can be empty: "@id": ""

@dret Got it. I agree.

I was wondering whether, in the proposal by @Stian, it would not make things easier if the hrefs would always be expressed in an array, instead of only using an array when there's more than 1 href. E.g. (adding linkset as per #103):

{
  "linkset":
  [
    {"anchor" : "http://example.net/bar",   
     "license": [
         {"href": "https://creativecommons.org/licenses/by/4.0/“}
     ],
     "author": [ 
         {"href": "http://orcid.org/0000-0001-9842-9718"},
         {"href": "http://orcid.org/0000-0002-1267-0234"}
     ]
    }
  ]
}

@stain, all, after talking with @hvdsomp:

What do you think about including language and value as aliases in the JSON-LD context? That should simplify the input, at least when looking at it as a plain JSON right? I've also mapped hreflang as well. I'm not sure what would be best at the moment, but the example below uses Activity vocabulary's hreflang: https://www.w3.org/TR/activitystreams-vocabulary/#dfn-hreflang (because it supposedly closely associated to Web Linking's hreflang [as used on AS2 Link], which is derived from Atom). The mapping could just as well be to dcterms:language ("hreflang": { "@id": "dct:language", "@container": "@set"}) and that should serve just fine I think - maybe even more "stable" at this point.

What do you think?

{
  "@context": [
    {
      "@vocab": "https://www.iana.org/assignments/link-relations/",
      "anchor": "@id",
      "href": "@id",
      "dct": "http://purl.org/dc/terms/",
      "link": "https://www.iana.org/assignments/link-relations#",
      "title": {
          "@id": "http://purl.org/dc/terms/title"
       },
      "title*": {
          "@id": "http://purl.org/dc/terms/title"
       },
      "type": {
        "@id": "dct:format",
        "@type": "@vocab"
      }
    },
    {
      "language": "@language",
      "value": "@value",
      "hreflang": {
        "@id": "https://www.w3.org/ns/activitystreams#hreflang",
        "@container": "@set"
      }
    }
  ],

  "linkset": [
    {
      "anchor": "http://example.net/qux",
      "next": {
        "href": "http://example.net/xyz",
        "hreflang": ["en", "de"]
      }
    },
    {
      "anchor" : "http://example.net/bar",
      "next": { 
        "href": "http://example.com/foo",    
        "type": "application/pdf", 
        "title": "Santa Claus",
        "title*": {
          "value": "Weihnachtsmann",
          "language": "de"
        }
      },    
      "license": {
        "href": "https://creativecommons.org/licenses/by/4.0/"
      },
      "author": [ 
        { "href": "http://orcid.org/0000-0001-9842-9718" },
        { "href": "http://orcid.org/0000-0002-1267-0234" }
      ],
      "http://example.com/relations/baz": { 
        "href": "http://example.com/foo"
      }
    },
    {
      "anchor": "https://datatracker.ietf.org/doc/rfc8288/",
      "describes": {
        "href": "https://tools.ietf.org/html/rfc8288"
      }
    }
  ]
}

Turtle would come out as (from JSON-LD playground):

<http://example.com/foo> <http://purl.org/dc/terms/format> <https://www.iana.org/assignments/link-relations/application/pdf> .
<http://example.com/foo> <http://purl.org/dc/terms/title> "Santa Claus" .
<http://example.com/foo> <http://purl.org/dc/terms/title> "Weihnachtsmann"@de .
<http://example.net/bar> <http://example.com/relations/baz> <http://example.com/foo> .
<http://example.net/bar> <https://www.iana.org/assignments/link-relations/author> <http://orcid.org/0000-0001-9842-9718> .
<http://example.net/bar> <https://www.iana.org/assignments/link-relations/author> <http://orcid.org/0000-0002-1267-0234> .
<http://example.net/bar> <https://www.iana.org/assignments/link-relations/license> <https://creativecommons.org/licenses/by/4.0/> .
<http://example.net/bar> <https://www.iana.org/assignments/link-relations/next> <http://example.com/foo> .
<http://example.net/qux> <https://www.iana.org/assignments/link-relations/next> <http://example.net/xyz> .
<http://example.net/xyz> <https://www.w3.org/ns/activitystreams#hreflang> "de" .
<http://example.net/xyz> <https://www.w3.org/ns/activitystreams#hreflang> "en" .
<https://datatracker.ietf.org/doc/rfc8288/> <https://www.iana.org/assignments/link-relations/describes> <https://tools.ietf.org/html/rfc8288> .
_:c14n0 <https://www.iana.org/assignments/link-relations/linkset> <http://example.net/bar> .
_:c14n0 <https://www.iana.org/assignments/link-relations/linkset> <http://example.net/qux> .
_:c14n0 <https://www.iana.org/assignments/link-relations/linkset> <https://datatracker.ietf.org/doc/rfc8288/> .

Edited: to include Turtle serialization, and fixed example.

I like the addition from @csarven to make language and hreflang work well without @keywords.

I also think having {} for the optional language tag is cleaner than nesting as array within arrays (multiple languages would be a typical case of using title*)

I agree with @dret that we should not mandate @context JSON-LD parsing. The point here of adding a JSON structure is to be able to parse it as pure JSON.

I would rather say that a @context is optional key, and provide a default context inline in the RFC and say that any then JSON structure compliant with this RFC could then alternatively be parsed as JSON-LD using that inline (or equivalent) context.

An equivalent context may for instance be to map it to schema.org instead of DCTerms. It would be up to those making alternative @context to make sure they map to the JSON keys used, which should still comply with the JSON-only requirements of this spec.

(It would be good if IETF would also allow us to give it a nice permalinkable URL so we can reference that from within the RFC - not sure if they have done anything like that so far or how to do that pre-RFC status in an I-D)

If you want I can have a go at formalizing this in a pull request to the ID? I won't have time for the next week, so ping me back.

@csarven if you are bringing in ActivityStream hreflang, then what about https://www.w3.org/TR/activitystreams-vocabulary/#dfn-rel ?

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Link",
  "href": "http://example.org/abc",
  "hreflang": "en",
  "mediaType": "text/html",
  "name": "Preview",
  "rel": ["canonical", "preview"]
}

Their Link is a "reified" approach that looks similar to the current application/linkset+json JSON, where "canonical" just becomes a string.

Perhaps not mix up the two approaches, and either keep hreflang mapped to dcterms:language (seeing the other properties use DC terms) -- or redo this whole approach to be closer to Activity Stream's reified rel expression.

@stain, I am currently (offline) working on a new version of the I-D that includes a description of the new JSON serialization. I hope to be able to put it up in the repo in the course of next week. I think it would be better if you would make adjustments to that version.

I had discussed a strategy similar to the one (I think) you propose with @dret, i.e.:

• Specify the JSON serialization in the I-D
• Indicate as part of that specification that the JSON serialization is "ready for use" in JSON-LD environments too
• In an Appendix, give an example of a context for use of the serialization as JSON-LD

@stain Just a minor comment... that data block with @context was only intended to view easily as a whole. I didn't mean to diverge from your original proposal.. ie keep it JSON, but JSON-LD parsable (eventually).

Great you are having a go @hvdsomp, those were exactly my thoughts!