Linked Open Research Cloud

Identifier
https://linkedresearch.org/cloud
Published
Modified
Notifications Inbox
inbox/
License
CC0 1.0 Universal

About

There is an abundance of scientific information on the Web. However, humans and machines have restricted access, are required to pay, or hindered to efficiently discover relations. The knowledge industry can better address societal challenges by embracing the virtues of the Web via decentralisation and interconnectivity of our collective knowledge.

The Linked Open Research Cloud (LORC) project aims to increase the awareness, discovery, and reuse of resources about scholarly communication on the Web in the form of open Linked Data. It pursues this by accepting notifications about scholarly activities, making them available for reuse, and generates an interactive visualisation for additional exploration. Consequently, LORC can assist researchers with their applications to discover pertinent scholarly information on the Web, and connect their knowledge with the global knowledge graph. For the wider scientific community, LORC can facilitate scientometrics studies and decision making based on the scholarly commons ecosystem.

To this end, this article announces its inbox to receive Linked Data Notifications (LDN) about scholarly activities, eg. publication of scholarly articles, Web Annotations (like peer reviews, replies), citations, call for contributions, proceedings, scientific observations and workflows, arguments, funding information etc. With a system like LORC, universal scientific knowledge can be better connected, findable, and accessible, with the potential to amplify its effectiveness and efficiency.


Keywords

Graph

Linked Open Research Cloud

Note

We have just started. Making the LORC look comprehensible is an ongoing work. If you would like to make your ideas tangible, please get involved!

Notifications

LORC uses the Linked Data Notifications protocol to receive and serve notifications about scholarly resources, so that they can be discovered and consumed by different applications. The visualisation in this article is dynamically constructed (with JavaScript and SVG) by consuming the notifications in LORC’s Inbox. For LORC, notifications only need to refer to complete works and activities. Different applications can discover and get the contents of the Inbox, where each notification has an HTTP URL with its content represented in RDF.

Conformance
The key words "MUST", "SHOULD", "MAY" in this document are to be interpreted as described in RFC2119.

The requirements for a notification to be included in LORC’s Inbox and the graph are as follows:

  • A notification MUST conform to one of the specified data shapes.
  • A notification MUST refer to resources that implement the Linked Data design principles.
  • A notification MUST refer to resources that are accessible to anyone free of charge.

Notification payload

  • A notification’s payload MUST be serialized as either HTML+RDFa, JSON-LD, or Turtle, and use text/html or application/xhtml+xml, application/ld+json, text/turtle media types respectively in the HTTP Content-Type header.
  • A notification MUST use a CC0 1.0 Universal license.

Note

Note that the LDN protocol requires JSON-LD as baseline, and encourages content-negotiation with the server for the other serializations. In addition to JSON-LD, LORC’s Inbox also accepts HTML+RDFa and Turtle serializations. Sender applications that wants to provide both human and machine-readable serialization may want to use HTML+RDFa.

Notification data shape

In this section the data shapes for the following notifications are provided:

In addition to the required data shapes, notifications can include anything else that may help with its reuse and the discovery of the resources it refers to. This does not mean that the body of the referred resources should be copied here.

Article data shape

MUST include:

<>
  a as:Announce ;
  as:updated "2017-09-05T21:11:58.611Z"^^xsd:dateTime ;
  schema:license <https://creativecommons.org/publicdomain/zero/1.0/> ;
  as:object <http://csarven.ca/dokieli-rww> .

<http://csarven.ca/dokieli-rww>
  a schema:ScholarlyArticle .
  • The subject URI of the as:Announce is not explicitly declared (<>) because eventually it will be parsed as the notification’s URL.
  • A valid xsd:dateTime is expected for as:updated.
  • CC0 1.0 Universal license is expected.
  • The value of as:object is the primary object of the announce, ie. the article.
  • A class along the lines of schema:ScholarlyArticle, sioc:Post, foaf:Document, biblio:Paper, bibo:Document, as:Article.

SHOULD include:

<>
  as:actor <http://csarven.ca/#i> .

<http://csarven.ca/dokieli-rww>
  schema:license <https://creativecommons.org/licenses/by/4.0/> .
  • as:actor is the URI of the agent that sent the notification.
  • URI of an open/free culture license on the article is expected.

Note

The property for the license would normally match that of what is in article, hence it is not enforced here. Senders may want to use eg. schema:license, dcterms:license, cc:license, doap:license.

Annotation data shape

MUST include:

