search

dret / I-D

Internet Drafts I've authored or contributed to.
17 stars 13 forks source link

Why yet another link relation format? #89

Closed stain closed 4 years ago

stain commented 7 years ago

Responding to draft-wilde-linkset-01

I wonder about what is the purpose of inventing a new media type application/linkset+json, when it is basically just a restricted form of RDF triples, where anchor ~= subject, rel ~= predicate and href ~= object - the set of which form a linkset or - if you like - a graph. (You didn't say they all needed to have the same anchor)

I am particularly worried as this draft seems to re-invent RDF Literal with language tags. Yes, these are important issues - which is why they have already been addressed.

See also how to describe RDF linksets - this would be the metadata about the linkset itself.

(I'm less ambivalent about application/linkset as it directly reflects the HTTP headers, I can see that as useful)

What this InternetDraft could instead do is to refer to existing RDF formats N-Triples -- which is flat and easy to parse -- and JSON-LD -- and give examples of how to represent HTTP links in those.

The main missing bit is to add a @vocab to more easily refer to the "non-absolute" link relations like "alternate" (See also mnot/I-D#39 and mnot/I-D#140)

Perhaps application/linkset+json should simply be tweaked to be a subset of JSON-LD by having an appropriate @context -- then you can reuse the Link header terminology.

dret commented 7 years ago

thanks for the comment.

On 2017-10-18 11:26, Stian Soiland-Reyes wrote:

I wonder about what is the purpose of inventing a new media type `application/linkset+json|, when it is basically just a restricted form of [RDF triples](https://www.w3.org/TR/rdf11-primer/), where|anchor ~= /subject/, rel ~= /predicate/ and href ~= /object/ - the set of which form a linkset or - if you like - a graph. (You didn't say they all needed to have the same anchor)

that's what RFC 5998bis web links are: typed relationships between resources. but links also have target attributes, which serve as annotations of these links. of course these can be modeled in RDF as well. but that would complicate the model quite a bit.

and then there would be the additional issue of representing RFC web link relations, which are strings, as RDF predicates, which have to be URIs. that problem remains a bit tricky because RDF's metamodel isn't such a great fit for this particular aspect of web links.

but generally speaking, the purpose of this draft is not to represent web links in RDF. it is to represent the web link model in easily consumable forms.

we have chosen the native representation and a JSON representation, based on the scenarios that we are working with. if you are interested in representing web links in RDF, you can do so, and then define media types that identify these.

asbjornu commented 7 years ago

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?

handrews commented 7 years ago

@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.

asbjornu commented 7 years ago

@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?

handrews commented 7 years ago

@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.

asbjornu commented 7 years ago

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.

dret commented 7 years ago

On 2017-10-18 22:23, Asbjørn Ulsberg wrote:

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?

that would require everybody to reference that context, and for the vast majority of users, it has no effect or utility. meaning that many will not do so, rendering them technically non-compliant.

if the RDF community is interested in representing web links, i'd rather just go the route outlined earlier: define an RDF model, and then come up with media types for the preferred serializations, JSON-LD and possible others as well.

dret commented 7 years ago

On 2017-10-19 00:00, Asbjørn Ulsberg wrote:

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

now i am getting curious on the technical level: 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? technically, JSON-LD is just RDF written down in JSON, and if you drop the context, it's not JSON-LD anymore and then interoperability suffers, because for anybody using their JSON-LD toolsets things stop working.

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? if not, any extension would become invisible after mapping into RDF. in order to be robust, who would be in charge of defining and providing these extension contexts?

asbjornu commented 7 years ago

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?

tpluscode commented 7 years ago

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?

dret commented 7 years ago

On 2017-10-19 21:48, Tomasz Pluskiewicz wrote:

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.

that's the thing: while web links often trigger the "this looks just like RDF" gut reaction, their way of managing the link type is different from what RDF can natively deal with.

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 http://tinyurl.com/yas6rsxc 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" . |

yup, that's the cop out. now it looks much uglier and the direct structural resemblance with RDF is gone. we're not really that interested in how to best represent web links in RDF, which is why we decided to go with the native syntax and a simple JSON syntax that is directly based on the native model.

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

no you're not. thanks for the input!

tpluscode commented 7 years ago

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

dret commented 7 years ago

On 2017-10-21 10:45, Tomasz Pluskiewicz wrote:

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

sure, and they may be the only way to properly represent web links. and it's not that we have anything against JSON-LD or RDF models for web links. it's just not something that seems to come up much, and as mentioned before: if somebody feels like doing it, i don't think we're holding anybody back.

and for context: the start of this thread suggested to drop the JSON media type and use some RDF serialization instead. we responded that our goal was not to define a RDF model for web links, and were simply interested in a straightforward JSON one. that's still the case.

tpluscode commented 7 years ago

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

dret commented 7 years ago

On 2017-10-21 13:53, Tomasz Pluskiewicz wrote:

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

personally, reification is not something that i really like. i don't know how the general RDF community is in favor of that. but deciding that is up to those coming up with the RDF model.

stain commented 7 years ago

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.

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..

asbjornu commented 7 years ago

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.

hvdsomp commented 6 years ago

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

dret commented 6 years ago

hello stian.

On Oct 26, 2017, at 07:29, Stian Soiland-Reyes notifications@github.com wrote:

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.

i don't think we can do that. a context MUST be explicit as per JSON-LD, afaict. maybe that changes with 1.1?

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.

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.

without getting into the weeds of how to best represent linksets and links in RDF: what would speak against a separate document defining the RDF model and some context for JSON-LD support? we could collaborate on aligning our JSON model and that draft's context and RDF model, but it would be a completely separate spec for those interested in representing linksets in some RDF serialization.

cheers,

dret.

BigBlueHat commented 6 years ago

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! 🎩

dret commented 6 years ago

On 2018-08-22 09:20, BigBlueHat wrote:

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 https://github.com/dret could you elaborate on what you see as "mandatory behavior as a result of JSON-LD support"?

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.

or am i misunderstanding JSON-LD's requirement for a context?

Additionally, the |title*| property might benefit from using a structure similar to JSON-LD's language map https://w3c.github.io/json-ld-syntax/#h-note-14 approach:

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

that looks pretty elegant. but if i recall correctly, our current design is based on treating all xxx attributes the same, and title just happens to be one of those. @hvdsomp, what do you think?

BigBlueHat commented 6 years ago

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/

dret commented 6 years ago

On 2018-08-22 17:32, BigBlueHat wrote:

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."

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.

dret commented 6 years ago

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!

BigBlueHat commented 6 years ago

@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. 😁

dret commented 6 years ago

On 2018-09-12 16:20, BigBlueHat wrote:

@dret https://github.com/dret it isn't JSON-LD without a context specified. 😃 However, you can specify a context in /either/ the content (via |@context| https://www.w3.org/TR/json-ld11/#the-context) or in a |Link| header (see Interpreting JSON as JSON-LD https://www.w3.org/TR/json-ld11/#interpreting-json-as-json-ld).

yup, i know these variants. they make it mandatory to specify a context, and like i said, i wouldn't know how to make JSON-LD work without it. but thanks for confirming!

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.

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

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 do like this as a general proposal to improve the JSON structure. i just chatted with @hvdsomp about the way forward. would you mind raising this as a separate issue so that we can keep track of it? thanks!

BigBlueHat commented 6 years ago

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. :smiley: 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/

csarven commented 5 years ago

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 https://github.com/dret/I-D/issues/80#issuecomment-454040571 )

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

dret commented 5 years ago

On 2019-01-27 15:50, Sarven Capadisli wrote:

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.

i see your point and agree that the word is not the best pick.

but this is first and foremost an initiative to create serializations for RFC 8288, and sticking to the established terminology of that spec to me makes more sense than trying to improve it.

csarven commented 5 years ago

@dret Got it. I agree.

hvdsomp commented 5 years ago

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"}
     ]
    }
  ]
}
csarven commented 5 years ago

@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.

stain commented 5 years ago

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.

stain commented 5 years ago

@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.

hvdsomp commented 5 years ago

@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.:

csarven commented 5 years ago

@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).

stain commented 5 years ago

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

dret commented 5 years ago

@hvdsomp, should we publish your update from february? by now, the published version is expired, and if there is interest in the new JSON format, maybe an updated draft would be useful?

dret commented 4 years ago

can be closed, this was a great issue and discussion! thanks!