Use of rel="item" in signposting on the scholarly web

[Petr.Knoth]

Hi all,

 

We are in the process of implementing signposting support in CORE. As we started the work, one question with regards to the identification of the scholarly manuscript, as envisaged on page 23 of these slides: https://www.slideshare.net/hvdsomp/signposting-overview-version-november-2017, came up.

 

At the moment it is envisaged that link type rel=”item” should be used to identify items in the collection (as defined here: https://www.iana.org/assignments/link-relations/link-relations.xhtml ). I feel more could be done to help robots navigate to the scholarly article available from a splash page.

 

One of the issues a robot typically needs to resolve when harvesting repositories (particularly DSpace) is to identify the link to the scholarly article from the splash page. However, this page may sometimes contain links to other supplementary material that is relevant to the resource as well, such as slides or licence files. It could, in principle, also contain links to a description of a research dataset (or even the dataset), data management plan, maybe even previous versions of the paper. If all of these resources are linked using rel=”item”, it will be difficult to distinguish the resource  the robot is looking for (e.g. the academic paper) from other resources with the same mime-type.

 

I would like to know if anyone of you have thought about this. I also wonder what rel types do we want repositories to use in these circumstances.

 

It seems to me that we might need:

- a new rel type “dataset”, to describe links to research data,

- to explicitly recommend repositories to support the use of rel=”license” for license files,

- a mechanism to distinguish slides from the manuscript (e.g. a new rel=”scholarly-article”)

 

What do you think about this?

 

Best,

 

Petr

 

 

--

Dr. Petr Knoth

Senior Research Fellow

Knowledge Media institute, The Open University

Walton Hall, Milton Keynes, MK7 6AA, BUCKS, United Kingdom

phone: +44 (0)1908 654548, Web:

http://kmi.open.ac.uk/people/member/petr-knoth, Twitter: @petrknoth

-- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302). The Open University is authorised and regulated by the Financial Conduct Authority in relation to its secondary activity of credit broking.

[Herbert Van de Sompel]

Hi Petr,

Thanks for your mail. 

The essence of your message is really about expressiveness. Signposting is by choice extremely simple; its expressiveness is rather coarse. As one adds expressiveness, complexity typically increases. For example, the “item” problem can also be addressed with high expressiveness using the RDF-based OAI-ORE. But that’s going to be a tad more complex ;-) It’s an expressiveness/complexity balance, which I have pointed out in http://dx.doi.org/10.1045/november2015-vandesompel and slides  17 and 21 of https://www.slideshare.net/hvdsomp/reminiscing-about-interoperability

Having said that, within the technology stack chosen for Signposting, there are still some things one can do to add expressiveness:

1. Use MIME typing as a (very coarse) indicator of the nature of an “item” resource 

2.Use semantic typing as an indicator of the nature of an “item” resource 

Regarding (2):

- Signposting has a “resource type”pattern, see http://signposting.org/resource_type/ . This is about a link with the “type” relation type exposed by an “item” resource. Meaning, a robot would need to do an HTTP HEAD on each “item” resource to find the items it is interested in.

- The Signposting site recommends the use of terms from schema.org as semantic types, ie as targets of the “type” Links. That’s obviously in order to achieve broad interoperability. URIs from other vocabs can be used but one needs to be aware of the impact this has on broad interop.

- I had anticipated  the need you describe and had aimed at the ability to express the semantic type as an attribute on the “item” link itself.  This would avoid doing the extra HTTP HEADs on the “item” resources to determine what they are. I had proposed this in relation to the Link Hint Internet Draft that Mark Nottingham was working on, see https://github.com/mnot/I-D/issues/175 . By now, it is clear that Link Hints is not going to happen, one of the reasons being that there’s quite some opposition to retroactively defining attributes that would apply to all link relation types. 

Bottom line:

- You can add semantic typing to “item”resources but you need to do so via a link with the “type” relation on those resources themselves. You can’t convey this info on the “item” links. 

- For interop, it would be good to use terms from schema.org as semantic type indicators. 

- This gives you increased expressiveness within the confines of a simple technology stack. If you need more, it may not be possible to achieve it within this stack ... Weigh your options carefully ;-)

Cheers

Herbert

--
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...@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/9483FE69-59FF-4DBC-9533-785BC657CA64%40open.ac.uk.
For more options, visit https://groups.google.com/d/optout.