<>
  a as:Announce ;
  as:updated "2017-09-05T21:11:58.611Z"^^xsd:dateTime ;
  schema:license <https://creativecommons.org/publicdomain/zero/1.0/> ;
  as:object <http://example.org/annotation> .
  as:target <http://example.net/article#introduction> .

<http://example.org/annotation>
  a oa:Annotation ;
  oa:motivation oa:assessing .
  • The subject URI of the as:Announce is not explicitly declared (<>) because eventually it will be parsed as the notification’s URL.
  • A valid xsd:dateTime is expected for as:updated.
  • CC0 1.0 Universal license is expected.
  • The value of as:object is the primary object of the announce, ie. the annotation.
  • The value of as:target is the target of the announce, ie. the annotated object.
  • oa:Annotation to indicate that the primary object is an annotation.
  • oa:motivation for the motivation of the annotation eg. assessment, a peer review.

SHOULD include:

<>
  as:actor <http://csarven.ca/#i> .

<http://example.org/annotation>
  schema:license <https://creativecommons.org/licenses/by/4.0/> .
  • as:actor is the URI of the agent that sent the notification.
  • URI of an open/free culture license on the annotation is expected.

Note

The property for the license would normally match that of what is in the article, hence it is not enforced here. Senders may want to use eg. schema:license, dcterms:license, cc:license, doap:license.

Citation data shape

MUST include:

<http://example.org/article#argument>
  cito:citesAsEvidence <http://example.net/observation#results> .
  • Inherit article data shape’s MUSTs with the exception that the citing entity, eg. http://example.org/article#argument can be an instance of any class.
  • The citing entity cites the cited entity in a specific or general way eg. cito:citesAsEvidence, schema:citation.

Note

In order to foster better discovery, senders may want to use terms from the Citation Typing Ontology (CiTO) or schema.org’s citation property. Alternative citation properties are only permitted if they are mentioned in this section.

SHOULD include:

Sending notifications

Notifications can be sent to LORC’s Inbox in different ways:

  • A typical LDN sender discovers the inbox of a target resource, eg. this article, so that the inbox URL is not hardcoded in sender’s application. There are conforming LDN sender applications which you can use to send notifications, or you are welcome to use your own.
  • Sending notifications directly into this article’s inbox (see the object of the ldp:inbox relation) is still welcome. For example, using curl it can be sent with curl -i -X POST -H'Content-Type: text/html' https://linkedresearch.org/inbox/linkedresearch.org/cloud/ --data-raw 'Replace this with your HTML+RDFa payload'. If the response is HTTP/1.1 201 Created you are good to go. The HTTP Location header value is where the notification can be dereferenced from. See more examples at Call for Linked Research and use LORC’s Inbox; https://linkedresearch.org/inbox/linkedresearch.org/cloud/, for the request URL.
  • If you are using tools like dokieli, notifications can be sent to LORC with the click of a button. To send a notification about the article, use the Share feature (from menu) and enter https://linkedresearch.org/cloud in the To field. Annotations and citations are soon to be automatic.

You have some questions, so here are some answers:

What about the LOD Cloud?
LORC puts emphasis on a the scholarly domain with its own requirements. If the LOD Cloud wants to incorporate LORC, there are no constraints from this end.
You tell us 😉 LORC focuses on building the scholarly graph from the ground-level, ie. individuals, groups or labs taking the initiative. LORC is aimed to be composed of mentions of original Linked Data resources available in full and free of charge. For example, metadata of an article, citations of content with restricted access, or simply desktop/print-centric resources, would not qualify. Hence, if the works are not available in the wild or part of the commons, then they do not exist as far as LORC is concerned.
What is the license of the visualisation?
The LORC visualisation uses the CC0 1.0 Universal license.
Will notifications be modified?
We have no reason to alter a notification as long as it meets the requirements of a notification data shape.
How do you verify if a resource is accessible or free of charge?
At this time, there is no automatic verification system to check this criteria. However, if we find out that it does not meet the criteria, it will be removed.
What can you say about data quality?
Notifications are just what they say they are. What matters are the resources the notifications refer to. If for example a citation notification does not exist at source (or never intended to), the notification will be eventually removed. Anyone can say anything about anything: consumers of the notifications are encouraged to verify the claims in the notifications for themselves.
Isn’t LORC a form of centralisation?
Of course it is. This is also a tangible solution, if anything, an experiment to understand the boundaries of what is possible. LORC should be seen as an instance of a service where it collects scholarly notifications. Scholarly communities are encouraged to create their own instances. We can talk about federation and distribution when we get there. If you have ideas on how to decentralise and do all this better, voice yourself and roll up your sleeves.
Can I say, ask or do something?
You are invited to join the public chat or raise an issue.