linkset relation type

[Herbert Van de Sompel]

Hi all,

While we are all waiting for "cite-as" to be registered, please have a look at another signposting-related effort: the "linkset" relation type. Current version of the I-D at https://tools.ietf.org/html/draft-wilde-linkset-01

This I-D and relation type are about providing links by reference rather than by value. One of the anticipated use cases is CrossRef providing signposting links on behalf of publishers. In this case, a publisher would merely provide a "linkset" link e.g. from the landing page of one of its articles. This link would point at an appropriate document/service at CrossRef and would yield the actual signposting links for the publisher's article.

The GitHub repo for this is at https://github.com/dret/I-D/tree/master/linkset . Feedback welcome.

Cheers

Herbert

--

Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
http://orcid.org/0000-0002-0715-6126

==

[Herbert Van de Sompel]

On Wed, Oct 18, 2017 at 3:52 AM, Stian Soiland-Reyes <soilan...@manchester.ac.uk> wrote:

To me this reads like a poor-man’s JSON-LD..?  Why re-invent yet another way to represent a graph of relations?

 

I’ve responded on https://github.com/dret/I-D/issues/89 although I think I could have formulated it better.. any help welcome 😊

 

There's meanwhile a tech discussion going on over at GitHub. But let me give you some background on all this.

Signposting is a deliberately "as simple as possible" approach to address some specific, longstanding issues in web-based scholarly communication. The choice for using web links as a "no brainer" technology is deliberate and informed by a variety of efforts I have been involved in over the years, both using and not using the RDF stack. The problems signposting is addressing did not require RDF so the choice was not to use RDF, as opposed to e.g. Open/Web Annotation, a complex problem that required RDF to get solved. To summarize: In order to cast the net of potential adopters as wide as possible, the simplest technology able to address the very specific problems was chosen. Feedback received from early adopters regarding required implementation time confirms it is simple indeed. 

As it turns, I was told that Signposting wasn't even simple enough to stand a chance of getting implemented by scholarly publishers. Not even the "cite-as" link (previously known as "identifier), which actually is intended to make sure that the DOIs publishers assign to their publications would actually be used for referencing; as you know, we learned in our research that many times they are not. There would, however, be a chance that something would happen with Signposting if it would be implemented centrally by CrossRef, not de-centrally by publishers. As such, the idea of providing a set of links by-reference (and the associated "linkset" relation type) arose.  I'd much rather have these links be exposed at the publishers. But since that seemed out of the question, and since I really would love signposting to get adopted, I decided to embark on the "linkset" I-D effort. Since Erik Wilde (@dret) had previously done work on linksets in the XML days, I reached out to him to collaborate.

One serialization, application/linkset, presented itself naturally. It's exactly the same format as the payload of the HTTP Link header, and, obviously directly based on the "link model" of RFC5988bis, see https://tools.ietf.org/html/draft-nottingham-rfc5988bis-08#section-2

The omnipresence of JSON and the fact that there was another effort aimed at a JSON serialization of links (see https://tools.ietf.org/html/draft-ietf-core-links-json-08) led to the idea to also define an application/linkset+json. Again, for obvious reasons, we based that work on the "link model" of RFC5899bis. Our attempts to reach out to the people behind the other effort led nowhere, thus far. As such, we have what we have in the I-D. Given the intended simplicity, doing anything RDF-y never even came up. Not in the other effort either, BTW.

Without getting too technical (we can do that in GitHub): You make it sound like a choice of serialization i.e. JSON versus JSON-LD. But I think it's a tad more involved and at the core this is a problem of different basic models (link model of RFC5988bis versus RDF model, IETF/IANA school versus W3C sem web school). I noticed you were also involved in the discussions https://github.com/mnot/I-D/issues/39 and https://github.com/mnot/I-D/issues/140, which essentially touched upon this very issue. Specifically I note that these extensive discussions did (AFAIK) not lead to a solution regarding expressing IANA link relation types as URIs, and language that was proposed with this regard never got included in RFC5988bis, which is well on its way to become an IETF standard. It is not in the scope of our "linkset" I-D effort to resolve that matter, especially since it was not resolved as part of the revision of RFC5988. But, some sensible things are being said in the GitHub issue you started, especially - IMO - by @handrews . I'll keep a close eye on where that all is going.

Cheers and thanks for your interest

Herbert

 

--
Stian Soiland-Reyes, eScience Lab
School of Computer Science, The University of Manchester
http://orcid.org/0000-0001-9842-9718

--
You received this message because you are subscribed to the Google Groups "signposting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to signposting+unsubscribe@googlegroups.com.
To post to this group, send email to signp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/signposting/CAOywMHeV6DYDMN0LhbO6a%3DhSwBFTMrdb1mWt-_vjMRC0-e0Z1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.