I am Sarven Capadisli, and this website contains a collection of my thoughts and interests. en-ca Copyright 2018 Sarven Capadisli http://csarven.ca/ info@csarven.ca (http://csarven.ca/#i) Fri, 29 Sep 2017 00:00:00 <h1 property="schema:name">Linked Specifications, Test Suites, and Implementation Reports</h1> <div id="authors"> <dl id="author-name"> <dt>Authors</dt> <dd id="Sarven-Capadisli" inlist="" rel="bibo:authorList" resource="http://csarven.ca/#i"><span about="" rel="schema:creator schema:publisher schema:author"><a about="http://csarven.ca/#i" href="http://csarven.ca/" property="schema:name" rel="schema:url" typeof="schema:Person"><span about="http://csarven.ca/#i"><span property="schema:givenName">Sarven</span> <span property="schema:familyName">Capadisli</span></span></a></span>^✊</dd> </dl> </div> <dl id="document-identifier"> <dt>Identifier</dt> <dd><a href="http://csarven.ca/linked-specifications-reports" rel="owl:sameAs">http://csarven.ca/linked-specifications-reports</a></dd> </dl> <dl id="document-in-reply-to"> <dt>In Reply To</dt> <dd><a href="https://linkedresearch.org/calls" rel="as:inReplyTo">Call for Linked Research</a></dd> <dd><a href="https://www2018.thewebconf.org/call-for-papers/developers-track-cfp/" rel="as:inReplyTo">CFP for Developers’ track, The Web Conf 2018</a></dd> </dl> <dl id="document-inbox"> <dt>Notifications Inbox</dt> <dd><a href="https://linkedresearch.org/inbox/csarven.ca/linked-specifications-reports/" rel="ldp:inbox">https://linkedresearch.org/inbox/csarven.ca/linked-specifications-reports/</a></dd> </dl> <dl id="document-annotation-service"> <dt>Annotation Service</dt> <dd><a href="https://linkedresearch.org/annotation/csarven.ca/linked-specifications-reports/" rel="oa:annotationService">https://linkedresearch.org/annotation/csarven.ca/linked-specifications-reports/</a></dd> </dl> <dl id="document-published"> <dt>Published</dt> <dd><time content="2017-09-29T00:00:00Z" datatype="xsd:dateTime" datetime="2017-09-29T00:00:00Z" property="schema:datePublished">2017-09-29</time></dd> </dl> <dl id="document-modified"> <dt>Modified</dt> <dd><time content="2018-01-15T00:00:00Z" datatype="xsd:dateTime" datetime="2018-01-15T00:00:00Z" property="schema:dateModified">2018-01-15</time></dd> </dl> <dl id="document-license"> <dt>License</dt> <dd><a href="https://creativecommons.org/licenses/by/4.0/" rel="schema:license" title="Creative Commons Attribution 4.0 Unported">CC BY 4.0</a></dd> </dl> <div id="content" datatype="rdf:HTML" property="schema:description"> <section id="abstract"> <h2 property="schema:name">Abstract</h2> <div datatype="rdf:HTML" property="schema:abstract"> <p>This article describes the semantic structure and linking of the W3C Recommendation <cite><a href="https://www.w3.org/TR/ldn/">Linked Data Notifications</a></cite> (LDN), its test suite, and implementation reports.</p> <p>Semantically interlinking and detailed machine-readability of components related to Web standards and their implementations is novel, and can be useful for coherently documenting software projects and their conformance with specifications. Everything presented here is open source and reusable by other specifications (W3C standards or not), test suites, and implementations.</p> <p>As a concrete example of the benefits of this approach, the LDN test suite is itself an LDN implementation for the purpose of automating the collection and aggregation of implementation reports which were used directly towards the formal standardisation process.</p> </div> </section> <section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction"> <h2 property="schema:name" resource="#introduction" typeof="#introduction">Introduction</h2> <div datatype="rdf:HTML" property="schema:description"> <p>A technical specification describes a set of requirements for a technology, for example data models, protocols, and application behaviour. The W3C publishes <q>Technical Reports</q> — also known as <q>specifications</q> and sometimes called <q>standards</q> once they are widely adopted. These documents are intended to help different (current or future) implementations to have common core functionality and quality, comply with accessibility and internationalisation guidelines, and take security and privacy considerations into account. When an application, for instance, implements a specification, it can be checked against that specification’s conformance criteria for normative requirements. Specifications are typically accompanied with test suites to assist implementations to identify their conformance level as well as areas for improvement. Similarly, reports and feedback help specifications to improve and advance towards publication. Thus, a specification and conforming implementations are integral to ensuring valid and interoperable applications. In the context of the Web, specifications enable discoverability of data and services, data exchange, and predictability of side effects of certain requests.</p> <p>In the wild, specifications and implementation reports are human-readable documents, and commonly the information within them is not machine-readable, at least from the perspective of exposing <cite>Linked Data</cite> on the Web. That is, there is a lack of globally identifiable and discoverable structured data in these documents, and they are not well linked to one another or to other resources on the Web; a machine consumer cannot reliably conduct a <q>follow your nose</q> type of exploration, or provide search mechanisms without considerable customisation per resource. There are HTML templates for specifications which facilitate embedding of some structured data, but they tend to describe items like document level sectioning, references, contributors, or metadata. On the other hand, information on each <em>specification requirement</em> and <em>conformance classifications</em> remain as unstructured prose, or at least geared towards human consumption.</p> <p>As for implementation reports, there is even less consistency across the board on how these documents are represented and accessed, let alone any definitive methods for data exchange or information retrieval.</p> <p>Having the specifications and implementation reports appropriately interlinked and retrievable can facilitate their automated discovery and reuse. One attainable use case is to be able to find applications that match a certain conformance criteria, eg. in order to have fine-grained bundling of software packages. While this would typically include normative requirements, tests can potentially capture and reveal optional features of specifications. Prospective consumers of the compliance reports can be application developers finding appropriate software for use, as well as automatic software package managers.</p> <p>This article describes the development of an interlinked, machine-readable W3C Recommendation, its test suite, and implementation reports as a whole. The W3C specification in question is <cite><a href="https://www.w3.org/TR/ldn/" rel="cito:citesAsEvidence cito:citesAsAuthority">Linked Data Notifications</a></cite> (<abbr title="Linked Data Notifications">LDN</abbr>). The associated automated <cite><a href="https://linkedresearch.org/ldn/tests/" rel="cito:citesAsEvidence">test suite</a></cite> covers each requirement of the specification with individual tests, and the test suite documentation is semantically linked with the specification itself accordingly. Once the tests have been run, the test suite generates a similarly linked implementation report. This report is submitted using LDN itself as the notification mechanism (more on this later). The listing of implementation reports (software conforming to the specification) is thus automatically updated. <a href="http://csarven.ca/linked-specifications-reports#figure-linked-specifications-reports">Figure 1</a> depicts an overview of linking the LDN specification, its test suite, the generated implementation report for the dokieli project, reports summary, and an article citing the specification.</p> <figure id="figure-linked-specifications-reports" rel="schema:hasPart" resource="#figure-linked-specifications-reports"> <object data="http://csarven.ca/media/images/articles/linked-specifications-reports.svg" height="427" rel="schema:image" type="image/svg+xml" width="640"></object> <figcaption property="schema:name">An overview of linking a specification, test suite, generated implementation report for the project, reports summary, and an article citing the specification</figcaption> </figure> <p>The information patterns discussed in the <a href="http://csarven.ca/linked-specifications-reports#specification">specification</a> and the <a href="http://csarven.ca/linked-specifications-reports#implementation-reports">implementation reports</a> sections should be reusable across other specifications and related components. Sources are available from:</p> <ul> <li>The specification: <a href="https://www.w3.org/TR/ldn/">https://www.w3.org/TR/ldn/</a></li> <li>The test suite: <a href="https://linkedresearch.org/ldn/tests/">https://linkedresearch.org/ldn/tests/</a></li> <li>Implementation reports summary and individual reports: <a href="https://linkedresearch.org/ldn/tests/summary">https://linkedresearch.org/ldn/tests/summary</a></li> </ul> <p>The test suite uses <em>mayktso</em> (<a href="https://github.com/csarven/mayktso">https://github.com/csarven/mayktso</a>) as the LDN receiver, but any conformant receiver implementation will work here.</p> <p>The prefixes and namespaces that are used in this article are listed under the <a href="http://csarven.ca/linked-specifications-reports#document-convention">document convention</a> section.</p> </div> </section> <section id="related-work" inlist="" rel="schema:hasPart" resource="#related-work"> <h2 property="schema:name" resource="#discussion" typeof="deo:RelatedWork">Related Work</h2> <div datatype="rdf:HTML" property="schema:description"> <p>Our approach uses existing standards and best practices throughout. Here we have a look at some work relevant to obtaining human and machine-readable specifications and test reports.</p> <dl> <dt id="generation-of-technical-reports">Generation of technical reports</dt> <dd><cite><a href="https://github.com/w3c/respec" rel="cito:citesAsAuthority">ReSpec</a></cite> is a tool for creating technical documents and web standards in HTML(+RDFa) that is commonly used for W3C specifications. There are also various <cite><a href="https://www.rfc-editor.org/pubprocess/tools/" rel="cito:discusses">tools for creating Internet Drafts</a></cite> and publishing them as <abbr title="Request For Comments">RFCs</abbr>, eg. at IETF, IANA. These approaches allow document authors to include structured data eg. in XML, JSON(-LD), in addition to text in prose as input before converting the source format to HTML.</dd> <dt id="generation-of-vocabularies">Generation of vocabularies</dt> <dd>Web standards often take the form of vocabularies. Some tools to generate the human-readable version of a vocabulary may also include some semantic markup. <a href="https://github.com/dgarijo/Widoco" rel="cito:discusses">Widoco</a> (<cite><a href="http://dgarijo.com/papers/widoco-iswc2017.pdf" rel="cito:citesAsAuthority">A Wizard for Documenting Ontologies</a></cite>) and <a href="http://www.essepuntato.it/lode/" rel="cito:discusses">LODE</a> (<cite><a href="http://speroni.web.cs.unibo.it/publications/peroni-2012-live-documentation-environment.pdf" rel="cito:citesAsAuthority">Live OWL Documentation Environment</a></cite>) focus on describing vocabularies and ontologies, and HTML output. The W3C <cite><a href="https://www.w3.org/TR/prov-o/" rel="cito:citesAsAuthority">PROV Ontology</a></cite>’s term definitions was generated using <a href="https://github.com/timrdf/prov-lodspeakr" rel="cito:discusses">prov-lodspeakr</a> — input being an RDF Turtle with OWL annotations, and the output of HTML sections that was integrated into the specification.</dd> <dt id="generation-of-implementation-reports">Generation of implementation reports</dt> <dd>The W3C SPARQL 1.1’s Service Description <a href="https://www.w3.org/2009/sparql/docs/tests/" rel="cito:citesAsAuthority">testing process</a> generates implementation reports in RDF/XML and Turtle using the <cite>EARL</cite> vocabulary.</dd> <dd>The <cite><a href="https://www.w3.org/TR/shacl/" rel="cito:citesAsAuthority">Shapes Constraint Language</a></cite> (<abbr title="Shapes Constraint Language">SHACL</abbr>) has a <a href="http://w3c.github.io/data-shapes/data-shapes-test-suite/" rel="cito:discusses">test suite and implementation report</a> HTML document (using ReSpec) that defines the format and process of the tests. It refers to individual test reports in Turtle as data dumps accessible from GitHub.</dd> <dd>Most closely related to the work described in this article is the W3C <cite><a href="http://rdfa.info/earl-reports/index.html" rel="cito:citesAsAuthority">RDFa 1.1 Processor Conformance</a></cite> that makes EARL reports from test suite available in HTML+RDFa, and alternatively in Turtle and JSON-LD. The tests however reference criteria URIs that do not exist; neither part of the summary document or in the <cite><a href="https://www.w3.org/TR/rdfa-core/" rel="cito:citesAsAuthority">RDFa Core 1.1</a></cite> specification. The same approach is taken in the <cite><a href="https://json-ld.org/test-suite/reports/" rel="cito:discusses">JSON-LD Implementation Report</a></cite>.</dd> </dl> <p>All of these approaches have and do work well in their respective areas, as well as meeting their target user’s needs. The missing connection among them is that a uniform resource discovery is not possible between the test reports and the individual conformance criteria in the specifications, where a given information at a particular URL is both human and machine-processable.</p> <p>We next describe our approach, which links the specification and implementation reports via the test suite itself.</p> </div> </section> <section id="specification" inlist="" rel="schema:hasPart" resource="#specification"> <h2 property="schema:name">Specification</h2> <div datatype="rdf:HTML" property="schema:description"> <p id="ldn"><cite><a href="https://www.w3.org/TR/ldn">Linked Data Notifications</a></cite> (LDN) is a W3C Recommendation, published in May 2017, which defines a protocol for discovery, creation and reuse of machine-readable notifications over HTTP.</p> <p>The W3C process requires the creation of a test suite, and the submission of reports about implementations which pass any or all of the tests. The LDN editors took the liberty to both use this process to exemplify the LDN protocol itself, as well as to generate discoverable Linked Data about the specification and its implementations.</p> <p>The LDN <a href="https://www.w3.org/TR/ldn/">technical report</a> has an HTML+RDFa representation. It used existing vocabularies (as of 2017-05). The document is a type of a <code>doap:Specification</code> and it has provenance information such as:</p> <ul> <li><code>prov:wasRevisionOf</code> for the earlier version of the specification.</li> <li><code>schema:datePublished</code> for the publication date.</li> <li><code>schema:author</code> and <code>schema:contributor</code> of the document and their partial descriptions.</li> <li><code>doap:repository</code> pointing at the specification’s repository, and <code>doap:bug-database</code> for issues.</li> <li><code>rdfs:seeAlso</code> for related stuff and the test suite’s location.</li> <li><code>as:inReplyTo</code> provides some context for the specification.</li> <li><code>xhv:license</code> for license (W3C default).</li> </ul> <p>This metadata covers what is required by W3C publishing standards.</p> <p>It also has some discourse components like <code>schema:abstract</code>, <code>schema:description</code> for each section with <code>schema:name</code> for short labels, and <code>schema:hasPart</code> to relate nested sections. Some sections have specific types, eg. <code>deo:Introduction</code>, <code>deo:Acknowledgements</code>, and <code>skos:Concept</code>.</p> <p>In order to specify how the specification’s requirements are linked to from the implementation reports, we need to look at the specification as something that provides the definitions of the concepts which the implementation reports can refer to in their assertions.</p> <p>One way to define the shape of the data structure is done with the <cite><a href="https://www.w3.org/TR/vocab-data-cube" rel="cito:citesAsPotentialSolution">RDF Data Cube vocabulary</a></cite> (<abbr title="The RDF Data Cube Vocabulary">QB</abbr>), and the definitions for its components with the <cite><a href="https://www.w3.org/TR/skos-reference/" rel="cito:citesAsPotentialSolution">Simple Knowledge Organization System</a></cite> (<abbr title="Simple Knowledge Organization System">SKOS</abbr>) vocabulary. The <cite><a href="http://www.w3.org/TR/EARL10/" rel="cito:citesAsPotentialSolution">Evaluation and Report Language</a></cite> (<abbr title="Evaluation and Report Language">EARL</abbr>) vocabulary is used to describe the test results and facilitate their exchange between applications.</p> <p>The <code>qb:DataStructureDefinition</code> (<abbr title="Data Structure Definition">DSD</abbr>) describes the shape of the multi-dimensional data which will be used in the reports, and is embedded in the LDN specification. In a hypercube, the dimensions serve to identify an observation, and the measure is for the observed value. The DSD is provided in the specification so that systems familiar with the QB vocabulary can have a sense of the structure independently of the actual use of EARL in the reports. Furthermore, alternative test suites can be built reusing the same DSD.</p> <figure class="listing" id="code-ldn-dsd" rel="schema:hasPart" resource="#code-ldn-dsd"> <pre about="#code-ldn-dsd" lang="" property="schema:description" typeof="fabio:Script" xml:lang=""><code id="code-ldn-dsd-1"><a href="https://www.w3.org/TR/ldn/#data-structure-definition">ldn:data-structure-definition</a></code> <code id="code-ldn-dsd-2"> a qb:DataStructureDefinition ;</code> <code id="code-ldn-dsd-3"> qb:component</code> <code id="code-ldn-dsd-4"> [ qb:dimension <span class="highlight-earl-subject">earl:subject</span> ] ,</code> <code id="code-ldn-dsd-5"> [ qb:dimension <span class="highlight-earl-test">earl:test</span> ] ,</code> <code id="code-ldn-dsd-6"> [ qb:dimension <span class="highlight-earl-mode">earl:mode</span> ] ,</code> <code id="code-ldn-dsd-7"> [ qb:measure <span class="highlight-earl-result">earl:result</span> ] .</code></pre> <figcaption property="schema:name">A snippet of the data structure definition as defined in the LDN specification in Turtle syntax.</figcaption> </figure> <p>The 3 dimension properties of type <code>qb:DimensionProperty</code> (ie. <code>earl:subject</code>, <code>earl:test</code>, <code>earl:mode</code>), and 1 measure property is of type <code>qb:MeasureProperty</code> (ie. <code>earl:result</code>):</p> <ul> <li><code class="highlight-earl-subject">earl:subject</code> for the application that’s being tested.</li> <li><code class="highlight-earl-test">earl:test</code> for the test criterion.</li> <li><code class="highlight-earl-mode">earl:mode</code> for how the test was conducted.</li> <li><code class="highlight-earl-result">earl:result</code> for the test result.</li> </ul> <p>LDN has conformance classes for each implementation role: sender, receiver, and consumer. A <code class="highlight-skos-conceptscheme">skos:ConceptScheme</code> is defined per role, and each concept scheme <code class="highlight-skos-hastopconcept">skos:hasTopConcept</code> referring to an individual requirement as a <code class="highlight-skos-concept">skos:Concept</code>. They all have their <code class="highlight-skos-preflabel">skos:prefLabel</code> and <code class="highlight-skos-definition">skos:definition</code>, and encapsulate the human-visible text of the requirements, for example: senders are required to send the <a href="https://www.w3.org/TR/ldn/#test-sender-header-post-content-type-json-ld">payload in JSON-LD</a>.</p> <figure class="listing" id="code-ldn-tests-concepts" rel="schema:hasPart" resource="#code-ldn-tests-concepts"> <pre about="#ldn-tests-concepts" lang="" property="schema:description" typeof="fabio:Script" xml:lang=""><code id="ldn-tests-concepts-1">&lt;&gt;</code> <code id="ldn-tests-concepts-2"> schema:hasPart ldn:ldn-tests-sender .</code> <code id="ldn-tests-concepts-4"></code> <code id="ldn-tests-concepts-3">ldn:ldn-tests-sender</code> <code id="ldn-tests-concepts-5"> a <span class="highlight-skos-conceptscheme">skos:ConceptScheme</span> ;</code> <code id="ldn-tests-concepts-6"> <span class="highlight-skos-preflabel">skos:prefLabel</span> "LDN Tests Sender"@en ;</code> <code id="ldn-tests-concepts-7"> <span class="highlight-skos-hastopconcept">skos:hasTopConcept</span> <a href="https://www.w3.org/TR/ldn/#test-sender-header-post-content-type-json-ld">ldn:test-sender-header-post-content-type-json-ld</a> .</code> <code id="ldn-tests-concepts-8"></code> <code id="ldn-tests-concepts-9">ldn:test-sender-header-post-content-type-json-ld</code> <code id="ldn-tests-concepts-10"> a <span class="highlight-skos-concept">skos:Concept</span> ;</code> <code id="ldn-tests-concepts-11"> skos:topConceptOf ldn:tests-sender ;</code> <code id="ldn-tests-concepts-12"> <span class="highlight-skos-definition">skos:definition</span> "the body of the POST request MUST contain the notification payload in JSON-LD with header Content-Type: application/ld+json"@en .</code></pre> <figcaption property="schema:name">A snippet of specification requirement in Turtle syntax</figcaption> </figure> <p>Each requirement represented as a concept has an HTML <code>id</code> attribute and a URI. These URIs correspond with observations’ dimensions values in the test reports.</p> </div> </section> <section id="implementation-reports" inlist="" rel="schema:hasPart" resource="#implementation-reports"> <h2 property="schema:name">Implementation Reports</h2> <div datatype="rdf:HTML" property="schema:description"> <p>The motivation for the test suite and the generated reports is to have their information equally consumable by human and machines. The human-friendly parts typically have an HTML user interface, and so making them also machine-processable extends their reuse. We do this by incorporating the structured data for the report in the test suite itself so that a report URL can accommodate both cases. This means that the test suite frames its expressions using the EARL and QB vocabularies, resulting in reuse of globally identifiable language — this is in contrast to creating an application-centric language that is virtually disconnected from everything else.</p> <p>A test report gets generated when a tester submits the results of running the <cite><a href="https://linkedresearch.org/ldn/tests/" rel="cito:citesAsEvidence">LDN Test Suite</a></cite>. The report contains the outcome of all test criterion as multi-dimensional data for a given type of implementation (sender, receiver, consumer).</p> <figure id="figure-dokieli-ldn-implementation-report" rel="schema:hasPart" resource="#figure-dokieli-ldn-implementation-report"> <img alt="Screenshot of dokieli’s LDN implementation report and test results as a sender" src="http://csarven.ca/media/images/articles/dokieli-ldn-implementation-report.jpg" height="1000" rel="schema:image" width="640" /> <figcaption property="schema:name">Screenshot of dokieli’s LDN implementation report and test results as a sender</figcaption> </figure> <p>All reports have their own URLs, and a representation in HTML+RDFa (optionally in other RDF serialisations via content negotiation at this particular test server). See for example <cite><a href="https://dokie.li/" rel="cito:citesAsEvidence">dokieli</a></cite>’s <a href="https://linkedresearch.org/ldn/tests/reports/2c5af2f0-f832-11e6-a642-0dd857219753" rel="cito:citesAsEvidence">implementation report and test results</a> as a sender (<a href="http://csarven.ca/linked-specifications-reports#figure-dokieli-ldn-implementation-report">figure 2</a>). This provides the human-visible information, eg. what was tested and the results also in machine-readable form. The report can be seen as a dataset composed of observations based on the structure that was specified in the specification. Hence, each test report is a <code>qb:DataSet</code> (and generally equivalent in <code>as:Object</code>) where its <code>qb:structure</code> refers to <code>https://www.w3.org/TR/ldn/#data-structure-definition</code>. The dataset has <code>as:published</code> and <code>as:actor</code> for the agent that initiated the test and generated the report. The report may be accompanied with an additional <code>as:summary</code>. An example report at <a class="highlight-observation-url" href="https://linkedresearch.org/ldn/tests/reports/2c5af2f0-f832-11e6-a642-0dd857219753">https://linkedresearch.org/ldn/tests/reports/2c5af2f0-f832-11e6-a642-0dd857219753</a> has the following core information:</p> <figure class="listing" id="code-ldn-test-report" rel="schema:hasPart" resource="#code-ldn-test-report"> <pre about="#code-ldn-test-report" lang="" property="schema:description" typeof="fabio:Script" xml:lang=""><code id="code-ldn-test-report-1">&lt;&gt;</code> <code id="code-ldn-test-report-2"> a qb:DataSet ;</code> <code id="code-ldn-test-report-3"> qb:structure <a href="https://www.w3.org/TR/ldn/#data-structure-definition">ldn:data-structure-definition</a> .</code> <code id="code-ldn-test-report-4"></code> <code id="code-ldn-test-report-5">&lt;<a class="highlight-observation-url" href="https://linkedresearch.org/ldn/tests/reports/2c5af2f0-f832-11e6-a642-0dd857219753#test-sender-header-post-content-type-json-ld">https://linkedresearch.org/ldn/tests/reports/2c5af2f0-f832-11e6-a642-0dd857219753#test-sender-header-post-content-type-json-ld</a>&gt;</code> <code id="code-ldn-test-report-6"> a qb:Observation, earl:Assertion ;</code> <code id="code-ldn-test-report-7"> qb:dataSet &lt;&gt; ;</code> <code id="code-ldn-test-report-8"> <span class="highlight-earl-subject">earl:subject</span> &lt;<a class="highlight-subject-project" href="https://dokie.li">https://dokie.li/</a>&gt; ;</code> <code id="code-ldn-test-report-9"> <span class="highlight-earl-test">earl:test</span> <a href="https://www.w3.org/TR/ldn/#test-sender-header-post-content-type-json-ld">ldn:test-sender-header-post-content-type-json-ld</a> ;</code> <code id="code-ldn-test-report-10"> <span class="highlight-earl-mode">earl:mode</span> earl:automatic ;</code> <code id="code-ldn-test-report-11"> <span class="highlight-earl-result">earl:result</span> [</code> <code id="code-ldn-test-report-12"> a earl:TestResult ;</code> <code id="code-ldn-test-report-13"> <span class="highlight-earl-outcome">earl:outcome</span> earl:passed ;</code> <code id="code-ldn-test-report-14"> <span class="highlight-earl-info">earl:info</span> "&lt;code&gt;Content-Type: application/ld+json; profile=&amp;quot;http://www.w3.org/ns/anno.jsonld&amp;quot;&lt;/code&gt; received."^^rdf:HTML ] .</code></pre> <figcaption property="schema:name">A snippet of a test result dataset and an observation in Turtle syntax</figcaption> </figure> <p>The test results are provided in an HTML table, where each test is expressed as an <code>qb:Observation</code> (and equivalent <code>earl:Assertion</code>) in RDFa containing:</p> <ul> <li>a <code class="highlight-earl-subject">earl:subject</code> that refers to the URI of the application, eg. <a class="highlight-subject-project" href="https://dokie.li/">dokieli</a>, a <code>doap:Project</code> as an <a href="https://www.w3.org/TR/ldn/#ldn-sender">LDN Sender</a>.</li> <li>a <code class="highlight-earl-test">earl:test</code> with the range being one the requirements (concepts) from the specification.</li> <li>a <code class="highlight-earl-mode">earl:mode</code> referring to one of the EARL test modes that were carried out: <a href="https://www.w3.org/TR/EARL10/#automatic">automatic</a>, <a href="https://www.w3.org/TR/EARL10/#manual">manual</a>, <a href="https://www.w3.org/TR/EARL10/#semiAuto">semi-automatic</a>, <a href="https://www.w3.org/TR/EARL10/#undisclosed">undisclosed</a>, <a href="https://www.w3.org/TR/EARL10/#unknownMode">unknown</a>.</li> <li>and a <code class="highlight-earl-result">earl:result</code> that gives information on the test <code class="highlight-earl-outcome">earl:outcome</code>: <a href="https://www.w3.org/TR/EARL10-Schema/#passed">passed</a>, <a href="https://www.w3.org/TR/EARL10-Schema/#failed">failed</a>, <a href="https://www.w3.org/TR/EARL10-Schema/#inapplicable">inapplicable</a>, <a href="https://www.w3.org/TR/EARL10-Schema/#cantTell">cannot tell</a>, <a href="https://www.w3.org/TR/EARL10-Schema/#untested">untested</a>, as well as detailed <code class="highlight-earl-info">earl:info</code> about the particular experiment.</li> </ul> <p>The implementation test report has some basic information linking to the <code>doap:Project</code> with a <code>doap:name</code>, and its <code>doap:maintainer</code>.</p> <p>All of the sender, receiver, and consumer reports are available in separate aggregate tables in <cite><a href="https://linkedresearch.org/ldn/tests/summary" rel="cito:citesAsEvidence">LDN Tests Summary</a></cite>. The summary is a <code>void:Dataset</code> where each report is linked as a <code>void:subset</code>. This makes individual reports alternatively findable if the exploration starts from the summary of all test results.</p> </div> </section> <section id="usage" inlist="" rel="schema:hasPart" resource="#usage"> <h2 property="schema:name">Usage</h2> <div datatype="rdf:HTML" property="schema:description"> <p id="implementation-description">At this point we have the test reports referring to specific parts of the specification. We can continue to further extend this linked data graph with other things. One extension possibility is to describe individual implementations further by stating that they implement the specification, or parts of it. This is a relatively simple exercise of making statements about the project such that it <code>doap:implements</code> the specification: <a href="https://www.w3.org/TR/ldn/">https://www.w3.org/TR/ldn/</a>, which <code>doap:programming-language</code>s it uses, the project’s <code>doap:repository</code> and so on. For more details, see <a href="https://dokie.li/">https://dokie.li/</a> on how the DOAP vocabulary is used as well as a reference to LDN.</p> <p id="implementation-conformance">Coming from the direction of the reports, we can also precisely know the conformance level of each implementation. This is useful to deterministically know that an implementation conforms to specification’s core requirements, which is necessary for interoperability, as well as their coverage of the optional features.</p> <p id="ldn-test-suites">The LDN Tests Suite puts the LDN protocol into practice by acting as an LDN receiver implementation (based on <cite><a href="https://github.com/csarven/mayktso" rel="cito:citesAsEvidence">mayktso</a></cite>). It also acts as a sender and consumer LDN implementation. Each part of the test suite (for <a href="https://linkedresearch.org/ldn/tests/sender" rel="cito:citesAsEvidence">Senders</a>, <a href="https://linkedresearch.org/ldn/tests/receiver" rel="cito:citesAsEvidence">Receivers</a>, and <a href="https://linkedresearch.org/ldn/tests/consumer" rel="cito:citesAsEvidence">Consumers</a>) advertise an <code>ldp:inbox</code>. Upon completion of a run of the tests, the system generates the report data and sends an LDN notification to the Inbox. The payload of the notification is the full report as RDF.</p> <p id="ldn-consumers">As an LDN Consumer, the test suite generates the <a href="https://linkedresearch.org/ldn/tests/summary">summary</a> of the reports by fetching and processing Inbox contents. The notifications are aggregated automatically, and the semantics of the submitted reports are retained.</p> <p>Once the notifications are fetched from the reports Inbox, an HTML+RDFa representation (alternatively in other RDF serialisations upon content negotiation) of the response is returned for a human- and machine-readable summary. The services are decoupled; that is, an implementer may generate their report independently of the test suite, and submit it vial the standard LDN protocol. Furthermore, projects can implement their own consumers and reuse the report data generated by the test suite directly, for example to demonstrate to potential users their conformance to the LDN specification.</p> <p id="citations">An opportunity arises when the specification is available with structured data by way of having ordinary Web articles simply refer to different sections and concepts. For example, the scholarly article on <cite><a href="http://csarven.ca/linked-data-notifications" rel="cito:citesAsEvidence">Linked Data Notifications</a></cite> uses the <cite><a href="http://purl.org/spar/cito/">CiTO</a></cite> vocabulary to cite the specification with <code>cito:citesAsAuthority</code>. Another peer reviewed article, <cite><a href="http://csarven.ca/dokieli-rww" rel="cito:citesAsEvidence">Decentralised Authoring, Annotations and Notifications for a Read-Write Web with dokieli</a></cite>, contextually cites the specification with <code>cito:citesAsPotentialSolution</code> from its <a href="http://csarven.ca/dokieli-rww#architectural-overview" rel="cito:citesAsEvidence">architectural overview</a> section, as well as the LDN Test Suite with <code>cito:citesAsAuthority</code> from its <a href="http://csarven.ca/dokieli-rww#adoption" rel="cito:citesAsEvidence">adoption</a> section. This is useful in that we can have articles linked to what is already available with minimal effort. Including this article that you are currently reading and interacting with.</p> <p>The realisation here is that we have everything operating in a way that is interoperable: the specification, test suite, discovery of the reports, and academic articles, all reusing existing vocabularies.</p> </div> </section> <section id="discussion" inlist="" rel="schema:hasPart" resource="#discussion"> <h2 property="schema:name" resource="#discussion" typeof="deo:Discussion">Discussion</h2> <div datatype="rdf:HTML" property="schema:description"> <p>The work here can serve as a demonstration or a guideline on what can be achieved by similar types of specifications and test suites. EARL and QB provide the foundations to <q>connect the dots</q> in these documents for the purpose of improving quality assurance, validation, and sharing the output of a working group as structured data on the Web.</p> <p>The key takeaways are:</p> <ul> <li>Human and machine-readable documents via HTML+RDFa are feasible for specifications and implementation reports.</li> <li>The connection between EARL and the QB vocabulary is suitable for multi-dimensional data without having to define new component specifications for the data cube.</li> <li>Individual observations (test results) can be identified and discovered through contextual links in the specification, with the use of EARL and QB vocabularies.</li> <li>The LDN protocol can support the possibility to send, receive and consume notifications about the implementation reports, as well as help with their discovery and reuse.</li> <li>It is possible for other documents to refer to specific parts of the specification, test suite and reports.</li> </ul> <p>We conclude by offering some suggestions to specification editors, test suite builders, and implementers:</p> <p>Specification editors should consider taking advantage of the level of expressivity that is possible and reuse the existing human-visible content towards machine-readability.</p> <p>It requires a considerable amount of work to devise the shape of test reports, so basing the test suite on EARL and QB can simplify and streamline this process. The approach also benefits from making the reports identifiable, discoverable, exchangeable, and reusable on the Web.</p> <p>Lastly, implementations should have machine-readable descriptions, eg. at their homepages, so that the test reports can refer to them and provide the possibility to collect more detailed information about their features.</p> </div> </section> <section id="acknowledgements" inlist="" rel="schema:hasPart" resource="#acknowledgements"> <h2 property="schema:name" resource="#acknowledgements" typeof="deo:Acknowledgements">Acknowledgements</h2> <div datatype="rdf:HTML" property="schema:description"> <p>The work on the LDN specification and its test suite was done in collaboration with <a href="https://rhiaro.co.uk/#me">Amy Guy</a>. Thanks to <a href="http://mynarz.net/#jindrich">Jindřich Mynarz</a>, <a href="http://soiland-reyes.com/stian/#me">Stian Soiland-Reyes</a>, and <a href="http://www.eurecom.fr/~troncy/">Raphaël Troncy</a> for giving early feedback on this article.</p> </div> </section> <section id="document-convention" inlist="" rel="schema:hasPart" resource="#document-convention"> <h2 property="schema:name">Document Convention</h2> <div datatype="rdf:HTML" property="schema:description"> <dl> <dt><code>as</code></dt> <dd><a href="https://www.w3.org/ns/activitystreams">https://www.w3.org/ns/activitystreams#</a></dd> <dt><code>cito</code></dt> <dd><a href="http://purl.org/spar/cito/">http://purl.org/spar/cito/</a></dd> <dt><code>doap</code></dt> <dd><a href="http://usefulinc.com/ns/doap">http://usefulinc.com/ns/doap#</a></dd> <dt><code>earl</code></dt> <dd><a href="http://www.w3.org/ns/earl">http://www.w3.org/ns/earl#</a></dd> <dt><code>ldn</code></dt> <dd><a href="https://www.w3.org/TR/ldn/">https://www.w3.org/TR/ldn/#</a></dd> <dt><code>prov</code></dt> <dd><a href="http://www.w3.org/ns/prov">http://www.w3.org/ns/prov#</a></dd> <dt><code>qb</code></dt> <dd><a href="http://purl.org/linked-data/cube">http://purl.org/linked-data/cube#</a></dd> <dt><code>rdf</code></dt> <dd><a href="http://www.w3.org/1999/02/22-rdf-syntax-ns">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></dd> <dt><code>schema</code></dt> <dd><a href="http://schema.org/">http://schema.org/</a></dd> <dt><code>skos</code></dt> <dd><a href="http://www.w3.org/2004/02/skos/core">http://www.w3.org/2004/02/skos/core#</a></dd> <dt><code>void</code></dt> <dd><a href="http://rdfs.org/ns/void">http://rdfs.org/ns/void#</a></dd> <dt><code>xhv</code></dt> <dd><a href="http://www.w3.org/1999/xhtml/vocab">http://www.w3.org/1999/xhtml/vocab#</a></dd> </dl> </div> </section> </div> http://csarven.ca/linked-specifications-reports Sat, 24 Jun 2017 00:00:00 <h1 property="schema:name">i am here now</h1> <div datatype="rdf:HTML" property="schema:description"><pre>ask yourself "where am i now?" tell yourself "i am here now" ask yourself again in the future "where am i now?" tell yourself "i am here now" </pre> </div> http://csarven.ca/i-am-here-now Tue, 14 Mar 2017 00:00:00 <h1 property="schema:name">Full Article, Immediate, Permanent, Discoverable, and Accessible to Anyone Free of charge</h1> <div datatype="rdf:HTML" property="schema:description"> <p id="background">Background: We have <a href="http://csarven.ca/linked-data-notifications">an article</a> that is peer-reviewed and accepted by <a href="http://2017.eswc-conferences.org/">an academic community</a>, however we do not agree with the publisher's copyright form (essentially giving exclusive rights). Here is what we are proposing instead.</p> <p id="derived-from">This proposal is derived from <cite><a href="http://users.ecs.soton.ac.uk/harnad/Hypermail/Amsci/3224.html" rel="prov:wasDerivedFrom cito:extends">FIPATRAFTO</a></cite> by <a href="https://en.wikipedia.org/wiki/Stevan_Harnad">Stevan Harnad</a>. We think <em>discoverability</em> (e.g., something referring to the article, or findable) and to <em>anyone</em> is important.</p> <p>Your feedback and contribution to this proposed agreement (in CC0) is much welcome. You are invited to use it as a template.</p> <section id="agreement" rel="schema:hasPart" resource="#agreement"> <h2 property="schema:name">FAIPDAAF Agreement</h2> <dl> <dt>Identifier</dt> <dd>http://csarven.ca/faipdaaf#agreement</dd> </dl> <dl id="document-license"> <dt>License</dt> <dd><a href="https://creativecommons.org/publicdomain/zero/1.0/" rel="schema:license" title="Creative Commons Zero">CC0 1.0</a></dd> </dl> <dl id="concept-faipdaaf" rel="schema:hasPart" resource="#concept-faipdaaf" typeof="skos:Concept"> <dt property="skos:notation">FAIPDAAF</dt> <dd datatype="rdf:HTML" property="skos:definition">Full Article, Immediate, Permanent, Discoverable, and Accessible to Anyone Free of charge</dd> </dl> <div datatype="rdf:HTML" property="schema:description"> <p>The authors provide the contribution to <cite>Acme Corporation</cite> with the Creative Commons Attribution 4.0 International license (<a href="https://creativecommons.org/licenses/by/4.0/">https://creativecommons.org/licenses/by/4.0/</a>) under the following conditions:</p> <ul> <li>the <em>full article</em>; text and media</li> <li><em>immediately</em> and <em>permanently</em></li> <li><em>discoverable</em> and <em>accessible</em> from their services</li> <li>to <em>anyone</em> (humans and machines)</li> <li><em>free</em> of charge</li> </ul> </div> </section> </div> http://csarven.ca/faipdaaf Mon, 27 Feb 2017 00:00:00 <h1 property="schema:name">Decentralised Authoring, Annotations and Notifications for a Read-Write Web with dokieli</h1> <div id="authors"> <dl id="author-name"> <dt>Authors</dt> <dd id="Sarven-Capadisli" inlist="" rel="bibo:authorList" resource="http://csarven.ca/#i"><span about="" rel="schema:creator schema:publisher schema:author"><a about="http://csarven.ca/#i" href="http://csarven.ca/" property="schema:name" rel="schema:url" typeof="schema:Person">Sarven Capadisli</a></span>^{<a about="http://csarven.ca/#i" href="http://csarven.ca/dokieli-rww#University-of-Bonn" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">1</a>}^{<a href="http://csarven.ca/dokieli-rww#email-Sarven-Capadisli">✊</a>}</dd> <dd id="Amy-Guy" inlist="" rel="bibo:authorList" resource="https://rhiaro.co.uk/#me"><span about="" rel="schema:author"><a about="https://rhiaro.co.uk/#me" href="https://rhiaro.co.uk/" property="schema:name" rel="schema:url" typeof="schema:Person">Amy Guy</a></span>^{<a about="https://rhiaro.co.uk/#me" href="http://csarven.ca/dokieli-rww#University-of-Edinburgh" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Edinburgh">2</a>}^{<a href="http://csarven.ca/dokieli-rww#email-Amy-Guy">🐦</a>}</dd> <dd id="Ruben-Verborgh" inlist="" rel="bibo:authorList" resource="https://ruben.verborgh.org/profile/#me"><span about="" rel="schema:author"><a about="https://ruben.verborgh.org/profile/#me" href="https://ruben.verborgh.org/" property="schema:name" rel="schema:url" typeof="schema:Person">Ruben Verborgh</a></span>^{<a about="https://ruben.verborgh.org/profile/#me" href="http://csarven.ca/dokieli-rww#Ghent-University" rel="schema:memberOf" resource="http://dbpedia.org/resource/Ghent_University">3</a>}^{<a href="http://csarven.ca/dokieli-rww#email-Ruben-Verborgh">🎸</a>}</dd> <dd id="Christoph-Lange" inlist="" rel="bibo:authorList" resource="http://eis.iai.uni-bonn.de/ChristophLange"><span about="" rel="schema:author"><a about="http://eis.iai.uni-bonn.de/ChristophLange" href="https://langec.wordpress.com/about/" property="schema:name" rel="schema:url" typeof="schema:Person">Christoph Lange</a></span>^{<a about="http://eis.iai.uni-bonn.de/ChristophLange" href="http://csarven.ca/dokieli-rww#University-of-Bonn" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">1</a>}^{<a href="http://csarven.ca/dokieli-rww#email-Christoph-Lange">∫</a>}</dd> <dd id="Sören-Auer" inlist="" rel="bibo:authorList" resource="http://eis.iai.uni-bonn.de/SoerenAuer"><span about="" rel="schema:author"><a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://eis.iai.uni-bonn.de/SoerenAuer.html" property="schema:name" rel="schema:url" typeof="schema:Person">Sören Auer</a></span>^{<a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://csarven.ca/dokieli-rww#University-of-Bonn" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">1</a>}^{<a href="http://csarven.ca/dokieli-rww#email-Sören-Auer">⚛</a>}</dd> <dd id="Tim-Berners-Lee" inlist="" rel="bibo:authorList" resource="https://www.w3.org/People/Berners-Lee/card#i"><span about="" rel="schema:author"><a about="https://www.w3.org/People/Berners-Lee/card#i" href="https://www.w3.org/People/Berners-Lee/" property="schema:name" rel="schema:url" typeof="schema:Person">Tim Berners-Lee</a></span>^{<a about="https://www.w3.org/People/Berners-Lee/card#i" href="http://csarven.ca/dokieli-rww#MIT" rel="schema:memberOf" resource="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology">4</a>}^{<a href="http://csarven.ca/dokieli-rww#email-Tim-Berners-Lee">🕸</a>}</dd> </dl> <ul id="author-org"> <li id="University-of-Bonn">¹Enterprise Information Systems Department, <a about="http://dbpedia.org/resource/University_of_Bonn" href="http://uni-bonn.de/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Bonn</a>, Bonn, DE</li> <li id="University-of-Edinburgh">²School of Informatics, <a about="http://dbpedia.org/resource/University_of_Edinburgh" href="http://www.ed.ac.uk/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Edinburgh</a>, Edinburgh, UK</li> <li id="Ghent-University">³<a about="http://dbpedia.org/resource/Ghent_University" href="http://www.ugent.be/" property="schema:name" rel="schema:url" typeof="schema:Organization">Ghent University</a> – <a about="http://dbpedia.org/resource/IMEC" href="http://www.imec-int.com/" property="schema:name" rel="schema:url" typeof="schema:Organization">imec</a>, Ghent, BE</li> <li id="MIT">⁴Decentralized Information Group, CSAIL, <a about="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology" href="https://mit.edu/" property="schema:name" rel="schema:url" typeof="schema:Organization">MIT</a>, Cambridge, US</li> </ul> <ul id="author-email"> <li id="email-Sarven-Capadisli">^✊<a about="http://csarven.ca/#i" href="http://csarven.camailto:info@csarven.ca" rel="schema:email">info@csarven.ca</a></li> <li id="email-Amy-Guy">^🐦<a about="https://rhiaro.co.uk/#me" href="http://csarven.camailto:amy@rhiaro.co.uk" rel="schema:email">amy@rhiaro.co.uk</a></li> <li id="email-Ruben-Verborgh">^🎸<a about="https://ruben.verborgh.org/profile/#me" href="http://csarven.camailto:ruben.verborgh@ugent.be" rel="schema:email">ruben.verborgh@ugent.be</a></li> <li id="email-Christoph-Lange">^∫<a about="http://eis.iai.uni-bonn.de/ChristophLange" href="http://csarven.camailto:langec@cs.uni-bonn.de" rel="schema:email">langec@cs.uni-bonn.de</a></li> <li id="email-Sören-Auer">^⚛<a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://csarven.camailto:auer@cs.uni-bonn.de" rel="schema:email">auer@cs.uni-bonn.de</a></li> <li id="email-Tim-Berners-Lee">^🕸<a about="https://www.w3.org/People/Berners-Lee/card#i" href="http://csarven.camailto:timbl@w3.org" rel="schema:email">timbl@w3.org</a></li> </ul> </div> <dl id="document-identifier"> <dt>Identifier</dt> <dd><a href="http://csarven.ca/dokieli-rww" rel="owl:sameAs">http://csarven.ca/dokieli-rww</a></dd> </dl> <dl id="document-inbox"> <dt>Notifications Inbox</dt> <dd><a href="https://linkedresearch.org/inbox/csarven.ca/dokieli-rww/" rel="ldp:inbox">https://linkedresearch.org/inbox/csarven.ca/dokieli-rww/</a></dd> </dl> <dl id="document-in-reply-to"> <dt>In Reply To</dt> <dd><a href="https://linkedresearch.org/calls" rel="as:inReplyTo">Call for Linked Research</a></dd> <dd><a href="http://icwe2017.webengineering.org/#application" rel="as:inReplyTo">ICWE2017 Call for Application Papers</a></dd> </dl> <dl id="document-annotation-service"> <dt>Annotation Service</dt> <dd><a href="https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/" rel="oa:annotationService">https://linkedresearch.org/annotation/csarven.ca/dokieli-rww/</a></dd> </dl> <dl id="document-published"> <dt>Published</dt> <dd><time content="2017-02-27T00:00:00Z" datatype="xsd:dateTime" datetime="2017-02-27T00:00:00Z" property="schema:datePublished">2017-02-27</time></dd> </dl> <dl id="document-modified"> <dt>Modified</dt> <dd><time content="2017-03-12T00:00:00Z" datatype="xsd:dateTime" datetime="2017-03-12T00:00:00Z" property="schema:dateModified">2017-03-18</time></dd> </dl> <dl id="document-license"> <dt>License</dt> <dd><a href="https://creativecommons.org/licenses/by/4.0/" rel="schema:license" title="Creative Commons Attribution 4.0 Unported">CC BY 4.0</a></dd> </dl> <div id="content"> <section id="abstract"> <h2>Abstract</h2> <div datatype="rdf:HTML" property="schema:abstract"> <p>Decentralising the creation, publication, and annotation of hypertext documents provides authors with a technological guarantee for independence of any publication authority. While the Web was designed as a decentralised environment, individual authors still lack the ability to conveniently author and publish documents, and to engage in social interactions with documents of others in a truly decentralised fashion. We present <cite><a rel="cito:cites" href="https://dokie.li/">dokieli</a></cite>, a fully decentralised, browser-based authoring and annotation platform with built-in support for social interactions, through which people retain the ownership of and sovereignty over their data. The resulting “living” documents are interoperable and independent of dokieli since they follow standards and best practices, such as HTML+RDFa for a fine-grained semantic structure, <cite>Linked Data Platform</cite> for personal data storage, and <cite>Linked Data Notifications</cite> for updates. This article describes dokieli’s architecture and implementation, demonstrating advanced document authoring and interaction without a single point of control. Such an environment provides the right technological conditions for independent publication of scientific articles, news, and other works that benefit from diverse voices and open interactions.</p> </div> </section> <section id="keywords"> <h2>Keywords</h2> <div> <ul rel="schema:about"> <li><a href="https://en.wikipedia.org/wiki/Decentralization" resource="http://dbpedia.org/resource/Decentralization">Decentralisation</a></li> <li><a href="https://en.wikipedia.org/wiki/Human-computer_interaction" resource="http://dbpedia.org/resource/Human-computer_interaction">Human-computer interaction</a></li> <li><a href="https://en.wikipedia.org/wiki/Linked_Data" resource="http://dbpedia.org/resource/Linked_Data">Linked Data</a></li> <li><a href="https://en.wikipedia.org/wiki/Semantic_publishing" resource="http://dbpedia.org/resource/Semantic_publishing">Semantic publishing</a></li> <li><a href="https://en.wikipedia.org/wiki/Social_machine" resource="http://dbpedia.org/resource/Social_machine">Social machine</a></li> <li><a href="https://en.wikipedia.org/wiki/Social_web" resource="http://dbpedia.org/resource/Social_web">Social web</a></li> </ul> </div> </section> <section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction"> <h2 property="schema:name">Introduction</h2> <div datatype="rdf:HTML" property="schema:description" resource="#introduction" typeof="deo:Introduction"> <p about="" id="problem-statement" rel="schema:hasPart"><span about="#problem-statement" property="schema:description" typeof="deo:ProblemStatement">While the Web was originally conceived as a decentralised platform where every organisation and individual can participate, it became increasingly centralised with <a href="https://news.netcraft.com/archives/category/web-server-survey/">less than 1% of the servers serving more than 99% of the content</a>. The main reason for this is rooted in technology: it is currently much easier and more efficient to author, manage, publish, and search large amounts of similarly structured content using a centralised platform. Blogger, YouTube and Facebook, for example, are centralised authoring, publishing, and search platforms for blog posts, videos or social network content respectively.</span></p> <p>However, independence of centralised platforms is a necessity for ownership of published ideas, and to establish a relation of trust. For example, Facebook has been accused of <a href="http://www.slate.com/articles/technology/technology/2016/05/yes_facebook_is_biased_now_it_should_admit_it.html">bias</a>, <a href="https://www.theguardian.com/media/2016/jul/12/how-technology-disrupted-the-truth">false information</a>, and <a href="https://www.nytimes.com/2016/09/10/technology/facebook-vietnam-war-photo-nudity.html">censorship</a>—but rather than blaming this on any particular platform, we identify it as an unavoidable result of centralisation. After all, there is a continued tension between unrestricted publication rights on the one hand, and a guarantee of balanced, verified information on the other. In a fully decentralised setting, each source is filterless and responsible for its own quality and reputation, while others are free to selectively (dis-)trust certain sources using any mechanism they desire.</p> <p>Decentralised authoring, publication, and annotation furthermore have the potential to impact areas in which centralisation currently determines the pace of evolution. Scientific publishing, for instance, is often bound to centralised review and dissemination processes. Instead, rigorous scientific discourse could be realised with an open, decentralised environment for the annotation of manuscripts, which has the potential to engage more people sooner. Trust then no longer stems from a finite process with limited transparency, but is rather continuously assessed by repeated independent validation. Publication thereby becomes the starting point rather than the end point.</p> <p>If we want to strengthen the decentralised nature of the Web again, we need to develop technologies to simplify the decentralised authoring, management, exploration, and search of Web content.</p> <p>In this article we present the <a href="http://csarven.ca/dokieli-rww#principles">principles</a> and <a href="http://csarven.ca/dokieli-rww#architecture-and-technologies">architecture</a> for a fully distributed authoring and publishing system. We describe the dokieli implementation of this architecture as well as an overview on its current <a href="http://csarven.ca/dokieli-rww#adoption">adoption</a> before we conclude with an outlook on <a href="http://csarven.ca/dokieli-rww#conclusions">challenges and future work</a>.</p> </div> </section> <section id="principles" inlist="" rel="schema:hasPart" resource="#principles"> <h2 property="schema:name">Principles</h2> <div datatype="rdf:HTML" property="schema:description" resource="#principles" typeof="deo:Model"> <p>This describes the principles against which decentralised approaches for authoring, annotation and notifications should be designed. These principles are derived from current literature on decentralisation, and Web development best practices.</p> <dl> <dt id="data-storage-independent-of-service-providers">Data storage independent of service providers</dt> <dd>Users should have a choice in where they store their data and full control over it e.g. with regard to who is allowed to access it. The <cite><a href="https://www.researchgate.net/publication/299536747_Industrial_Data_Space_Digital_Souvereignity_Over_Data" rel="cito:citesAsRelated">Industrial Data Space</a></cite> initiative calls this <q>data sovereignty</q>.</dd> <dt id="interoperability">Interoperability</dt> <dd>By allowing the application logic to be decoupled from the data, users can switch between applications and personal data storage servers, thereby avoiding a <em>vendor lock-in</em>. To achieve maximum interoperability, applications should conform to well-defined Web standards and protocols (rather than properietary software implementations). Dangers of data silos and some example standards to use to decentralise are given in <cite><a href="https://www.w3.org/DesignIssues/CloudStorage.html" rel="cito:citesAsRelated">Socially-aware Cloud Storage</a></cite>.</dd> <dt id="separation-of-concerns">Separation of concerns</dt> <dd>A <em>progressive enhancement</em> strategy to connect the structural, presentational, and behavioural layers allows content and base functionality to be accessible through different media and devices (as described in <cite><a href="http://hesketh.com/publications/progressive_enhancement_and_the_future_of_web_design.html" rel="cito:citesAsRelated">Progressive Enhancement and the Future of Web Design</a></cite>).</dd> <dt id="accessibility">Accessibility</dt> <dd>To lower the barrier for entry for all forms of participation, enhanced functionality should be accessible to users based on the capabilities of their user-agents, storage availability, network access or personal preferences (we consider this to be self-evident, and there are a plethora of Web best practices in this area).</dd> <dt id="freedom-of-expression">Freedom of expression</dt> <dd>Because there are no central authorities, we must assume applications follow the open-world principle, where <q>any author can say anything about anything</q>. Identifying everything using [de]referenceable IRIs allows any distributed authoring or annotation application to reference and link to previously published content (this overlaps with Principles 1, 3 and 4 in the <cite><a href="https://www.w3.org/2001/12/semweb-fin/w3csw" rel="cito:citesAsRelated">W3C Semantic Web Activity</a></cite> charter).</dd> <dt id="web-of-trust">Web of Trust</dt> <dd>The Web as a collaborative medium makes it possible for people to take responsibility (or be accountable) for their contributions. It should be possible for people to publish, share, and annotate information while ensuring their provenance, authenticity and integrity [<cite><a href="https://pdfs.semanticscholar.org/5e37/daf945094ea9c9df127e06b05282e03e39bd.pdf" rel="cito:citesAsRelated">Weaving a Web of Trust</a></cite>, <cite><a href="https://link.springer.com/content/pdf/10.1007%2F978-3-540-39718-2_23.pdf" rel="cito:citesAsRelated">Trust Management for the Semantic Web</a></cite>, <cite><a href="http://sir-lab.usc.edu/cs586/20151readings/w13-1.pdf" rel="cito:citesAsRelated">Trust Networks on the Semantic Web</a></cite>].</dd> </dl> </div> </section> <section id="related-work" inlist="" rel="schema:hasPart" resource="#related-work"> <h2 property="schema:name">Related work</h2> <div datatype="rdf:HTML" property="schema:description" resource="#related-work" typeof="deo:RelatedWork"> <p><cite><a href="http://svn.aksw.org/papers/2011/JWS_SemanticContentAuthoring/public.pdf">User Interfaces for Semantic Authoring of Textual Content</a></cite> gives an overview on relevant related work. A range of quality attributes such as collaboration, interoperability, and scalability, while relevant to our work, we also consider systems and tools on dimensions based on the principles that we have outlined.</p> <p id="cenrtalised-autoring-and-annotation-platforms"><strong>Centralised authoring and annotation platforms</strong>: <span id="googledocs-medium-authorea"><cite><a href="https://docs.google.com/" rel="cito:discusses">Google Docs</a></cite>, <cite><a href="https://medium.com/" rel="cito:discusses">Medium</a></cite>, and <cite><a href="https://www.authorea.com/" rel="cito:discusses">Authorea</a></cite> are examples of Web applications for collaborative creation and publication of content which require account creation and data storage with respective centralised services. They allow multiple participants to annotate and hold discussions around the primary content; users must access their accounts to be notified of updates to conversations, and data from both the main content and related discussion is confined to the service which was used to create it.</span> <span id="wordpress"><cite><a href="https://wordpress.org/" rel="cito:discusses">WordPress</a></cite> is a free and open-source platform for article publication which can be self-hosted on a server controlled by the user. Visitors may sign-in with their WordPress accounts to leave comments on others’ articles, however they are typically under the hosting site’s database.</span> <span id="hypothesis"><cite><a href="https://hypothes.is/" rel="cito:discusses">Hypothesis</a></cite> makes it possible for users to leave annotations on different types of documents on the Web using a browser plugin or via a proxy. Annotations may be private or public, and can be threaded to form conversations around a piece of content. Despite allowing the attachment of annotations to resources hosted anywhere, they depend on centralised account creation and storage for the annotations themselves. Hypothesis is open source, with an API that uses Web Annotations data model, and may be self-hosted, but currently it is not possible to federate between different instances.</span> <span id="pundit"><cite><a href="http://thepund.it/" rel="cito:discusses">Pundit</a></cite> is a set of tools that allow web annotation with highlights, comments and semantic annotations. It is similar to Hypothesis in its architecture and deployment, i.e., annotations made through the pundit client require it to be saved on its corresponding annotations server.</span></p> <p id="decentralised-authoring-and-annotation-platforms"><strong>Decentralised authoring and annotation systems</strong>: <span id="libreoffice-online">Some authoring and publishing systems already go into a decentralised direction. However, they only realize a relatively small subset of the principles outlined in the last section. <cite><a href="https://github.com/libreoffice/online" rel="cito:discusses">LibreOffice Online</a></cite>, for example, allows collaborative editing of office documents (e.g., Writer) from the Web browser. Content can be stored under different CMSs in the cloud. The document’s interface consists of image tiles which are sent from the server and rendered in the browser. However, it hardly provides accessibility, rich interlinking and annotations or separations of concerns.</span> <span id="smallest-federated-wiki">The <cite><a href="http://fed.wiki.org/" rel="cito:discusses">Smallest Federated Wiki</a></cite> pages to be forked and maintain personal copies.</span> <span id="amaya"><cite><a href="https://www.w3.org/Amaya/" rel="cito:discusses">Amaya</a></cite> is a desktop Web editor application (to create and update documents) as well as a lightweight browser that was (1993) developed by W3C to provide a framework to test its technologies.</span></p> <p>The tools which provide good collaborative editing UIs appear to do so at the expense of data ownership and interoperability; those which promote creation and publication of data in open reusable formats are lacking facilities for linking discourse and conversation to concepts published. Decentralised creations also mean that each author can choose their own semantics (e.g. their own vocabulary to annotate RDF), and then such decentralised documents can link to each other and their schemas can also be mapped to each other, whereas in centralised platforms this is (if they support semantics at all) often prescribed, either technically enforced, or encouraged by social convention.</p> </div> </section> <section id="architecture-and-technologies" inlist="" rel="schema:hasPart" resource="#architecture-and-technologies"> <h2 property="schema:name">Architecture and technologies</h2> <div datatype="rdf:HTML" property="schema:description" resource="#architecture-and-technologies" typeof="deo:Contribution"> <p>In this section we discuss an architecture to bridge the gaps in existing work for a decentralised authoring and semantic annotation client-side application, which decouples itself from data and specific server requirements.</p> <section id="architectural-overview" inlist="" rel="schema:hasPart" resource="#architectural-overview"> <h3 property="schema:name">Architectural overview</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Decentralised read-write environments make it possible for different actors (e.g., authors, reviewers) to have their own personal online storages where they can: manage their data; have socially-aware access controls on the data (e.g., who gets to see and update what); send notifications based on their interactions; and permit different applications to operate on the data, including moving the data from one server to another seamlessly.</p> <p>Figure 1 depicts the contrast between typical centralised and decentralised architectures.</p> <figure id="figure-centralised-decentralised-architectures" rel="schema:hasPart" resource="#figure-centralised-decentralised-architectures"> <object rel="schema:image" data="http://csarven.ca/media/images/articles/centralised-decentralised-architectures.svg" type="image/svg+xml" width="900" height="300"></object> <figcaption property="schema:name">Typical centralised and decentralised architectures</figcaption> </figure> <p>dokieli as a client-side application can be <a href="http://csarven.ca/dokieli-rww#deployment">deployed</a> on a single-page or through a browser extension, which can consume and interact with Linked Data (or otherwise) anywhere on the Web. We consider an HTML document with CSS and JavaScript as the default UI of a document. Through the separation of the layers, other UIs can work injunction with the same HTML. This approach is independent from specific server-side software, proprietary APIs or the requirement to have an account.</p> <p>On the other hand, if desired and available, users can participate using their own profiles (WebIDs) located anywhere on the Web, and get to store and make their annotations in their own personal storage, as well as assign access controls to documents. Similarly, a decentralised communications protocol, <cite><a href="http://csarven.ca/linked-data-notifications" rel="cito:citesAsPotentialSolution">Linked Data Notifications</a></cite> (LDN) – <cite><a href="https://www.w3.org/TR/ldn/" rel="cito:citesAsAuthority">W3C Proposed Recommendation</a></cite> – is used get past the limits of centralisation by enabling communication to happen across independent servers and applications. Figure 2 depicts relations between the kinds of entities which underlay dokieli’s architecture, where nodes are under different domains and authority.</p> <figure id="figure-dokieli-architecture-relations" rel="schema:hasPart" resource="#figure-dokieli-architecture-relations"> <img alt="Entities and relations within dokieli’s architecture" rel="schema:image" src="http://csarven.ca/media/images/articles/dokieli-architecture-relations.png" width="1024" height="362" /> <figcaption property="schema:name">Entities and relations within dokieli’s architecture</figcaption> </figure> <p id="self-replicating">dokieli can <em>self-replicate</em>, in that the reader of a dokieli document can spawn an instance — either a copy or a brand new empty document — into their own storage space at the click of a button.</p> </div> </section> <section id="creating-documents" inlist="" rel="schema:hasPart" resource="#creating-documents"> <h3 property="schema:name">Creating documents</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Documents use HTML5 <cite><a href="https://www.w3.org/TR/html-polyglot/" rel="cito:citesAsAuthority">Polyglot Markup</a></cite> to ensure that when served as (X)HTML respectively, they can be processed as either HTML or XML, which is useful in XML ecosystems and toolchains. Semantics is embedded directly into human-visible prose using RDFa. The machine-readable data is thus kept in context, reusing the article’s text as literal object values, and avoiding data duplication or data ‘islands’, which can occur when other RDF serialisations are included within HTML <code>&lt;script&gt;</code> elements.</p> <p>The appearance of documents is determined with CSS3. Different stylesheets can be applied to the same HTML structure so that a document can be presented flexibly, in the most appropriate way for a particular circumstance. Stylesheets can be switched from either dokieli’s menu or through Web browser with native controls, for example from a two-column layout required by an academic journal to a design in keeping with the author’s blog.</p> <p>When JavaScript is enabled, dokieli provides a rich editing interface which includes visual and structural formatting of text as well as embedding machine-readable semantics, media, dynamic citations, and inclusion of statistical charts from live endpoints. An external personal data store, or even internet connection, are not needed at this stage as modifications to a document made in the browser this way can be persisted to a local filesystem using the dokieli menu <em>export</em> function (or the browser’s <em>save as</em>), or through brower’s native local storage.</p> </div> </section> <section id="consuming-documents" inlist="" rel="schema:hasPart" resource="#consuming-documents"> <h3 property="schema:name">Consuming documents</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="http-get">Documents can be retrieved from Web servers with a single <code>HTTP GET</code> request, by either a browser (for human-readable HTML) or script (machine-readable RDF). Through the use of progressive enhancement, document contents are available in text-only browsers, and further functionality of CSS and JavaScript are layered on according to the user agent’s abilities.</p> <p id="data-reuse">dokieli’s approach to marking human-visible content in RDFa makes it possible to further decouple itself, the application that produced the data, from the data itself, facilitating potential reuse of the data by other applications. A dokieli document can be parsed into a graph, and users can use any other RDF-aware application with the data that was generated by dokieli. Thereby, dokieli can effectively remove itself as a dependency when it comes to data consumption and reuse.</p> <p id="authentication">dokieli is able to authenticate users via WebID-TLS if they provide a WebID. This enables further functionality: the user can use dokieli to access protected resources and write to non-public data storage containers if their WebID is authorised to do so. For authenticated users leaving annotations on other documents dokieli fetches their name and display picture from their online profile if available, to display alongside their comment.</p> <p id="vocabularies">dokieli uses the following vocabularies as standard: <cite><a href="http://schema.org/" rel="cito:citesAsAuthority">schema.org</a></cite> to describe the general-purpose relations about the document as well as profiles, the <cite><a href="http://purl.org/spar" rel="cito:citesAsAuthotiy">SPAR Ontologies</a></cite> for scholarly articles and referencing, <cite><a href="http://www.w3.org/ns/oa" rel="cito:citesAsDataSource">Web Annotations</a></cite> for annotations (with motivations e.g., replying, bookmarking, commenting, assessments), <cite><a href="http://www.w3.org/ns/ldp" rel="cito:citesAsDataSource">LDP</a></cite> for personal storage management, <cite><a href="https://www.w3.org/wiki/WebAccessControl" rel="cito:citesAsPotentialSolution">WAC</a></cite>/<cite><a href="http://www.w3.org/ns/auth/acl" rel="cito:citesAsDataSource">ACL</a></cite> for access control, <cite><a href="http://www.w3.org/ns/ldp#inbox">LDN Inbox</a></cite> and <cite><a href="https://www.w3.org/ns/activitystreams" rel="cito:citesAsDataSource">ActivityStreams</a></cite> for social notifications, <cite><a href="https://creativecommons.org/ns" rel="cito:citesAsDataSource">Creative Commons</a></cite> for rights and licensing, <cite><a href="http://www.w3.org/ns/prov" rel="cito:citesAsAuthority">PROV Ontology</a></cite> for provenance (e.g., for derivations with <q>save as</q>), and the <cite><a href="https://www.w3.org/TR/vocab-data-cube/" rel="cito:citesAsAuthority">RDF Data Cube vocabulary</a></cite> to consume multi-dimensional data from SPARQL endpoints. Authors can optionally include other vocabularies to mark up specific concepts through dokieli’s UI.</p> </div> </section> <section id="publishing-documents" inlist="" rel="schema:hasPart" resource="#publishing-documents"> <h3 property="schema:name">Publishing documents</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="write-operations">Documents can of course be published on ordinary Web servers, as Web pages. The next layer of enhancement is for authors who wish to edit documents on a Web server directly rather than locally; they can make use of dokieli’s write operations. This uses JavaScript, and moves the burden of processing user input from servers (i.e., offering HTML forms and processing of the form submission) to the client where the payload uses the RDF language. Data shape verification is an orthogonal process and can be addressed through servers processing the payload based on the constraints advertised for the resource (e.g., via <code>ldp:constrainedBy</code>). In essence, dokieli behaves as a <q>smart client</q>.</p> <p id="http-put">dokieli implements the <cite><a href="https://www.w3.org/TR/ldp/" rel="cito:citesAsAuthority">Linked Data Platform</a></cite> (LDP) protocol for creating, updating and deleting documents. As such, personal data stores or servers which implement the server portion of the protocol can be used to store and edit dokieli documents directly. An <code>HTTP PUT</code> request to a URL is used to create a <em>new</em> document, to clone an existing one with <em>save as</em>, to <em>save</em> changes, and so that readers of a document can create their own document in <em>reply</em>. All of these operations are available through the dokieli menu.</p> <aside id="http-patch"> <p><code>HTTP PATCH</code> can be useful towards statement level updates, thereby simpler <em>diffs</em> between versions. dokieli currently does not use <code>HTTP PATCH</code> because servers with <cite><a href="https://tools.ietf.org/html/rfc5261" rel="cito:citesAsAuthority">XML Patch</a></cite> and mediatype <code>application/xml-patch+xml</code> (<cite><a href="https://tools.ietf.org/html/rfc7351" rel="cito:citesAsAuthority">RFC 7351</a></cite>) capability in the Linked Data ecosystem are not well supported. <code>HTTP PATCH</code> with <cite><a href="https://www.w3.org/TR/sparql11-update/" rel="cito:citesAsAuthority">SPARQL Update</a></cite> (using mediatype <code>application/sparql-update</code>) is an important and effective alternative towards statement level updates. XML Patch however may be more appropriate for HTML+RDFa based documents since it would not require servers to have an HTML+RDFa serializer, whereas the SPARQL Update requires the servers preprocess, and then may eventually need to store a particular serialization in the case of flat filesystem writes. This is not a concern when writing to RDF stores.</p> </aside> </div> </section> <section id="social-interactions-and-annotations" inlist="" rel="schema:hasPart" resource="#social-interactions-and-annotations"> <h3 property="schema:name">Social interactions and annotations</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="http-post">Interactions with a document with respect to Web Annotations include the following motivations: replying, describing (e.g., footnotes), commenting, assessing (e.g., approvals, disapprovals, and request for specificity used towards peer-reviews), bookmarking, and tagging. They can be about the document as a whole, or of a selection of text. In both cases, the dokieli menu presents an input to the annotator, along with a choice of license which they can assign to their contributions. dokieli then adds semantic markup based on all of the input, and then sends the data off for appropriate storage so it can be retrieved and re-displayed on future document loads. These write operation requests are made with <code>HTTP POST</code>.</p> <p id="http-delete">Document authors can point to a storage service (using the Web Annotations <code>annotationService</code> property) which lets readers without their own personal storage comment nonetheless. Readers who have a preferred storage location against which they can authenticate are able to direct dokieli to store their input there instead (or in addition). dokieli allows users to remove their annotations, where an <code>HTTP DELETE</code> request is made to the server. In this way, dokieli does not impose a centralised mechanism for social interactions, and allows users to effectively ‘own’ their comments, annotations, and reviews, in their own space.</p> </div> </section> <section id="notifications" inlist="" rel="schema:hasPart" resource="#notifications"> <h3 property="schema:name">Notifications</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="linked-data-notifications">When readers interact with a document, the author is notified by means of the <cite><a href="https://www.w3.org/TR/ldn/">Linked Data Notifications</a></cite> (LDN) protocol. A notification, composed of the data from the interaction or annotation, is sent to the <em>inbox</em> advertised by the document or arbitrary parts, thereof. This inbox may be on the same server as the document itself, or may be elsewhere. dokieli subsequently reads this inbox to display interactions and annotations on the document.</p> <p id="control-of-contributions">Authors of documents who have write-access to its inbox can remove notifications for interactions they find inappropriate, <em>without</em> needing to worry about their inability to access the original source of the interaction. Similarly, if they do not have access to the inbox, they may assign an alternative inbox for the article (or its parts). Conversely, annotators do not lose control or authority over their contributions, even if the object of their interaction wishes to disassociate itself. Each contributor retains their own respective rights over the entities they create on the Web.</p> </div> </section> </div> </section> <section id="implementation" inlist="" rel="schema:hasPart" resource="#implementation"> <h2 property="schema:name">Implementation</h2> <div datatype="rdf:HTML" property="schema:description" resource="#implementation" typeof="deo:Results"> <p>dokieli is open source: <a href="https://github.com/linkeddata/dokieli">https://github.com/linkeddata/dokieli</a> and available to try at <a href="https://dokie.li/">https://dokie.li/</a> (or at any instance on the Web, see <cite><a href="http://csarven.ca/dokieli-rww#adoption">Adoption</a></cite>).</p> <section id="components" inlist="" rel="schema:hasPart" resource="#components"> <h3 property="schema:name">Components</h3> <div datatype="rdf:HTML" property="schema:description"> <p>dokieli’s components include <strong>data</strong> (for structure and semantics), <strong>stylesheets</strong> (for presentation) and <strong>scripts</strong> (for interaction). All data (articles, annotations, notifications) are represented in HTML and RDF with vocabularies expressing the underlying content, resources are <em>self-descriptive</em> to increase their reuse, and contain relations to related external resources to foster <em>follow-your-nose</em> type of exploration.</p> <p>Several stylesheets provide alternative views for consumption (e.g., stylesheets for different media: screens, print, slideshow). dokieli’s JavaScript includes: a library for editing (<cite><a href="https://github.com/yabwe/medium-editor">MediumEditor</a></cite>) in its <em>authoring environment</em>; features to <em>fetch and display statistical data</em> from SPARQL endpoints (<cite><a href="http://csarven.ca/sparqlines-sparql-to-sparkline">Sparqlines</a></cite>); retrieval of profile information, as well as means to <em>sign in</em> with <cite><a href="https://www.w3.org/2005/Incubator/webid/spec/tls/">WebID Authentication over TLS</a></cite>; functionality for write-operations, which includes checking <em>authorisation</em> against access-control level settings on the server with the authenticated user’s WebID and personal certificate; creation and consumption of <cite><a href="https://www.w3.org/TR/annotation-model/">Web Annotations</a></cite> and <cite><a href="https://www.w3.org/TR/ldn/">Linked Data Notifications</a></cite>; and fetching information from remote articles when adding a citation.</p> <p id="scope">The scope of dokieli includes documents and the interactions around them. The creation and maintenance of user profiles, personal storage spaces, and access control rules are not managed by dokieli; since they are all standard mechanisms, users are expected to be able to accomplish this using other specialised applications.</p> </div> </section> <section id="deployment" inlist="" rel="schema:hasPart" resource="#deployment"> <h3 property="schema:name">Deployment</h3> <div datatype="rdf:HTML" property="schema:description"> <p>dokieli employs two complementary deployment approaches: <em>single-page application</em> and <em>Web browser extension</em>.</p> <p id="single-page-application">dokieli’s presentational and behavioural code layers can be included in Web pages in order to trigger them as active single-page applications. It is a smart client that allows different kinds of articles e.g., academic, blog posts, news, to be authored and annotated from within Web browsers, without necessarily having them deployed from a server, i.e., it can be used offline or on localhost. dokieli internally handles its content and well-formed structural and semantic representation based on user’s interactivity. Articles, profiles and their contact information, notifications, annotations with different motivations, for instance, can be read and written ubiquitously to any Web space with supporting HTTP methods and access control mechanisms.</p> <p id="web-browser-extension">The Web browser extension is a thin wrapper around dokieli’s core code in order to embed itself in any HTML-based Web page on the Web. It inherits all of the features of a single-page application. While HTML based documents on the Web vary in their quality, dokieli’s write operations generate well-formed HTML+RDFa. One of the primary utilities for the extension is to have a consistent interface for annotating (comment, bookmark, like) any text selection on a Web page, as well as sharing parts of pages with ones contacts via notifications, without having a service dependency or being limited by the Web page’s UI.</p> </div> </section> <section id="interactions" inlist="" rel="schema:hasPart" resource="#interactions"> <h3>Interactions</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Screencasts for the following use-cases showcase dokieli’s social features where users interact by creating and sharing information, available at https://dokie.li/</p> <!-- <div class="figure-column-2"> --> <figure id="figure-dokieli-annotation" inlist="" rel="schema:hasPart" resource="#figure-dokieli-annotation"> <video controls="controls" id="video-dokieli-annotation" inlist="" poster="https://dokie.li/media/images/dokieli-annotation.jpg" preload="none" rel="schema:hasPart" width="800"> <source about="#video-dokieli-annotation" rel="schema:hasPart" resource="https://dokie.li/media/video/dokieli-annotation.webm" src="https://dokie.li/media/video/dokieli-annotation.webm" type="video/webm" typeof="fabio:Film" /> </video> <figcaption property="schema:name"><a href="https://dokie.li/media/video/dokieli-annotation.webm">Video</a> of dokieli Web Annotation</figcaption> </figure> <!-- </div> --> <p id="annotations"><strong>Annotations</strong>: A core feature to facilitate collaboration is the possibility to annotate arbitrary parts of a Web document (e.g., <cite><a href="https://www.w3.org/TR/dpub-annotation-uc/">Digital Publishing Annotation Use Cases</a></cite>). Users can select an entity or a span of text of interest, a context menu is presented to input their annotations along with the choice to select a license for their contribution. If the user is signed-in with their WebID, and provided they have a personal storage space, dokieli discovers this through their online profile and saves the annotations to that location. Once the annotation is submitted by the user, dokieli proceeds with three operations: 1) the annotation is requested to be saved at the user’s personal storage, and if it is access controlled, the user will be prompted to authenticate themselves against that server, before the annotation is saved and is assigned its own URL, 2) if the article or any identifiable statement or segment has its own inbox, dokieli sends a notification to the inbox indicating that an annotation was made and where its retrievable location is, with accompanying metadata like who created it, date, its license etc., 3) the annotation is fetched from its canonical location, and integrated into the article e.g., in marginalia. If the article has a reference to a public annotation service (a writeable space adhering to <cite><a href="https://www.w3.org/TR/annotation-protocol/">Web Annotation Protocol</a></cite>), the user has the option to send a copy of the annotation there as well. In cases where the user does not want to have the canonical copy of the annotation on their server, or if a user does not have write access to a storage, they can still use this option to engage with the article.</p> <figure id="figure-dokieli-share" inlist="" rel="schema:hasPart" resource="#figure-dokieli-share"> <video controls="controls" id="video-dokieli-share" poster="https://dokie.li/media/images/dokieli-share.jpg" preload="none" rel="schema:hasPart" width="800"> <source about="#video-dokieli-share" rel="schema:hasPart" resource="https://dokie.li/media/video/dokieli-share.webm" src="https://dokie.li/media/video/dokieli-share.webm" type="video/webm" typeof="fabio:Film" /> </video> <figcaption property="schema:name"><a href="https://dokie.li/media/video/dokieli-share.webm">Video</a> of dokieli Share</figcaption> </figure> <p id="sharing"><strong>Social Sharing</strong>: A key aspect of the Social Web is sharing with others. After (optionally) authenticating with a WebID, dokieli documents can be shared with contacts, which are discovered from the user’s WebID profile. Contacts whose profiles advertise an LDN Inbox will receive a notification of the share. The notification contains Activity Streams 2.0 vocabulary terms, and recipients can use any LDN-compatible application to view the notification, without needing to have ever used dokieli before.</p> <!-- <div class="figure-column-2"> --> <figure id="figure-dokieli-citation" inlist="" rel="schema:hasPart" resource="#figure-dokieli-citation"> <video about="" controls="controls" id="video-dokieli-citation" poster="https://dokie.li/media/images/dokieli-citation.jpg" preload="none" rel="schema:hasPart" width="800"> <source about="#video-dokieli-citation" rel="schema:hasPart" resource="https://dokie.li/media/video/dokieli-citation.webm" src="https://dokie.li/media/video/dokieli-citation.webm" type="video/webm" typeof="fabio:Film" /> </video> <figcaption property="schema:name"><a href="https://dokie.li/media/video/dokieli-citation.webm">Video</a> of semantic inline citations</figcaption> </figure> <!-- </div> --> <p id="inline-citations"><strong>Inline Citations</strong>: Rich semantic links can also be established between dokieli documents themselves. The author selects a text fragment and inserts the URL of the document to be linked to as well as a semantic link type (e.g. <q>agrees with</q>, <q>confirms</q>, <q>cites as evidence</q>) from the CiTO and schema.org ontologies. dokieli automatically retrieves metadata (e.g. title, authors) from the linked document and adds a proper scientific endnote reference. If the cited article advertises its won LDN inbox, a notification of the citation is sent as well, thus allowing bi-directional linking.</p> <figure id="figure-dokieli-sparqlines" rel="schema:hasPart" resource="#figure-dokieli-sparqlines"> <video about="" controls="controls" id="video-dokieli-sparqlines" poster="https://dokie.li/media/images/GDP-per-capita-growth--annual---.svg" preload="none" rel="schema:hasPart" width="800"> <source about="#video-dokieli-sparqlines" rel="schema:hasPart" resource="https://dokie.li/media/video/dokieli-sparqlines.webm" src="https://dokie.li/media/video/dokieli-sparqlines.webm" type="video/webm" typeof="fabio:Film" /> </video> <figcaption property="schema:name"><a href="https://dokie.li/media/video/dokieli-sparqlines.webm">Video</a> of Sparqlines interaction in dokieli</figcaption> </figure> <p id="statistical-data-and-diagrams"><strong>Statistical Data and Diagrams</strong>: Embedding dynamically generated diagrams and charts is possible: after selecting text, the dokieli context menu offers results of a search across registered SPARQL endpoints for the keywords in the selected text, and presents a list of available data series to visualise. The result is an inline sparkline diagram.</p> </div> </section> <section id="adoption" inlist="" rel="schema:hasPart" resource="#adoption"> <h3 property="schema:name">Adoption</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="adoption-w3c-use">The W3C Working Group Note <cite><a href="https://www.w3.org/TR/annotation-html/" rel="cito:citesAsAuthority">Embedding Web Annotations in HTML</a></cite> includes examples from dokieli’s use of the Web Annotation data <cite><a href="https://www.w3.org/TR/annotation-model/" rel="cito:citesAsAuthority">Model</a></cite> and <cite><a href="https://www.w3.org/TR/annotation-vocab/" rel="cito:citesAsAuthority">Vocabulary</a></cite> with motivations for example for <q>Lightweight, decentralised Annotation Tools</q>. The W3C <cite><a href="https://www.w3.org/TR/ldn/" rel="cito:citesAsAuthority">Linked Data Notifications</a></cite> specification uses dokieli’s HTML+RDFa template, and the <a href="https://linkedresearch.org/ldn/" rel="cito:citesAsAuthority">Editor’s Draft</a> showcase dokieli as a consumer of LDN and Web Annotations. The LDN <a href="https://linkedresearch.org/ldn/tests/" rel="cito:citesAsAuthority">test suite</a> also uses dokieli’s templates and stylesheets.</p> <p id="adoption-academic">The academic workshop <cite><a href="http://semstats.org/">SemStats</a></cite> series use dokieli in its Website templates, including the call for contributions. <cite><a href="http://ceur-ws.org/">CEUR-WS.org</a></cite>, an <q>Online Proceedings for Scientific Conferences and Workshops</q> offers the tooling <cite><a href="https://github.com/ceurws/ceur-make">ceur-make</a></cite> to help organisers generate proceedings using dokieli’s HTML+RDFa template, e.g., <cite><a href="http://ceur-ws.org/Vol-1654/">SemStats 2016</a></cite>. We list a community (of academics) who self-publish their articles and thesis using dokieli with different stylesheets and derived scripts under its <cite><a href="https://github.com/linkeddata/dokieli/wiki#examples-in-the-wild">examples in the wild</a></cite>. The conference series: WWW (e.g., <a href="http://events.linkeddata.org/ldow2017/">LDOW</a> and <a href="http://sociam.org/wow2017/">WOW</a> workshops), <a href="https://iswc2017.semanticweb.org/calls/html-submission-guide/">ISWC</a>, and <a href="http://2017.eswc-conferences.org/call-papers">ESWC</a> propose dokieli as one tooling in which authors can use to make their contributions to the calls with.</p> <p id="adoption-misc">The <cite><a href="https://linkedresearch.org/">Linked Research</a></cite> website uses dokieli in its templates on the site as well as workshop proposals and call for contributions. <a href="http://csarven.ca/">csarven.ca</a> uses dokieli in full, where some articles (like this article) offer pointers to a public annotation service in which users may wish to use for their annotations. Articles also dynamically embed annotations from personal storage spaces.</p> </div> </section> </div> </section> <section id="conclusions" inlist="" rel="schema:hasPart" resource="#conclusions"> <h2 property="schema:name">Conclusions</h2> <div about="#conclusions" datatype="rdf:HTML" property="schema:description" typeof="deo:Conclusion"> <p>The Web’s design stands out because of its absence of centralised control, both for technical reasons of scalability and resilience as well as a societal need for freedom of expression. A challenge in such large-scale decentralised networks is how related publications can be semantically interlinked, even if they are authored and published by different parties. Centralising their publications is practiced by the majority of authoring networks today, demanding authors to give up some or all of their control in exchange for technical simplicity.</p> <p>dokieli shows it is possible to build a social machine wherein people interact with each other without the need of centralised coordination. Users can choose storage space for their content independently of the applications with which they edit and view that content. Documents are connected statically through links and dynamically through Linked Data Notifications. This is a proof for the viability of a decentralised authoring and annotation environment built with Web standards.</p> <p>On the other hand, dokieli’s use of standards shows that dokieli itself is only one means to an end: once the document has been created, it lives on as an independent Web citizen. The social machine consists of people and documents, connected by Web standards, with dokieli acting as just one possible catalyst. Different Web applications can incorporate any of dokieli’s functions and implement the principles to varying extents. Since the data is loosely coupled to the application, we avoid the <em>walled garden</em> problem of many current social platforms today.</p> <p>A couple of important socio-technical challenges remain. Resources might want to indicate in a granular way which actions they support or encourage, such as liking, bookmarking, or sharing, and perhaps conditions about which notifications should be sent when any of these events take place. In order to encourage positive behaviour, we might want ways to provide moderation, and solutions to prevent harassment and abuse. Closely related is the issue of identity, pseudonymity and anonymity, and its relation with trust and verification. While there is likely no final solution to these issues in an open ecosystem, it is worthwhile exploring within dokieli or other tools.</p> <p>Future work can examine how additional features can be realised on top of existing Web standards, or where more development is required. Real-time collaborative editing is often realised with centralised communication (even though some peer to peer alternatives exist). Services like top-down annotations or automated entity marking can improve the discoverability of a publication, yet the question of how to offer these without being tied to certain servers needs to be still solved.</p> <p about="" id="epilogue" rel="schema:hasPart"><span about="#epilogue" property="schema:description" typeof="deo:Epilogue">We invite you to try dokieli yourself right now! Annotate this article or spawn a new or a copy that you can edit yourself.</span></p> </div> </section> <section id="acknowledgements" inlist="" prefix="scoro: http://purl.org/spar/scoro/" rel="schema:hasPart" resource="#acknowledgements"> <h2 property="schema:name">Acknowledgements</h2> <div about="#acknowledgements" datatype="rdf:HTML" property="schema:description" typeof="deo:Acknowledgements"> <p>Special thanks to our colleagues at <span about="" id="funding-recipient" rel="scoro:funding-recipient"><a about="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology" href="https://mit.edu/" property="schema:name" rel="schema:url" typeof="schema:Organization">MIT</a></span>/<a href="https://www.w3.org/">W3C</a>; <a href="http://nicola.io/">Nicola Greco</a>, <a href="http://www.computingjoy.com/">Dmitri Zagidulin</a>, <a href="https://deiu.me/profile">Andrei Sambra</a>, <a href="https://www.w3.org/People/Sandro/">Sandro Hawke</a>, <a href="https://www.w3.org/People/functions/admin#amy">Amy van der Hiel</a> as well as <a href="http://bblfish.net/">Henry Story</a> and <a href="https://melvincarvalho.com/#me">Melvin Carvalho</a> for their contributions. We are also thankful to collaborate with colleagues at <a href="http://qcri.org.qa/">QCRI</a>. This research was supported in part by <span about="" id="funder" rel="scoro:funder"><a about="http://dbpedia.org/Qatar_Computing_Research_Institute" href="http://qcri.org.qa/" property="schema:name" rel="schema:url" typeof="schema:Organization">Qatar Computing Research Institute</a></span>, <a href="https://www.hbku.edu.qa/">HBKU</a> through the <a href="http://crosscloud.org/">Crosscloud</a> project from 2015-10 to 2016-09. <a href="http://kingsley.idehen.net/">Kingsley Idehen</a> and <a href="https://www.openlinksw.com/">OpenLink Software</a> for their support and contributions to the browser extension. Last but not least, the contributors to the dokieli code, issues, and discussion.</p> </div> </section> <section id="references"> <h2>References</h2> <div> <ol> <li>Otto, B., Auer, S., et al: <cite>Industrial Data Space</cite>, Technical Report, 2016, <a href="https://www.researchgate.net/publication/299536747_Industrial_Data_Space_Digital_Souvereignity_Over_Data" rel="schema:citation">https://www.researchgate.net/publication/299536747_Industrial_Data_Space_Digital_Souvereignity_Over_Data</a></li> <li>Berners-Lee, T.: <cite>Socially-aware Cloud Storage</cite>, 2009, <a href="https://www.w3.org/DesignIssues/CloudStorage.html" rel="schema:citation">https://www.w3.org/DesignIssues/CloudStorage.html</a></li> <li>Champeon, S.: <cite>Progressive Enhancement and the Future of Web Design</cite>, Webmonkey, 2003, <a href="http://hesketh.com/publications/progressive_enhancement_and_the_future_of_web_design.html" rel="schema:citation">http://hesketh.com/publications/progressive_enhancement_and_the_future_of_web_design.html</a></li> <li>Koivunen, M-R., Eric Miller, E.: <cite>W3C Semantic Web Activity</cite>, 2001, <a href="https://www.w3.org/2001/12/semweb-fin/w3csw" rel="schema:citation">https://www.w3.org/2001/12/semweb-fin/w3csw</a></li> <li>Golbeck, J.: <cite>Weaving a Web of Trust</cite>, Science Magazine, Vol. 321, 2008, <a href="https://pdfs.semanticscholar.org/5e37/daf945094ea9c9df127e06b05282e03e39bd.pdf" rel="schema:citation">https://pdfs.semanticscholar.org/5e37/daf945094ea9c9df127e06b05282e03e39bd.pdf</a></li> <li>Richardson, M., Agrawal, R., Domingos, P.: <cite>Trust Management for the Semantic Web</cite>, ISWC 2003, <a href="https://link.springer.com/content/pdf/10.1007%2F978-3-540-39718-2_23.pdf" rel="schema:citation">https://link.springer.com/content/pdf/10.1007%2F978-3-540-39718-2_23.pdf</a></li> <li>Jennifer Golbeck, J.: Parsia, B., Hendler, J.: <cite>Trust Networks on the Semantic Web</cite>, Volume 2782 of the book series LNCS, 2003, <a href="http://sir-lab.usc.edu/cs586/20151readings/w13-1.pdf" rel="schema:citation">http://sir-lab.usc.edu/cs586/20151readings/w13-1.pdf</a></li> <li>Khalili, A., Auer, S.: <cite>User interfaces for semantic authoring of textual content: A systematic literature review</cite>, Web Semantics, Volume 22, pages 1–18 (2013), <a href="http://svn.aksw.org/papers/2011/JWS_SemanticContentAuthoring/public.pdf" rel="schema:citation">http://svn.aksw.org/papers/2011/JWS_SemanticContentAuthoring/public.pdf</a></li> <li>Capadisli, S., Guy, A., Lange, C., Auer, S., Deiu, A., Berners-Lee, T.: <cite>Linked Data Notifications: a resource-centric communication protocol</cite>, ESWC Linked Data, 2017, <a href="http://csarven.ca/linked-data-notifications" rel="schema:citation">http://csarven.ca/linked-data-notifications</a></li> <li>Capadisli, S., Guy, A.: <cite>Linked Data Notifications</cite>, W3C Proposed Recommendation, 2017, <a href="https://www.w3.org/TR/ldn/" rel="schema:citation">https://www.w3.org/TR/ldn/</a></li> <li>Graff, E., Silli, L.: <cite>Polyglot Markup: A robust profile of the HTML5 vocabulary</cite>, W3C Working Group Note, 2015, <a href="https://www.w3.org/TR/html-polyglot/" rel="schema:citation">https://www.w3.org/TR/html-polyglot/</a></li> <li>Capadisli, S.: <cite>Sparqlines: SPARQL to Sparkline</cite>, ISWC SemStats, 2016, <a href="http://csarven.ca/sparqlines-sparql-to-sparkline" rel="schema:citation">http://csarven.ca/sparqlines-sparql-to-sparkline</a></li> <li>Story, H., Corlosquet, S., Sambra, A.: <cite>WebID Authentication over TLS</cite>, W3C Editor’s Draft, 2014, <a href="https://www.w3.org/2005/Incubator/webid/spec/tls/" rel="schema:citation">https://www.w3.org/2005/Incubator/webid/spec/tls/</a></li> <li>Sanderson, R., Ciccarese, P., Young, B.: <cite>Web Annotation Data Model</cite>, W3C Recommendation, 2017, <a href="https://www.w3.org/TR/annotation-model/" rel="schema:citation">https://www.w3.org/TR/annotation-model/</a></li> <li>Sanderson, R.: <cite>Digital Publishing Annotation Use Cases</cite>, W3C Interest Group Note, 2014 <a href="https://www.w3.org/TR/dpub-annotation-uc/" rel="schema:citation">https://www.w3.org/TR/dpub-annotation-uc/</a></li> <li>Sanderson, R.: <cite>Web Annotation Protocol</cite>, W3C Recommendation, 2017, <a href="https://www.w3.org/TR/annotation-protocol/" rel="schema:citation">https://www.w3.org/TR/annotation-protocol/</a></li> <li>Cole, T., Capadisli, S., Young, B., Herman, I.: <cite>Embedding Web Annotations in HTML</cite>, W3C Working Group Note, 2017, <a href="https://www.w3.org/TR/annotation-html/" rel="schema:citation">https://www.w3.org/TR/annotation-html/</a></li> <li>Sanderson, R., Ciccarese, P., Young, B.: <cite>Web Annotation Vocabulary</cite>, W3C Recommendation, 2017, <a href="https://www.w3.org/TR/annotation-vocab/" rel="schema:citation">https://www.w3.org/TR/annotation-vocab/</a></li> </ol> </div> </section> </div> http://csarven.ca/dokieli-rww Sat, 19 Nov 2016 00:00:00 <h1 property="schema:name">Where is Web Science? From 404 to 200</h1> <div id="authors"> <dl id="author-name"> <dt>Authors</dt> <dd id="Sarven-Capadisli" inlist="" rel="bibo:authorList" resource="http://csarven.ca/#i"><span about="" rel="schema:creator schema:publisher schema:author"><a about="http://csarven.ca/#i" href="http://csarven.ca/" property="schema:name" rel="schema:url" typeof="schema:Person"><span about="http://csarven.ca/#i"><span property="schema:givenName">Sarven</span> <span property="schema:familyName">Capadisli</span></span></a></span>^✊</dd> </dl> </div> <dl id="document-identifier"> <dt>Identifier</dt> <dd><a href="http://csarven.ca/web-science-from-404-to-200" rel="owl:sameAs">http://csarven.ca/web-science-from-404-to-200</a></dd> </dl> <dl id="document-in-reply-to"> <dt>In Reply To</dt> <dd><a href="https://linkedresearch.org/calls" rel="as:inReplyTo">Call for Linked Research</a></dd> <dd><a href="http://sociam.org/wow2017/" rel="as:inReplyTo">Workshop on Web Observatories, Social Machines and Decentralisation</a></dd> </dl> <dl id="document-inbox"> <dt>Notifications Inbox</dt> <dd><a href="https://linkedresearch.org/inbox/csarven.ca/web-science-from-404-to-200/" rel="ldp:inbox">inbox/</a></dd> </dl> <dl id="document-annotation-service"> <dt>Annotation Service</dt> <dd><a href="https://linkedresearch.org/annotation/csarven.ca/web-science-from-404-to-200/" rel="oa:annotationService">annotation/</a></dd> </dl> <dl id="document-published"> <dt>Published</dt> <dd><time datatype="xsd:dateTime" content="2016-11-19T00:00:00Z" datetime="2016-11-19T00:00:00Z" property="schema:datePublished">2016-11-19</time></dd> </dl> <dl id="document-modified"> <dt>Modified</dt> <dd><time datatype="xsd:dateTime" content="2017-01-22T00:00:00Z" datetime="2017-01-22T00:00:00Z" property="schema:dateModified">2017-01-22</time></dd> </dl> <dl id="document-license"> <dt>License</dt> <dd><a href="https://creativecommons.org/licenses/by/4.0/" rel="schema:license" title="Creative Commons Attribution 4.0 Unported">CC BY 4.0</a></dd> </dl> <div id="content"> <section id="abstract"> <h2>Abstract</h2> <div datatype="rdf:HTML" property="schema:abstract"> <p>Typical practice in scholarly communication of Web Science diverges from the broader vision of the Web. This article outlines the socio-technical problem space of Web-based academic engagement, and presents a vision of a paradigm shift led by Web Science. We propose a path towards adding Web Science research to the Web. 🙈 🙉 🙊</p> </div> </section> <section id="keywords"> <h2>Keywords</h2> <div> <ul rel="schema:about"> <li><a href="https://en.wikipedia.org/wiki/Decentralization" resource="http://dbpedia.org/resource/Decentralization">Decentralisation</a></li> <li><a href="https://en.wikipedia.org/wiki/Open_access" resource="http://dbpedia.org/resource/Open_access">Open Access</a></li> <li><a href="https://en.wikipedia.org/wiki/Semantic_publishing" resource="http://dbpedia.org/resource/Semantic_publishing">Semantic publishing</a></li> <li><a href="https://en.wikipedia.org/wiki/Social_machine" resource="http://dbpedia.org/resource/Social_machine">Social machine</a></li> <li><a href="https://en.wikipedia.org/wiki/Social_web" resource="http://dbpedia.org/resource/Social_web">Social web</a></li> <li><a href="https://en.wikipedia.org/wiki/Web_science" resource="http://dbpedia.org/resource/Web_science">Web Science</a></li> </ul> </div> </section> <section id="introduction" rel="schema:hasPart" resource="#introduction"> <h2 property="schema:name">Introduction</h2> <div datatype="rdf:HTML" property="schema:description" resource="#introduction" typeof="deo:Introduction"> <p>The ideas in this article are intended to serve as areas of investigation for the Web Science community to self-examine and pursue a socio-technical (r)evolution in scholarly communication. Contemporary scholarly communication is a complex social machine involving a global network of (in the broadest senses) teachers, learners, buyers and sellers. Centuries or more of embedded assumptions and culture around knowledge acquisition and sharing meet modern technologies and practices. Advancements in scholarly communication are not keeping pace with the advances in, and expectations that society has of, communication in general. We argue that Web Scientists have both the duty and ability to lead progress, but are hampered by a complex array of social and technical challenges. This article unpacks some of these challenges, describes the advancements that have been made so far, and proposes small steps we can take to move forwards.</p> <figure id="figure-from-visual-to-the-electric-age" rel="schema:hasPart" resource="#figure-from-visual-to-the-electric-age"> <iframe allowfullscreen="true" frameborder="0" height="480" rel="schema:video" src="https://www.youtube-nocookie.com/embed/5gKPsSYYkns?rel=0" width="640"></iframe> <figcaption property="schema:name">From the visual to the electric age</figcaption> </figure> <p><q cite="https://www.youtube-nocookie.com/embed/5gKPsSYYkns?rel=0" rel="cito:includesQuotationFrom">Literate culture is visual and detached... <strong>the effect of the electric revolution is to create once more an involvement</strong> that is total.</q> — <cite><a href="https://en.wikipedia.og/wiki/Marshall_McLuhan" rel="cito:credits">Marshall McLuhan</a></cite>.</p> <p id="web-as-an-extension">The Web offers extensible interactions, creative participation, and social engagement. There is a natural human desire to connect with others, as well as to co-create. Given these opportunities, the fundamental question to ask here is: why should research communication in Web Science be limited to, evaluated by, and rewarded according to old-fashioned practices? The methods in question which are still used date back to the invention of the <a href="https://en.wikipedia.org/wiki/Printing_press">mechanical movable type printing press</a> (circa 1450).</p> <figure id="figure-ted-nelson-demonstrates-xanaduspace" rel="schema:hasPart" resource="#figure-ted-nelson-demonstrates-xanaduspace"> <iframe allowfullscreen="true" height="360" rel="schema:video" src="https://www.youtube-nocookie.com/embed/1yLNGUeHapA?rel=0&amp;start=50&amp;end=90" width="640"></iframe> <figcaption property="schema:name">Ted Nelson Demonstrates XanaduSpace (by Arthur Bullard)</figcaption> </figure> <p><q cite="https://www.youtube.com/watch?v=1yLNGUeHapA&amp;t=50s" rel="cito:includesQuotationFrom">When I saw the computer, I said, <strong>‘at last we can escape from the prison of paper’</strong>... what did the other people do, they <strong>imitated paper</strong>, which to me seems totally insane</q> — <cite><a href="http://en.wikipedia.org/wiki/Ted_Nelson" rel="cito:credits">Ted Nelson</a></cite>.</p> <p id="if-no-accessible-iri-does-it-exist">The Web can be purposed for greater possibilities than that of print alone; we urgently need to address the question: what constitutes a <em>contribution</em> in Web Science? What do you think of the following equivalence: <q cite="https://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest">If a tree falls in a forest and no one is around to hear it, does it make a sound?</q> ≡ <q>If Web Science scholarly communication is inaccessible or unidentifiable, does it exist?</q></p> <p><q>Local-scale changes in Web architectures and resources can lead to large-scale societal and technical effects.</q> — <cite><a href="http://eprints.ecs.soton.ac.uk/12614/01/Semantic_Web_Revisted.pdf" rel="cito:includesQuotationFrom">The Semantic Web Revisited</a> (Nigel Shadbolt, Wendy Hall, Tim Berners-Lee)</cite></p> <p>This article is a reflection on the scholarly communication practices primarily from Web Science, Semantic Web, Linked Data, and related Information Science communities, referred to collectively as Web Science.</p> </div> </section> <section id="problem-space" rel="schema:hasPart" resource="#problem-space"> <h2 property="schema:name">Problem space</h2> <div datatype="rdf:HTML" property="schema:description" resource="#problem-space" typeof="deo:ProblemStatement"> <p>We first outline some of the categories of challenges that remain to be addressed to facilitate Web-based scholarly communication:</p> <dl> <dt id="universal-access">Universal Access</dt> <dd>Research outputs tend to end up being published at for-profit third-party services. These services have created an ecosystem that is closed in nature, restricting the acquisition of research results only to the privileged, dependent on location or connection with subscribing institutions. Thus publicly funded research ends up actually controlled by <q>gatekeepers</q>, in many ways contradictory to the fundamental values of the Web. Even in the case of initiatives like <cite>Open Access</cite>, individuals and institutions end up with high costs in electronic subscriptions, self-archiving, and with article processing charges. This <cite><a href="http://poynder.blogspot.ch/2017/01/the-nih-public-access-policy-triumph-of.html" rel="cito:discusses">contradicts</a></cite> even the heart of the <cite><a href="http://www.budapestopenaccessinitiative.org/" rel="cito:citesAsEvidence">Budapest Open Access Initiative</a></cite> (or even if we revisit <cite><a href="http://openaccess.eprints.org/index.php?/archives/669-guid.html" rel="cito:citesAsEvidence">Subversive Proposal</a></cite>). The for-profit models which also influence rights and licensing on the information breed access barriers to human knowledge even today. Hence the emergence of guerilla services like <cite><a href="https://en.wikipedia.org/wiki/Sci-Hub" rel="cito:citesAsEvidence">Sci-Hub</a></cite> which bypass publisher paywalls.</dd> <dt id="centralisation">Centralisation</dt> <dd>Academic publications end up in <em>information silos</em>. There are constraints and penalties for moving the data or making it accessible by other means. With that, the canonical identifiers of research objects — the strings that are considered to be academically <q>citable</q> — and the resources retrievable via those identifiers, are subject to the terms of the host. The opportunity to build a true sense of data ownership is missing from the Web Science community; information is usually handed over to third-party services operating in isolation in comparison to the Web at large.</dd> <dt id="open-communication">Open communication</dt> <dd>The common scientific communication form in this space is unidirectional — between the organising committee and the authors — as well as held mostly behind the scenes. The communication is neither held in public nor exposed even after the articles are made publicly available. The public is not particularly aware of the grounds on which an article was accepted, the feedback and concerns it received from peer-reviewers, or the revisions it received. This is useful information for carrying out open discussions in the spirit of science. Lastly, there is no way to identify the reliability or strength of reviewers beyond the trust the community places on organising committees.</dd> <dt id="user-experience">User experience</dt> <dd>Scholarly articles and their peer-reviews are predominantly geared for desktop and print-based consumption. Knowledge is expected to fit rigorously within two-dimensional space, absorbed in a linear-fashion, and is devoid of the interactive possibilities of the Web.</dd> <dt id="machine-readable-data">Machine-readable data</dt> <dd>Recently there are <a href="http://ec.europa.eu/digital-agenda/en/news/revision-psi-directive" title="European Commission PSI Directive" rel="cito:citesAsEvidence">directives</a> in some regions to publish datasets in accessible, machine-readable open formats, and Web Science research should be pioneering these efforts. Although more and more researchers (from all disciplines) are publishing their datasets and results directly in some form, Web Scientists are missing the opportunity to use their expertise to lead in publishing machine-readable semantic representations of all kinds of data, including the contents of prose-style research 'papers'. Such data can be purposed toward (semi)automated discovery of arguments and hypotheses, tracking provenance of and relationships between ideas, and collective <em>understanding</em> of the enormous scale of research which is produced every year.</dd> <dt id="practice">Practice</dt> <dd>The absence of Web-based engagement in one’s own research work may lead to confined understanding of what works or is feasible to materialise. In other words, the community at large neglects to <em>eat its own dogfood</em>. This has lead to exploring solutions to problems which do not necessarily work well in practice. The lack of involvement in the complete process of capturing research data from the start, from writing, to peer-reviews, and collation and distribution of articles, has lead to designing research communication that is strictly non-involving or participatory. The opportunity to better collaborate with the other researchers, as well as effectively reuse their data is minimal. The effects of non-engagement have consequences in personal education, control and trust, and the enhancement of the field as whole.</dd> </dl> <p>Where these themes converge is that notable amounts of scholarly data is either inaccessible to the Web at large or unfit for the native Web stack, and consequently hinders the evolutionary process of <em>Web Science</em> and its study. The rest of this article narrows down on some key areas where these issues emerge and proposes tangible paths towards working more closely within the forward-looking <cite><a href="http://eprints.soton.ac.uk/id/eprint/263347" rel="cito:citesAsAuthority">A Framework for Web Science</a></cite>.</p> </div> </section> <section id="escaping-the-prison-of-paper" rel="schema:hasPart" resource="#escaping-the-prison-of-paper"> <h2 property="schema:name">Escaping the prison of paper</h2> <div datatype="rdf:HTML" property="schema:description"> <section id="eating-our-own-dogfood" rel="schema:hasPart" resource="#eating-our-own-dogfood"> <h3 property="schema:name">Eating our own dogfood</h3> <div datatype="rdf:HTML" property="schema:description"> <p><cite><a href="http://users.physik.fu-berlin.de/~kleinert/feynman/last16s.jpg" rel="cito:includesQuotationFrom">What I cannot create I do not understand.</a></cite> — <a href="https://en.wikipedia.org/wiki/Richard_Feynman">Richard Feynman</a></p> <p id="fair-is-not-so-fair" rel="schema:hasPart" resource="#fair-is-not-so-fair"><span datatype="rdf:HTML" property="schema:description">There are several examples of well-intentioned researchers presenting their findings and ideas on how to take scholarly communication as well as Web Science forward, yet the majority stop at actually demonstrating what they propose. To take one recent example, the article <cite><a rel="cito:discusses" href="http://www.nature.com/articles/sdata201618">The FAIR Guiding Principles for scientific data management and stewardship</a></cite> with 53 authors (that is not a typo), hosted by nature.com (2016), points out a helpful guideline: <q resource="http://www.nature.com/articles/sdata201618" rel="cito:includesQuotationFrom">F1. (meta)data are assigned a globally unique and persistent identifier</q>. To eat one’s own dogfood, we would have expected an identifier for that statement, however it does not exist. Naturally, one should ask: what is <em>Findable, Accessible, Interoperable, Reusable</em> (<abbr title="Findable, Accessible, Interoperable, Reusable">FAIR</abbr>) about that statement? What is the measurable delta between this article and every other article (and there are many) making the exact same recommendation? If we were to try to reuse the guideline that is put forward in our study, how can we link to it without any ambiguity? Here is a working example from 1996 <a href="https://www.w3.org/DesignIssues/Axioms.html#Universality" title="Universal Resource Identifiers -- Axioms of Web Architecture" rel="cito:includesQuotationFrom">https://www.w3.org/DesignIssues/Axioms.html#Universality2</a> written by <a href="https://www.w3.org/People/Berners-Lee/card#i">Tim Berners-Lee</a> which states: <q>Axiom 0a: Universality 2. Any resource of significance should be given a URI.</q> Why was not this earlier work reused or cited?</span></p> <p id="paper-based-conferences" rel="schema:hasPart" resource="#paper-based-conferences"><span datatype="rdf:HTML" property="schema:description">In a similar vein, conferences announce their calls for contributions, and require contributions to use desktop/paper-based electronic formats, e.g., <cite><a href="http://www.cyprusconferences.org/elpub2017/submission.html" rel="cito:refutes">ELPUB</a></cite>, <cite><a href="http://ht.acm.org/ht2016/calls" rel="cito:refutes">ACM Hypertext</a></cite>, <cite><a href="http://www.www2017.com.au/call-for-papers/" rel="cito:refutes">WWW</a></cite>, <cite><a href="https://websci.tw.rpi.edu/Papers.html" rel="cito:refutes">WebSci</a></cite>, <cite><a href="http://csarven.caicwe2017.webengineering.org/#submissions" rel="cito:refutes">ICWE</a></cite>. All of these calls are about sharing research output about the Web as two dimensional objects destined for print. None of them explore the full potential of native Web tools or technologies for knowledge dissemination, or encourage their research communities to do so. Reviews are held behind closed doors, reviewers are not publicly attributed or subject to question. These type of events even state that contributions which do not comply with certain constraints will be rejected at the door without review. To pick further on WWW (<strong>the</strong> World Wide Web conference), its contribution to the <cite><a href="http://www.www2017.com.au/about/festival-of-the-web.php" rel="cito:discusses">Festival of the Web</a></cite>, expects contributions to be in <q>English</q>, <q>font size no smaller than 9pt</q>, <q>in PDF</q>, <q>formatted for US Letter size</q>, <q>occupy no more than eight pages</q>. McLuhan, Ted, TimBL, sorry, we really messed up our information superhighway. If we apply Tim’s <cite><a href="https://www.w3.org/DesignIssues/LinkedData#fivestar" rel="cito:agreesWith">Linked Open Data star scheme</a></cite>, it is debatable whether they would even receive a single <abbr title="star">★</abbr> (star).</span></p> <p id="easychair" rel="schema:hasPart" resource="#easychair"><span datatype="rdf:HTML" property="schema:description">Lastly, the peer-reviews themselves tend to live behind centralised services like <a href="http://easychair.org/" rel="cito:critiques">Easychair</a> with no particular educational value to anyone outside of the restricted access, i.e., the public. A transparent peer-review process as well as the discussions around it can be seen as <cite><a href="http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0147913" rel="cito:citesForInformation">an indicator of peer-review quality</a></cite>.</span></p> <p id="web-we-want" rel="schema:hasPart" resource="#web-we-want"><span datatype="rdf:HTML" property="schema:description">All of these are lost opportunities for the community as a whole, where even small amounts of mindfulness and care on building towards a <cite><a href="https://webwewant.org/" rel="cito:citesAsRelated">Web We Want</a></cite> can make a big difference. To counter our complaints, we now present the following as some positive examples of eating one’s own dogfood.</span></p> <section id="sparqlines-semstats-ceur" rel="schema:hasPart" resource="#sparqlines-semstats-ceur"> <h4 property="schema:name">Sparqlines, SemStats, CEUR-WS</h4> <div datatype="rdf:HTML" property="schema:description"> <p><cite><a href="http://semstats.org/" rel="cito:citesAsEvidence">SemStats</a></cite> is a workshop series usually held at <cite><a href="http://iswc2017.semanticweb.org/" rel="cito:citesAsEvidence">ISWC</a></cite>. Determined to push forward the vision of accessible and open semantics research, we have been welcoming HTML/RDF based contributions since 2013. The entire workshop site, including the calls themselves are in HTML+RDFa. This enables the possibility to make relations such as <a href="http://csarven.ca/sparqlines-sparql-to-sparkline" rel="cito:citesAsEvidence">article</a> <em>is in reply to</em> a <a href="http://semstats.org/2016/call-for-contributions" rel="cito:citesAsEvidence">call</a>, as well as having the <a href="http://ceur-ws.org/Vol-1654/" rel="cito:citesAsEvidence">proceedings</a> semantically related to both the article and the workshop. We can see these simple yet useful <em>links</em> among these documents with their accompanying data:</p> <div id="article-calls-proceedings" class="tabs"> <nav> <ul> <li class="selected"><a href="http://csarven.ca/web-science-from-404-to-200#figure-article-calls-proceedings">Graph</a></li> <li><a href="http://csarven.ca/web-science-from-404-to-200#script-article-calls-proceedings">Turtle</a></li> </ul> </nav> <figure class="selected" id="figure-article-calls-proceedings" rel="schema:hasPart" resource="#figure-article-calls-proceedings"> <object data="http://csarven.ca/media/images/articles/calls-and-proceedings-graph.svg" height="253" rel="schema:image" type="image/svg+xml" width="480"></object> <figcaption property="schema:name">RDF statements interlinking a research article, call for contributions and workshops, and proceedings.</figcaption> </figure> <figure class="listing" id="script-article-calls-proceedings" rel="schema:hasPart" resource="#script-article-calls-proceedings"> <pre about="#script-article-calls-proceedings" property="schema:description" typeof="fabio:Script"><code>@prefix sioc: &lt;http://rdfs.org/sioc/ns#&gt; .</code> <code>@prefix schema: &lt;https://schema.org/&gt; .</code> <code>@prefix bibo: &lt;http://purl.org/ontology/bibo/&gt; .</code> <code>&lt;<a href="http://semstats.org/2013/">http://semstats.org/2013/</a>&gt;</code> <code> as:inReplyTo &lt;<a href="http://iswc2013.semanticweb.org/content/call-workshops.html">http://iswc2013.semanticweb.org/content/call-workshops.html</a>&gt; ;</code> <code> <strong class="highlight-hasPart">schema:hasPart</strong> &lt;<a href="http://semstats.org/2013/call-for-papers">http://semstats.org/2013/call-for-papers</a>&gt; .</code> <code>&lt;<a href="http://csarven.ca/linked-statistical-data-analysis">http://csarven.ca/linked-statistical-data-analysis</a>&gt;</code> <code> <strong class="highlight-reply_of">as:inReplyTo</strong> &lt;<a href="http://semstats.org/2013/call-for-papers">http://semstats.org/2013/call-for-papers</a>&gt; ;</code> <code> bibo:citedBy &lt;<a href="http://ceur-ws.org/Vol-1549/">http://ceur-ws.org/Vol-1549/</a>&gt; .</code> <code>&lt;<a href="http://ceur-ws.org/Vol-1549/">http://ceur-ws.org/Vol-1549/</a>&gt;</code> <code> schema:hasPart &lt;<a href="http://ceur-ws.org/Vol-1549/#article-06">http://ceur-ws.org/Vol-1549/#article-06</a>&gt; .</code> <code>&lt;<a href="http://ceur-ws.org/Vol-1549/#article-06">http://ceur-ws.org/Vol-1549/#article-06</a>&gt;</code> <code> bibo:uri &lt;<a href="http://csarven.ca/linked-statistical-data-analysis">http://csarven.ca/linked-statistical-data-analysis</a>&gt; .</code></pre> <figcaption property="schema:name">RDF statements interlinking a research article, call for contributions and workshops, and proceedings.</figcaption> </figure> </div> <script>DO.U.showAsTabs('article-calls-proceedings');</script> </div> <figure rel="schema:hasPart" resource="http://csarven.ca/media/images/articles/graph-sparqlines-semstats-ceur-linked-research.png"> <a rel="foaf:depicts" resource="#sparqlines-semstats-ceur" href="http://csarven.ca/media/images/articles/graph-sparqlines-semstats-ceur-linked-research.png"><img src="http://csarven.ca/media/images/articles/graph-sparqlines-semstats-ceur-linked-research.png" alt="Graph view of the Sparqlines article, SemStats Call, Linked Research Call, and CEUR-WS Proceeding" width="100%" /></a> <figcaption property="schema:name">Graph view of the Sparqlines article, SemStats Call, Linked Research Call, and the CEUR-WS Proceeding generated using <a href="http://franz.com/agraph/gruff/">Gruff</a>.</figcaption> </figure> </section> <section id="semantic-web-journal" rel="schema:hasPart" resource="#semantic-web-journal"> <h4 property="schema:name">Semantic Web journal</h4> <div datatype="rdf:HTML" property="schema:description"> <p>The online <cite><a href="http://www.semantic-web-journal.net/" rel="cito:discusses">Semantic Web journal</a></cite> places a mandate for the authors to provide their peer-reviewed articles in LaTeX format in order to be fit for the third-party publisher’s workflow, as well as to disseminate the research knowledge about Semantic Web in PDF. However this is in addition to the article being <a href="http://www.semantic-web-journal.net/content/linked-sdmx-data" rel="cito:citesAsEvidence">available</a> (free of charge) on their website and in some cases linked to their <a href="http://csarven.ca/linked-sdmx-data" rel="cito:citesAsEvidence">canonical URL</a>. The highlight of the journal is its encouragement for <a href="http://geog.ucsb.edu/~jano/LP-final-authorversion.pdf" rel="cito:citesAsEvidence" title="Open and transparent: the review process of the Semantic Web journal">open and transparent peer-review</a>. Reviews are publicly accessible on the contributions at each phase of the publication process. Additionally, authors of the reviews have the option to be transparent about their identity, which plays an important role towards accountability as well as receiving well-deserved attribution for their time and expertise.</p> </div> </section> <section id="semant-web-dog-food-and-scholarlydata" rel="schema:hasPart" resource="#semantic-web-dog-food-and-scholarlydata"> <h4 property="schema:name">Semantic Web Dog Food and ScholarlyData</h4> <div datatype="rdf:HTML" property="schema:description"> <p id="semantic-web-dog-food" rel="schema:hasPart" resource="#semantic-web-dog-food"><span datatype="rdf:HTML" property="schema:description">The <cite><a href="http://data.semanticweb.org/" rel="cito:discusses">Semantic Web Dog Food</a></cite> initiative was aimed at providing <q>information on papers that were presented, people who attended, and other things that have to do with the main conferences and workshops in the area of Semantic Web research.</q> The initiative was successful and grounded itself in demonstrating convincing arguments towards contributing to the Semantic Web vision by providing a <cite><a href="http://iswc2007.semanticweb.org/papers/795.pdf" rel="cito:citesForInformation">recipe for dogfooding</a></cite>. However, one limitation of its corpus on research articles was that it only <a href="http://data.semanticweb.org/conference/eswc/2015/paper/demo/41" rel="cito:citesAsEvidence">consisted of metadata</a> like article title, authors, abstract. There was no granular semantic information like hypothesis, arguments, results, methodology, and so on since the article source format was not accompanied with semantic relations.</span></p> <p id="scholarlydata" rel="schema:hasPart" resource="#scholarlydata"><span datatype="rdf:HTML" property="schema:description">Following this effort, the <cite><a href="http://www.scholarlydata.org/" rel="cito:discusses">ScholarlyData project</a></cite> recently became the <cite><a href="http://www.scholarlydata.org/papers/iswc2016/iswc2016.html" rel="cito:citesForInformation">successor</a></cite> of Semantic Web Dog Food project, where it focused on refactoring the original dataset, as well as making improvements on the <cite><a href="http://data.semanticweb.org/ns/swc/swc_2009-05-09.html" rel="cito:citesForInformation">Semantic Web Conference Ontology</a></cite>. Nevertheless, the input data (from the articles, conferences, people and organisations) is still no better than its source formats. The dependency here is not on native Web formats but on others’ requirements and convenience. These initiatives can still have higher potential if the original data shifted from <em>metadata</em> to <em>data</em>.</span></p> </div> </section> <section id="current-initiatives-at-conferences" rel="schema:hasPart" resource="#current-initiatives-at-conferences"> <h4 property="schema:name">Current initiatives</h4> <div datatype="rdf:HTML" property="schema:description"> <p>Some of the academic conferences in Web Science, e.g., ISWC, ESWC, EKAW, as well as multiple conferences and journals from non Computer Science disciplines, have shown interest in experimenting with the ideas on using non-print centric formats for the research contributions. While the observable progress is relatively slow, it is on the community’s radar. This is a social progress in contrast to the state of affairs circa 2012.</p> <p id="call-for-enabling-linked-research" rel="schema:hasPart" resource="#call-for-enabling-linked-research"><span datatype="rdf:HTML" property="schema:description">Most recently, venues at WWW2017: <cite><a href="http://events.linkeddata.org/ldow2017/" rel="cito:citesAsEvidence">Linked Data on the Web</a></cite> pitched the initiative towards <q><a href="http://events.linkeddata.org/ldow2017/#lorc" rel="cito:citesAsEvidence">Pioneering the Linked Open Research Cloud</a></q>; and the <cite><a href="http://sociam.org/wow2017/" rel="cito:citesAsEvidence">Workshop on Web Observatories, Social Machines and Decentralisation</a></cite> takes a more holistic approach that is closely aligned with Web Science. The workshop on <cite><a href="https://linkedresearch.org/events/eswc2017/" rel="cito:citesAsEvidence">Enabling Decentralised Scholarly Communication</a></cite> at ESWC2017 is part of an ongoing <a href="https://linkedresearch.org/calls" rel="cito:citesForInformation">Call for Linked Research</a>. Contributors to these calls are explicitly requested to make the best use of what the Web offers (incorporating self-publication, archiving, interactions, social engagement), as well as to raise questions to further understand the challenges ahead and ways to pursue them. This ought to be the norm in Web Science scholarly communication regardless of the content of the research itself.</span></p> </div> </section> <p id="pay-it-forward">In summary, Web Scientists ought to pay it forward by experimenting with the technologies in their playground when they have the chance. In this day and age, a Web scientist who refuses, neglects, or is incapable of using native Web technologies and standards to capture and disseminate their own knowledge is <em title="I can not remember if this is a quote from somewhere or I came up with it. I think the latter.">a bit like a natural scientist insisting to use their own eyes when a microscope is made available to them</em>. We should make best use of the media that are available to us.</p> </div> </section> <section id="illusion-of-existence" rel="schema:hasPart" resource="#illusion-of-and-existence"> <h3 property="schema:name">Illusion of existence</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Let’s have a look at what it means to <em>exist</em> in terms of scholarly communication.</p> <p id="doi" rel="schema:hasPart" resource="#doi"><span datatype="rdf:HTML" property="schema:description">While DOIs and ORCIDs are useful tools, they are centralised manifestations in context of the Web. On the technical end, information that is identified with a DOI scheme <a href="http://blog.crossref.org/2013/09/dois-unambiguously-and-persistently-identify-published-trustworthy-citable-online-scholarly-literature-right.html" title="DOIs unambiguously and persistently identify published, trustworthy, citable online scholarly literature. Right?" rel="cito:citesForInformation">does not in and of itself equate to good quality</a>. After all, anyone can have a DOI registry under their own domain. However in social terms, especially in scientific circles, they are perceived to have more <em>weight</em> than an HTTP URI. HTTP URIs and DOI strings are the same in being unique strings which can be recognised by certain systems. <a href="https://doi.org/" rel="cito:discusses">doi.org</a> makes these identifiers resolveable via HTTP, but is <a href="http://blog.crossref.org/2016/06/beyond-the-doi-to-richer-metadata.html" title="Beyond the DOI to richer metadata" rel="cito:citesAsEvidence">extremely brittle</a>, relies on redirection, and <a href="http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0115253" title="Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot" rel="cito:citesAsEvidence">suffers from reference rot</a>. The cultural value of DOIs can be observed in the tools and services which are built around only acknowledging or exchanging data which has a DOI. Services like <cite><a href="http://crossref.org/" rel="cito:discusses">CrossRef</a></cite> or <cite><a href="https://www.datacite.org/" rel="cito:discusses">DataCite</a></cite> for instance acknowledge <a href="https://doi.org/10.1007/978-3-319-25639-9_5">https://doi.org/10.1007/978-3-319-25639-9_5</a> but do not acknowledge the canonical URI <a href="http://csarven.ca/this-paper-is-a-demo" title="This ‘Paper’ is a Demo" rel="cito:discusses">http://csarven.ca/this-paper-is-a-demo</a>, which is accessible to anyone for free, accompanied with granular Linked Data, interactions, peer-reviews, and wider social engagement tooling. Regardless, the former URI is considered to be <q>citable</q> and the latter is just a blog post according to most Web scientists (for those who do not feel like clicking the links, the article contents are the same). Even services like <cite><a href="http://opencitations.net/" rel="cito:discusses">Open Citations</a></cite> (dependent on the other centralised services) only consider resources which essentially have have a DOI pattern.</span></p> <p id="orcid" rel="schema:hasPart" resource="#orcid"><span datatype="rdf:HTML" property="schema:description">Similarly, while I can more authoritatively provide rich semantic information about my own identity on the Web through <a href="http://csarven.ca/#i" rel="cito:citesAsEvidence">http://csarven.ca/#i</a> (and enabling a <em>follow-your-nose</em> type of exploration) than I ever could with <a href="http://orcid.org/0000-0002-0880-9125" rel="cito:discusses">http://orcid.org/0000-0002-0880-9125</a>, the latter gets acknowledged by services which are essentially disjoint from the rest of the Web. Again, current centralised systems would acknowledge the ORCID URI but not what I have to say about myself that is under my control. I own/rent the domain csarven.ca, but have no control over those of orcid.org. Moreover, to ‘park’ a profile at the latter, I must agree to their terms of service. This is not particularly different than having a profile at Facebook, Twitter, or Google for instance. <cite><a href="https://en.wikipedia.org/wiki/King%27s_Quest_VI" rel="cito:includesQuotationFrom">Heir Today, Gone Tomorrow</a></cite>.</span></p> <p id="social-governance">Technical reasons are secondary to the issue of social governance here. We should naturally raise the question about which academic works and profiles are acknowledged to exist in the scholarly information space. Given that institutions and individuals are capable of creating and sharing their works and profiles at Webspaces under their control (circa 1989, World Wide Web), it follows that DOI and ORCID are only social mechanisms to distinguish between what counts and what does not.</p> <p id="third-party-dependency">There is the traditional approach where an article goes through an opaque peer-review process; complies with the technical requirements of what constitutes a <q>paper</q>; and has the individual or their organisation paying the fees (to publish as well as to attend potential meetings), in addition to agreeing to the terms of the publisher. In this case, works are entitled to <em>exist</em> by means of centralised identifiers. If however this process is not met, the community does not necessarily consider what lays outside to be scientific knowledge. It goes without saying that publishing scientific knowledge on the Web, i.e., accessibly, and with different modes of engagement, is orthogonal to having a free and open, attributable scientific publication process. The requirements of publishers <em>need not</em> necessarily prevent us as individuals from publishing our work on our own websites. However, researchers are not occupying a vacuum, and contend with influences from many directions. These intertwined concerns make up the scholarly communication social machine, one part of which is that universities and libraries channel public funds for subscription fees so that researchers have read access to the articles, reinforcing the system. DOI and ORCID serve as top-down authoritarian constructs. Consequently, the type of data that can be fetched through these routes is fundamentally dependent on whatever the third-party publisher deems suitable for their own business and technical process.</p> </div> </section> <section id="directing-research-focus" rel="schema:hasPart" resource="#directing-research-focus"> <h3 property="schema:name">Directing research focus</h3> <div datatype="rdf:HTML" property="schema:description"> <p>The particular areas of research focus in Web Science is generally guided by conference organisation and journal committees, with the influence of senior researchers and their team’s interests, as well as the funding that is tied to that research. While this approach is practical and accommodates the community’s short-term needs and activities, it is evidently based on human-centred decision making as opposed to leveraging data-driven analysis of the field.</p> <p>To further examine this, we observe that the topics of interest for calls for contributions is a reflection on what worked and did not from earlier experiences usually through <q>town-hall</q> discussions at conferences, as well as off-the-record discussions through different channels. This is valuable feedback from the community, however it could and should be accompanied by the possibility that new research challenges can be discovered by analysing directly data about what has already been studied. This would be a measurable observation which can feed back into the community, as well as providing actual data when it comes to requesting funding more legitimately.</p> </div> </section> <section id="freedom-to-innovate" rel="schema:hasPart" resource="#freedom-to-innovate"> <h3 property="schema:name">Freedom to innovate</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Web Science can serve itself better if the freedom to innovate around how to best present and distribute research results is continuously encouraged. In order for the community to evolve using its own framework, the attempts at reformulating its conventions should be carefully considered and all centrally or top-down imposed restrictions should be thoroughly critiqued.</p> <p id="first-hand-experience">If articles and reviews accommodate machine-readable data (like Linked Data), the potential for reuse is increased. For example, if research articles capture their <a href="http://csarven.ca/web-science-from-404-to-200#problem-space" rel="cito:citesAsEvidence">problem statements</a>, <a href="http://csarven.ca/call-for-linked-research#no-central-authority" rel="cito:citesAsEvidence">motivation</a> <a href="http://csarven.ca/sense-of-lsd-analysis#hypothesis-null" rel="cito:citesAsEvidence">hypothesis</a>, <a href="http://csarven.ca/cooling-down-web-science#introduction" rel="cito:citesAsEvidence">arguments</a>, <a href="http://csarven.ca/enabling-accessible-knowledge#workflow" rel="cito:citesAsEvidence">workflow steps</a>, <a href="http://csarven.ca/sense-of-lsd-analysis#methodology" rel="cito:citesAsEvidence">methodology</a>, <a href="http://csarven.ca/linked-data-notifications#protocol" rel="cito:citesAsEvidence">design</a>, <a href="http://csarven.ca/linked-statistical-data-analysis#results" rel="cito:citesAsEvidence">results</a>, <a href="http://csarven.ca/linked-data-notifications#analysis-and-evaluation">evaluation</a>, <a href="http://csarven.ca/linked-research-scholarly-communication#conclusions" rel="cito:citesAsEvidence">conclusions</a>, <a href="http://csarven.ca/dokieli#next-steps" rel="cito:citesAsEvidence">future challenges</a>, as well as all <a href="https://dokie.li/#figure-dokieli-citation" rel="cito:citesAsEvidence">inline semantic citations</a> (to name <em>a few</em>) where they are uniquely identified, related to other data, and discoverable, then specialised software can be used to verify the article’s well-formedness with respect to the domain. In essence, this materialises the possibility of articles being executable towards reproduction of computational results. Similarly, user interfaces can manifest environments where readers can rerun experiments or observe the effects of changing the input parameters of an algorithm. This provides an important affordance for a more <a title="Up and Down the Ladder of Abstraction" href="http://worrydream.com/LadderOfAbstraction/">involving environment for the user</a>, improves learnability of material, and supersedes the passive mode of simply reading about a proposed approach.</p> <p id="first-post">Innovation can also be encouraged by shortening the length of the research cycle. There are benefits to releasing early-work to the scientific community. For instance, having an early timestamp on some research can provide a strong signal on the origins of ideas and solutions, as well as having the value of practicality of receiving initial feedback from the community and public. Today, even some of the Open Access journal models slow down the scientific process (even if released to the public within first 2 years) when research is not immediately accessible.</p> </div> </section> <section id="illusion-of-quality" rel="schema:hasPart" resource="#illusion-of-quality"> <h3 property="schema:name">Illusion of quality</h3> <div datatype="rdf:HTML" property="schema:description"> <p>We can examine social behaviours around writing articles for particular conferences and journals. For the sake of this discussion, we can refrain from judging the quality of the peer-reviews themselves since rich and poor reviews appear everywhere. This is especially true since <cite><a href="http://journals.plos.org/plosmedicine/article?id=10.1371/journal.pmed.0020124" title="Why Most Published Research Findings Are False" rel="cito:citesAsEvidence">detecting bias even in accurate research findings</a></cite> can be challenging.</p> <p id="groupthink">One groupthink is a fixation on equations like: the number of accepted peer-reviewed articles over total contributions to a conference as a signifier for the venue’s importance in terms of academic credit. Lower the percentile tends to socially imply that a given venue is challenging for scholars to leave their scholarly mark. Unfortunately, such social perceptions create artificial bubbles.</p> <p>To better understand these acceptance rates, we must think again in terms of the holistic social machine of scholarly communication. First, the number of acceptances are not solely based on the value of the contents of contributions as useful research output, but rather dependent on a number of other factors. The contributions that are accepted are ultimately subject to 1) the availability and suitability of the research tracks in a given year (decided, as we already mentioned, by the instinct of senior academics or whims of funding bodies), and 2) the number of articles allotted per volume or proceeding that the chairs are able to take on. Conferences that are collaborating with third-party publishers are instructed to commit to an optimal or preferred number of <em>pages</em> (or other criteria like number of words) for the conference series. These requirements are driven, again as we have already mentioned, by the business needs of for-profit organisations.</p> <p>If venues were not subject to the constraints mentioned above, what would the information space be for the scientific output? Such endeavour would bring researchers to aim for venues or tracks that are most appropriate for their research area, and keep their focus solely on sound and reproducible research, as opposed to making it in to a journal that is artificially prestigious and imposed on researchers by third-party services. Perhaps we should find other standards by which to judge the quality of our research output aggregators instead. Criteria could include: are we permitted to present our work in the way that best conveys its message? Is my contribution deftly and conveniently situated alongside related work for passers-by? Do I have enough control to issue updates, or to engage with reviewers in context?</p> </div> </section> <section id="attributions-and-credit" rel="schema:hasPart" resource="#attributions-and-credit"> <h3 property="schema:name">Attributions and credit</h3> <div datatype="rdf:HTML" property="schema:description"> <p>The Web Science community, like in other fields of research, goes above and beyond investing time, energy, and expertise into peer-reviews. With a few exceptions, reviewers are usually not publicly attributed and credited for their contributions. While the quality of peer-reviews may always be subject to question, they are nevertheless critical to providing some form of verification of scientific output. Hence, they should be captured, preserved, and environments should be created for further social engagement. Peer-review should not be a one-off event, but an ongoing conversation or collaboration. This desire amongst researchers is demonstrated by emerging services which allow academics to engage in <a href="https://publons.com/" rel="cito:discusses">pre</a> and <a href="https://pubpeer.com/" rel="cito:discusses">post</a> <em>publication</em> peer-reviews and comments publicly to foster verifiable reviews and to keep track of retractions.</p> <p>While most research publications in Web Science have their focus on positive results, as well as potentially reusable output (applications), the volume tends to pale in comparison to the negative or inconclusive results obtained during the research process. It is <a href="https://www.nytimes.com/2014/09/19/upshot/to-get-more-out-of-science-show-the-rejected-research.html" rel="cito:citesAsPotentialSolution">hypothesised</a> that to get more out of science, negative results should as well be made visible and credited as they also serve useful information for other researchers to rapidly advance the field. Hence, workshops like <cite><a href="http://noise-workshop.org/" rel="cito:citesAsPotentialSolution">Negative or Inconclusive Results in Semantic Web</a></cite> should be integral to the main research tracks or other workshops.</p> </div> </section> </div> </section> <section id="be-the-change-towards-linked-research" rel="schema:hasPart" resource="#be-the-change-towards-linked-research"> <h2 property="schema:name">Be the change: towards Linked Research</h2> <div datatype="rdf:HTML" property="schema:description"> <p><cite><a href="https://linkedresearch.org/" rel="cito:citesAsAuthority">Linked Research</a></cite> is an initiative, a movement, and a manifesto. It is set out to socially and technically enable researchers to take full control, ownership, and responsibility of their knowledge, and have their contributions accessible to society at maximum capacity. Linked Research calls for dismantling the archaic and artificial barriers that get in the way of this. A <q><a href="https://linkedresearch.org/calls" rel="cito:citesAsPotentialSolution">call</a></q> is available for publishing and promoting open, accessible and reusable academic knowledge.</p> <p id="acid-test">An <em>acid test</em> is proposed at <cite><a href="http://csarven.ca/linked-research-scholarly-communication#user-stories-assumption" rel="cito:citesAsPotentialSolution">Linked Research: An Approach for Scholarly Communication</a></cite>, which aims to evaluate systems openness, accessibility, decentralisation, interoperability in scholarly communication. This test does not mandate a specific technology, therefore the challenge can be met by different solutions. There are a set of proposed challenges for the community to check their systems against to see how well they can fulfill them, as part of the push towards building cooperating systems.</p> <section id="framing-our-vocabulary" rel="schema:hasPart" resource="#framing-our-vocabulary"> <h3 property="schema:name skos:definition">Framing our vocabulary</h3> <div datatype="rdf:HTML" property="schema:description" resource="#framing-our-vocabulary" typeof="skos:ConceptScheme"> <p datatype="rdf:HTML" property="skos:definition">If we acknowledge an imminent new paradigm shift on the horizon, it is necessary to commit and exercise a new vocabulary in our academic endeavours. We should give importance to these new terms because they set our frame of mind, which sets the stage for our daily work. I would like to encourage new calls for <em>contributions</em> to welcome researchers to <em>share</em> their <em>articles</em> and supporting material on the Web:</p> <dl rel="skos:hasTopConcept"> <dt about="#s-submit-share" id="s-submit-share" property="skos:prefLabel" rel="skos:topConceptOf" resource="#framing-our-vocabulary" typeof="skos:Concept"><samp>s/submit/share</samp></dt> <dd about="#s-submit-share" datatype="rdf:HTML" property="skos:definition">The archaic mental frame hinged on the idea that individuals <em>submit</em> their work, as in handing it over, dislocating themselves from what they have produced by giving up their future rights. There is no need to give up anything. It belongs to the creator, and they simply <em>share</em> it under their terms.</dd> <dt about="#s-submission-contribution" id="s-submission-contribution" property="skos:prefLabel" rel="skos:topConceptOf" resource="#framing-our-vocabulary" typeof="skos:Concept"><samp>s/submission/contribution</samp></dt> <dd about="#s-submission-contribution" datatype="rdf:HTML" property="skos:definition">A call by a venue does not merely get <em>submissions</em> of works. That is a misnomer. The process is much richer than that. Individuals make <em>contributions</em> to the field, pushing the boundaries of the collective understanding.</dd> <dt about="#s-paper-article" id="s-paper-article" property="skos:prefLabel" rel="skos:topConceptOf" resource="#framing-our-vocabulary" typeof="skos:Concept"><samp>s/paper/article</samp></dt> <dd about="#s-paper-article" datatype="rdf:HTML" property="skos:definition">The term <em>paper</em> is an obvious and dreadful artefact imposed by the pre-digital generation and archaic business models. Academics in Web Science tend to create <em>articles</em> (electronic documents if you will) that gets to reside somewhere on the Web, that can be discoverable and accessible.</dd> </dl> </div> </section> <section id="cooperation" rel="schema:hasPart" resource="#cooperation"> <h3 property="schema:name">Cooperation</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Sooner or later we need a strategy to address questions like: <em>What do we aim to accomplish?</em> <em>Who is trying to do it and for the benefit of whom?</em> <em>How do we know whether we are making progress and when we have succeeded?</em></p> <p>Potential solutions to these questions and new challenges need to address the unspoken gap between researchers, academic and public institutions, as well as what ends up in the commons. It is not just about researchers publishing their work online, nor about conferences requesting semantically annotated contributions or operating with transparent peer-review. All of these things must move in combination. Here are some ideas that can be executed today:</p> <dl> <dt id="working-together-researchers">Researchers</dt> <dd>Researchers take full responsibility for the creation and publication of their work. This can be at any Webspace they put trust on or have sufficient authority over, e.g., personal site, institutions’ student and faculty pages. Making their work as Webby as possible e.g., linking their arguments and citations to others', interactive story-telling or experimentation possibilities for their readers. Researchers should take special care to ensure URI persistence and archiving of their work. See what your library or online archives (such as <a href="https://archive.org/">archive.org</a> and <a href="http://archive.is/">archive.is</a>) can do for you.</dd> <dt id="working-together-conferences-and-journals">Conferences and journals</dt> <dd>In person conferences and online journals should encourage and accept research publications which use native Web technologies. Support transparent and attributed peer-review process. Aggregation or proceedings of the events should be machine-friendly and archival measures should be taken in addition to that of researchers.</dd> <dt id="working-together-public-institutions">Public institutions</dt> <dd>Given sufficient evidence of the Web Science community’s acknowledgement of research as well as its contributions (eg peer-reviews), academic institutions should officially acknowledge such work towards academic credit. Libraries should make the community’s output discoverable, catalogued, enriched, among many other things.</dd> </dl> </div> </section> </div> </section> <section id="conclusions" inlist="" rel="schema:hasPart" resource="#conclusions"> <h2 property="schema:name">Conclusions</h2> <div datatype="rdf:HTML" property="schema:description" resource="#conclusions" typeof="deo:Conclusion"> <p>This article highlighted some of the significant areas in the practice of Web Science which should be the subject of scrutiny. We describe how scholarly communication functions as a complex social machine, with many aspects which influence each other. This conceptualisation of the space can help us to coordinate efforts in effecting change. Only by examining our current practices, as well as cherishing our curiosity we can evolve Web Science. One of the important outcomes of this is being more active participants for the <q>Web We Want</q>.</p> <p id="new-generation-researchers" rel="schema:hasPart" resource="#new-generation-researchers"><span datatype="rdf:HTML" property="schema:description">The <em>new generation</em> of researchers will phase out older practices. The recent or current generation of academics are sticking to the <span xml:lang="la" lang="la" title="existing state of affairs">status quo</span> and adhering to demands of the third-party publishers’ requirements, or simply because they were <em>brought up</em> in their careers to strictly comply with desktop/print based knowledge dissemination. This generation, resistant to evolution, swims in a <cite class="cool-media"><a href="http://www.worldcat.org/oclc/243805695" title="Understanding media: The extension of man" rel="cito:citesAsRecommendedReading">cool medium</a></cite> - the Web - without actually embracing it. New students and researchers entering an institution are asked to learn Word or LaTeX in order to document their work. We can ask them to learn HTML (possibly with RDF as well) instead. The <q>new generation</q> of academics <em>will</em> open up a new phase for the Web Science community and set a revised agenda to pioneer the field and its practices. This is not about publishing and consuming research knowledge in Webby methods (that is really only a part of the big picture), but diving right into the essence of understanding and welcoming decentralisation, interoperability, data responsibility, accessibility, user experience, and a <em>true</em> sense of linking and building on ideas that can be tracked and discovered. Perhaps most importantly, helping us to better understand the effects of what we do, and the how the Web is changing societies.</span></p> <p id="prophecy">Due to the divergence from the practices described by the Web Science framework, we need to re-examine our mode of work. The community should be preparing for a <cite><a href="http://www.worldcat.org/oclc/857115808" title="The structure of scientific revolutions" rel="cito:citesAsRecommendedReading">paradigm shift</a></cite>, checking the fundamental shared assumptions about the current paradigm in use. What will shortly follow is a state of crisis as the <em>faith</em> in conducting archaic practices will be shaken. The community will then reach a pre-paradigm phase where the new perspective (let’s call it <cite><a href="https://linkedresearch.org/" rel="cito:discusses">Linked Research</a></cite> for now?) will be further explored. The revolution will become invisible when scientists return to their daily activities, better using and incorporating the Web and what it has to offer.</p> <p>We need to be prepared to answer questions like <q>Which scholarly articles are relevant to my research problem?</q>, <q>How can we find and compare the variables of similar hypothesis?</q>, <q>Which other researchers might find my results/output directly useful so I can notify them?</q>, <q>What are some of the unanswered questions or new challenges in a research area?</q>, <q>What are the research gaps?</q>, <q>How do we verify a peer-review and credit the peer-reviewer?</q>, <q>How do we control, store, preserve research?</q>, <q>When do I get my free lunch?</q></p> <p id="space-travel">If trying to achieve space travel was based on our ability to jump, we would have reinvented the trampoline. Therefore, in the spirit of the Web, we ought to strive to change the status of Web Science from <em>404 Not Found</em> to <em>200 OK</em>!</p> </div> </section> <section id="acknowledgements" inlist="" rel="schema:hasPart" resource="#acknowledgements"> <h2 property="schema:name">Acknowledgements</h2> <div about="#acknowledgements" datatype="rdf:HTML" property="schema:description" typeof="deo:Acknowledgements"> <p>A shout-out to Captain <a href="https://rhiaro.co.uk/#me" rel="cito:credits">Amy Guy</a> for encouraging and collaborating to move some of the mentioned initiatives forward, as well as turning my ramblings into something coherent. And, especially <a href="https://linkedresearch.org/calls#reviewers" rel="cito:credits">everyone</a> contributing to improve scholarly communication in Web Science.</p> </div> </section> </div> http://csarven.ca/web-science-from-404-to-200 Tue, 14 Jun 2016 00:00:00 <h1 property="schema:name">Sparqlines: SPARQL to Sparkline</h1> <div id="authors"> <dl id="author-name"> <dt>Authors</dt> <dd id="Sarven-Capadisli" inlist="" rel="bibo:authorList" resource="http://csarven.ca/#i"><span about="" rel="schema:creator schema:publisher schema:author"><a about="http://csarven.ca/#i" href="http://csarven.ca/" property="schema:name" rel="schema:url" typeof="schema:Person"><span about="http://csarven.ca/#i"><span property="schema:givenName">Sarven</span> <span property="schema:familyName">Capadisli</span></span></a></span>^{<a about="http://csarven.ca/#i" href="http://csarven.ca/sparqlines-sparql-to-sparkline#author-org-1" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">1</a>}^{<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#author-email-1">✊</a>}</dd> </dl> <ul id="author-org"> <li id="author-org-1">¹Enterprise Information Systems Department, <a about="http://dbpedia.org/resource/University_of_Bonn" href="http://uni-bonn.de/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Bonn</a>, Bonn, Germany</li> </ul> <ul id="author-email"> <li id="author-email-1">^✊<a about="http://csarven.ca/#i" href="http://csarven.camailto:info@csarven.ca" rel="schema:email">info@csarven.ca</a></li> </ul> </div> <dl id="document-identifier"> <dt>Identifier</dt> <dd><a href="http://csarven.ca/sparqlines-sparql-to-sparkline" rel="owl:sameAs">http://csarven.ca/sparqlines-sparql-to-sparkline</a></dd> </dl> <dl id="document-inbox"> <dt>Notifications Inbox</dt> <dd><a href="https://linkedresearch.org/inbox/csarven.ca/sparqlines-sparql-to-sparkline/" rel="ldp:inbox">inbox/</a></dd> </dl> <dl id="document-published"> <dt>Published</dt> <dd><time content="2016-06-14T00:00:00Z" datatype="xsd:dateTime" datetime="2016-06-14T00:00:00Z" property="schema:datePublished">2016-06-14</time></dd> </dl> <dl id="document-modified"> <dt>Modified</dt> <dd><time content="2016-11-23T00:00:00Z" datatype="xsd:dateTime" datetime="2016-11-23T00:00:00Z" property="schema:dateModified">2016-11-23</time></dd> </dl> <dl id="document-in-reply-to"> <dt>In Reply To</dt> <dd><a href="http://semstats.org/2016/call-for-contributions" rel="as:inReplyTo">SemStats 2016 Call for Contributions</a></dd> <dd><a href="https://linkedresearch.org/calls" rel="as:inReplyTo">Call for Linked Research</a></dd> </dl> <dl id="document-appeared"> <dt>Appeared In</dt> <dd rel="bibo:citedBy" resource="http://ceur-ws.org/Vol-1654/"> <span about="http://ceur-ws.org/Vol-1654/" typeof="bibo:Proceedings"> <span property="bibo:shortTitle">CEUR</span> (<span property="schema:name">Central Europe workshop proceedings</span>): <a href="http://ceur-ws.org/Vol-1654/" rel="schema:url">Proceedings of the 4th International Workshop on Semantic Statistics</a>, Volume <span lang="" property="bibo:volume" xml:lang="">1654</span>, <span lang="" property="bibo:uri" xml:lang="">urn:nbn:de:0074-1654-1</span> </span> </dd> </dl> <dl id="document-license"> <dt>License</dt> <dd><a href="https://creativecommons.org/licenses/by/4.0/" rel="schema:license" title="Creative Commons Attribution 4.0 Unported">CC BY 4.0</a></dd> </dl> <div id="content"> <section id="abstract"> <h2>Abstract</h2> <div datatype="rdf:HTML" property="schema:abstract"> <p>This article presents <em>sparqlines</em>: statistical observations fetched from SPARQL endpoints and displayed as inline-charts. An inline-chart, also known as a <a href="https://en.wikipedia.org/wiki/Sparkline"><em>sparkline</em></a>, is concise, and located where it is discussed in the text, complementing the supporting text without breaking the reader’s flow. For example, the  <span rel="schema:hasPart" resource="#figure-GDP-per-capita-growth--annual---"> <a href="http://worldbank.270a.info/dataset/NY.GDP.PCAP.KD.ZG" property="schema:name" rel="prov:wasDerivedFrom" resource="http://worldbank.270a.info/dataset/NY.GDP.PCAP.KD.ZG" typeof="qb:DataSet">GDP per capita growth (annual %)</a> [Canada] <span class="sparkline" rel="schema:image" resource="#GDP-per-capita-growth--annual---"> <svg height="100%" prefix="rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# xsd: http://www.w3.org/2001/XMLSchema# qb: http://purl.org/linked-data/cube# prov: http://www.w3.org/ns/prov# schema: https://schema.org/" version="1.1" width="100%" xmlns="http://www.w3.org/2000/svg" xmlns:ev="http://www.w3.org/2001/xml-events" xmlns:xlink="http://www.w3.org/1999/xlink"> <style type="text/css">/*<![CDATA[*/line { stroke:#000; stroke-width:1px; } circle { stroke:#f00; fill:#f00; }/*]]>*/</style> <g rel="prov:wasDerivedFrom" resource="http://worldbank.270a.info/dataset/NY.GDP.PCAP.KD.ZG"> <metadata rel="schema:license" resource="https://creativecommons.org/publicdomain/zero/1.0/" /> <title property="schema:name">GDP per capita growth (annual %)</title> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1961" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1961"><line x1="0.9615384615384616%" x2="0.9615384615384616%" y1="43.16454574172421%" y2="43.16454574172421%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1962" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1962"><line x1="0.9615384615384616%" x2="2.8461538461538463%" y1="43.16454574172421%" y2="0.2602253013133691%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1963" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1963"><line x1="2.8461538461538463%" x2="4.730769230769231%" y1="0.2602253013133691%" y2="20.546079976437966%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1964" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1964"><line x1="4.730769230769231%" x2="6.615384615384616%" y1="20.546079976437966%" y2="4.9166537468372695%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1965" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1965"><line x1="6.615384615384616%" x2="8.5%" y1="4.9166537468372695%" y2="4.731637579170197%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1966" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1966"><line x1="8.5%" x2="10.384615384615385%" y1="4.731637579170197%" y2="5.859252100219621%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1967" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1967"><line x1="10.384615384615385%" x2="12.26923076923077%" y1="5.859252100219621%" y2="43.58392297111188%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1968" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1968"><line x1="12.26923076923077%" x2="14.153846153846153%" y1="43.58392297111188%" y2="16.605031338302297%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1969" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1969"><line x1="14.153846153846153%" x2="16.03846153846154%" y1="16.605031338302297%" y2="14.17112377526918%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1970" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1970"><line x1="16.03846153846154%" x2="17.92307692307692%" y1="14.17112377526918%" y2="42.73729961025032%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1971" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1971"><line x1="17.92307692307692%" x2="19.807692307692307%" y1="42.73729961025032%" y2="27.685195209211884%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1972" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1972"><line x1="19.807692307692307%" x2="21.69230769230769%" y1="27.685195209211884%" y2="14.826164877967003%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1973" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1973"><line x1="21.69230769230769%" x2="23.576923076923077%" y1="14.826164877967003%" y2="1.4210854715202004e-14%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1974" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1974"><line x1="23.576923076923077%" x2="25.46153846153846%" y1="1.4210854715202004e-14%" y2="35.39007629908832%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1975" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1975"><line x1="25.46153846153846%" x2="27.346153846153843%" y1="35.39007629908832%" y2="56.008189983767984%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1976" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1976"><line x1="27.346153846153843%" x2="29.230769230769226%" y1="56.008189983767984%" y2="14.398016142296555%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1977" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1977"><line x1="29.230769230769226%" x2="31.115384615384617%" y1="14.398016142296555%" y2="31.113117376011147%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1978" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1978"><line x1="31.115384615384617%" x2="33%" y1="31.113117376011147%" y2="24.010867612061844%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1979" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1979"><line x1="33%" x2="34.88461538461538%" y1="24.010867612061844%" y2="25.516209087392284%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1980" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1980"><line x1="34.88461538461538%" x2="36.76923076923077%" y1="25.516209087392284%" y2="46.03805171008273%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1981" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1981"><line x1="36.76923076923077%" x2="38.65384615384615%" y1="46.03805171008273%" y2="31.353777706294892%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1982" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1982"><line x1="38.65384615384615%" x2="40.53846153846154%" y1="31.353777706294892%" y2="98%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1983" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1983"><line x1="40.53846153846154%" x2="42.42307692307692%" y1="98%" y2="37.049138412484396%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1984" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1984"><line x1="42.42307692307692%" x2="44.30769230769231%" y1="37.049138412484396%" y2="3.8990386857101242%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1985" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1985"><line x1="44.30769230769231%" x2="46.19230769230769%" y1="3.8990386857101242%" y2="14.466152419708749%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1986" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1986"><line x1="46.19230769230769%" x2="48.07692307692307%" y1="14.466152419708749%" y2="40.20714194723098%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1987" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1987"><line x1="48.07692307692307%" x2="49.96153846153846%" y1="40.20714194723098%" y2="24.23504082493062%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1988" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1988"><line x1="49.96153846153846%" x2="51.84615384615385%" y1="24.23504082493062%" y2="16.4155854058384%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1989" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1989"><line x1="51.84615384615385%" x2="53.730769230769226%" y1="16.4155854058384%" y2="46.513539215559256%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1990" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1990"><line x1="53.730769230769226%" x2="55.61538461538461%" y1="46.513539215559256%" y2="68.88140254723645%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1991" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1991"><line x1="55.61538461538461%" x2="57.49999999999999%" y1="68.88140254723645%" y2="91.51801871119973%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1992" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1992"><line x1="57.49999999999999%" x2="59.38461538461538%" y1="91.51801871119973%" y2="58.89063066569448%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1993" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1993"><line x1="59.38461538461538%" x2="61.269230769230774%" y1="58.89063066569448%" y2="42.041295592538034%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1994" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1994"><line x1="61.269230769230774%" x2="63.153846153846146%" y1="42.041295592538034%" y2="14.563197311382893%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1995" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1995"><line x1="63.153846153846146%" x2="65.03846153846155%" y1="14.563197311382893%" y2="34.19521785880608%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1996" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1996"><line x1="65.03846153846155%" x2="66.92307692307693%" y1="34.19521785880608%" y2="49.44858112486089%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1997" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1997"><line x1="66.92307692307693%" x2="68.8076923076923%" y1="49.44858112486089%" y2="21.72442052861726%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1998" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1998"><line x1="68.8076923076923%" x2="70.6923076923077%" y1="21.72442052861726%" y2="20.975803658149985%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1999" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/1999"><line x1="70.6923076923077%" x2="72.57692307692308%" y1="20.975803658149985%" y2="5.386196833413024%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2000" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2000"><line x1="72.57692307692308%" x2="74.46153846153847%" y1="5.386196833413024%" y2="9.161609941779957%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2001" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2001"><line x1="74.46153846153847%" x2="76.34615384615385%" y1="9.161609941779957%" y2="46.98143019467036%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2002" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2002"><line x1="76.34615384615385%" x2="78.23076923076924%" y1="46.98143019467036%" y2="33.71789219866544%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2003" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2003"><line x1="78.23076923076924%" x2="80.11538461538463%" y1="33.71789219866544%" y2="45.81166841275399%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2004" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2004"><line x1="80.11538461538463%" x2="82%" y1="45.81166841275399%" y2="32.79500363273925%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2005" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2005"><line x1="82%" x2="83.88461538461539%" y1="32.79500363273925%" y2="33.68496358846721%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2006" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2006"><line x1="83.88461538461539%" x2="85.76923076923077%" y1="33.68496358846721%" y2="33.70021419695024%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2007" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2007"><line x1="85.76923076923077%" x2="87.65384615384616%" y1="33.70021419695024%" y2="42.15969197718631%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2008" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2008"><line x1="87.65384615384616%" x2="89.53846153846155%" y1="42.15969197718631%" y2="59.31341793784153%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2009" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2009"><line x1="89.53846153846155%" x2="91.42307692307693%" y1="59.31341793784153%" y2="96.43770278569066%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2010" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2010"><line x1="91.42307692307693%" x2="93.3076923076923%" y1="96.43770278569066%" y2="33.011290571731266%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2011" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2011"><line x1="93.3076923076923%" x2="95.1923076923077%" y1="33.011290571731266%" y2="38.88670062678091%" /></a> <a rel="rdfs:seeAlso" resource="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2012" target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2012"><line x1="95.1923076923077%" x2="97.07692307692308%" y1="38.88670062678091%" y2="49.719411631415205%" /></a> <a target="_blank" xlink:href="http://worldbank.270a.info/dataset/world-bank-indicators/NY.GDP.PCAP.KD.ZG/CA/2012"><circle cx="97.07692307692308%" cy="49.719411631415205%" r="1" /></a> </g> </svg> </span> </span> claimed by the <a href="http://worldbank.270a.info/">World Bank Linked Dataspace</a>. We demonstrate an implementation which allows scientists or authors to easily enhance their work with sparklines generated from their own or public statistical linked datasets. This article includes an active demonstration accessible at <a href="http://csarven.ca/sparqlines-sparql-to-sparkline">http://csarven.ca/sparqlines-sparql-to-sparkline</a>.</p> </div> </section> <section id="keywords"> <h2>Keywords</h2> <div> <ul rel="schema:about"> <li><a href="https://en.wikipedia.org/wiki/Linked_Data" resource="http://dbpedia.org/resource/Linked_Data">Linked Data</a></li> <li><a href="https://en.wikipedia.org/wiki/Semantic_publishing" resource="http://dbpedia.org/resource/Semantic_publishing">Semantic publishing</a></li> <li><a href="https://en.wikipedia.org/wiki/Sparkline" resource="http://dbpedia.org/resource/Sparkline">Sparkline</a></li> <li><a href="https://en.wikipedia.org/wiki/SPARQL" resource="http://dbpedia.org/resource/SPARQL">SPARQL</a></li> <li><a href="https://en.wikipedia.org/wiki/Statistics" resource="http://dbpedia.org/resource/Statistics">Statistics</a></li> <li><a href="https://en.wikipedia.org/wiki/User_interface" resource="http://dbpedia.org/resource/User_interface">User interface</a></li> </ul> </div> </section> <section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction"> <h2 property="schema:name">Introduction</h2> <div datatype="rdf:HTML" property="schema:description"> <p>In this article we introduce <em>sparqlines</em>, an integration of statistical data retrieval using SPARQL with displaying observations in the form of word-size graphics: sparklines. We describe an implementation which is part of a Web based authoring tool (<a href="https://dokie.li/">dokieli</a>). We cover how the data is modelled and exposed in order to be suitable for embedding; demonstrate how to embed data as both static and dynamic sparklines and discuss the technical requirements of each; and walk through the user interactions to do so.</p> <p>Our contribution is the generation of a well-established visual aid to reading statistical data (the sparkline) directly from the dataset itself, at the time of authoring the supporting text as part of the writing workflow. This enables authors who are already publishing data to use it directly, as well as encouraging them to make their data available for others to use, and offers an easy way to present the reader with a way to better understand the information.</p> <p>We conclude with a discussion, including design considerations. The code of our implementation is open source, and we invite you to try it out and make requests for more advanced features: <a href="https://github.com/linkeddata/dokieli">https://github.com/linkeddata/dokieli</a>.</p> </div> </section> <section id="related-work" inlist="" rel="schema:hasPart" resource="#related-work"> <h2 property="schema:name">Related Work</h2> <div datatype="rdf:HTML" property="schema:description" resource="#related-work" typeof="deo:RelatedWork"> <section id="sparklines" inlist="" rel="schema:hasPart" resource="#sparklines"> <h3 property="schema:name">Sparklines</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="sparkline-description">The earliest known implementation of an inline-chart was designed and programmed by <a href="http://pete.zelchenko.com/">Peter Zelchenko</a> and Mike Medved to represent historical charts efficiently in the <a href="http://pete.zelchenko.com/portfolio/screen/2gk.htm">QuoteTracker</a> software in early 1999 [<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-1">1</a>]. They are <q>datawords</q>, carrying dense information with the resolution of typography, particularly useful in places where the available screen real estate is minimal. <a href="http://www.edwardtufte.com/">Edward Tufte</a> describes sparkline as <q cite="http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR&amp;topic_id=1"><a href="http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR&amp;topic_id=1">small intense, simple, word-sized graphic with typographic resolution</a></q> [<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-2">2</a>]. They are designed to be included anywhere, for example embedded in a sentence, table or even a map, within the relevant context. When embedded in a sentence, they support the text, allowing continuous reading <embed class="sparkline" src="http://csarven.camedia/images/articles/GDP-per-capita-growth--annual---.svg" type="image/svg+xml" /> without the need to refer to a figure disjoint from the original context, whilst still providing an opportunity for the reader to investigate further by clicking on the data line to access each point of source, per <a href="http://csarven.ca/sparqlines-sparql-to-sparkline#figure-static-sparkline">Figure 1</a>.</p> <p id="sparkline-graphics">Sparkline graphics typically have a variable long dimension and a constrained short dimension. In the case of a typographic line, the constraint can be fixed to the height of the font-size of the encapsulating component. For example, the computed CSS <code>height</code> value of the <code>embed</code> HTML element that contains the sparkline on the current viewing device is <samp class="height">20px</samp>, and so the embedded sparkline in this paragraph will have a vertical aspect ratio as such.</p> <script>document.addEventListener('DOMContentLoaded', function(){var s = document.querySelector('#sparkline-description .sparkline'); document.querySelector('#sparkline-graphics .height').innerHTML = s.ownerDocument.defaultView.getComputedStyle(s, null)["height"];});</script> <figure id="figure-static-sparkline" rel="schema:hasPart" resource="#figure-static-sparkline"> <object data="http://csarven.camedia/images/articles/GDP-per-capita-growth--annual---.svg" height="60" rel="schema:image" type="image/svg+xml" width="640"></object> <figcaption property="schema:name">A typical static figure in an article disjoint from the original context</figcaption> </figure> <style>/*<![CDATA[*/ #figure-static-sparkline object { height:60px !important; min-height:60px !important; } /*]]>*/</style> <p>Sparklines appear in many places where small datafeeds are useful; programmatical insertion in text-editors and spreadsheets, fitness feeds from wearable watches, social media analytics, streaming real-time quotes, electroencephalograms, system dashboards and trays, temperature and stock activity, to name a few. Studies show that novice and experienced investors using stock reports with Sparklines will experience reduced cognitive load [<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-3">3</a>].</p> <p>Sparklines in line, bar, column or win/loss graphs can be programatically included in <cite>Google Drive</cite> documents by including data from an embedded table or sequence of numbers via the Google Charts API [<a href="http://csarven.caref-4">4</a>].</p> <p>The <cite><a href="https://archive.org/web/">Wayback Machine</a></cite> uses sparklines to show an application of the snapshots of a URL through time: <img style="display:block; margin:1em 0;" src="https://web.archive.org/web/jsp/graph.jsp?nomonth=1&amp;graphdata=1029_75_1996:-1:000000000000_2004:-1:010000000430_2005:-1:122430033004_2006:-1:193656640155_2007:-1:634212110911_2008:-1:111111164102_2009:-1:111100000000_2010:-1:101111112322_2011:-1:122221241511_2012:-1:232130203201_2013:-1:5015212111cf_2014:-1:e20112312222_2015:-1:135221123011_2016:3:225300000000" /></p> <p>There are sparkline implementations in JavaScript libraries like d3.js and jQuery. Sparkline implementations also exist for command-line interfaces. These tools tend to take input data in tabular form (CSV). Sparklines can also be created by simple use of <a href="https://rosettacode.org/wiki/Sparkline_in_unicode">Unicode characters</a>: <code>▂▁▄▃▆▅█▇</code>.</p> </div> </section> <section id="rdf-data-cube-and-sparql" inlist="" rel="schema:hasPart" resource="#rdf-data-cube-and-sparql"> <h3 property="schema:name">RDF Data Cube and SPARQL</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Statistical data that is modelled with the RDF Data Cube vocabulary [<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-5">5</a>] makes it possible to discover and identify artefacts in a uniform way. This is in contrast to writing applications to consume data from endpoints with heterogeneous data models. For front-end Web applications, data can be fetched, explored, and filtered from <a href="http://csarven.ca/statistical-linked-dataspaces">statistical linked dataspaces</a> with SPARQL endpoints, e.g., <a href="http://270a.info/">http://270a.info/</a>. Utilising this method of access from within various types of articles on the Web, makes it possible to build applications which put more focus on user-interfaces rather than handling different data models case by case, or burdensome data integration tasks. Furthermore, having easy access to highly structured multidimensional data - essentially through an <code>HTTP GET</code> request - makes it desirable to create static and real-time visualisations.</p> <p><a href="https://github.com/mgskjaeveland/sgvizler">Sgvizler</a> is a SPARQL result set visualisation JavaScript library that uses Google Charts API to create sparkline images [<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-6">6</a>]. These are block-level raster images.</p> <p>Investigation of analysis and visualisation of piracy reports have been conducted through endpoint querying with a <a href="http://cran.r-project.org/web/packages/SPARQL/index.html">SPARQL client for R</a> [<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-7">7</a>].</p> <p><a href="http://aksw.org/Projects/CubeViz">CubeViz</a> was developed to visualise multidimensional statistical data. It is a faceted browser, which utilizes the RDF Data Cube vocabulary, with a chart visualisation component [<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-8">8</a>].</p> <p><a href="http://csarven.ca/linked-statistical-data-analysis">Linked Statistical Data Analysis</a> [<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-9">9</a>], presents a way to reuse data through federated SPARQL queries, and generation of statistical analyses and scatter plots. The <a href="http://stats.270a.info/">stats.270a.info</a> service stores computed analysis, and makes it possible for future discovery.</p> </div> </section> </div> </section> <section id="data-provision" inlist="" rel="schema:hasPart" resource="#data-provision"> <h2 property="schema:name">Data Provision</h2> <div datatype="rdf:HTML" property="schema:description"> <p>In order to use sparqlines, data has to be both well-formed and available over a SPARQL endpoint. Here we briefly discuss both of these requirements.</p> <p>The RDF Data Cube vocabulary is used to describe multidimensional statistical data. It makes it possible to represent significant amounts of heterogeneous statistical data as Linked Data which can be discovered and identified in a uniform way. To qualify for consumption as a sparqline, the data must conform with some of the integrity constraints of the RDF Data Cube model, e.g., IC-1 (Unique DataSet), IC-11 (All dimensions required), IC-12 (No duplicate observations), IC-14 (All measures present).</p> <p>Additional enrichments on the data cubes can improve their discovery and reuse. Examples include but not limited to; providing human-readable <em>labels</em> for the datasets (with language tags), <em>classifications</em>, and <em>data structure definition</em>, as well as <em>provenance</em> level data like license, last updated.</p> <p>In order to allow user interfaces which can utilise a group of observations in a dataset, <em>slices</em> should be made available in the data. This enables consuming applications to dissect datasets (through SPARQL queries) for arbitrary subsets of observations. For example, while it is possible to construct a general query to get all of the observations in a dataset which have a particular dimension, it may be preferable to only query for such subsets provided that their structures can be identified and externally referenced. In the case of sparklines, one common use case for slices is to present data in time-series.</p> <p>SPARQL queries are used to filter for graph patterns in the RDF Data Cube datasets. Depending on the user interface application, there may be multiple queries made to the SPARQL endpoints in order to filter the data based on user input. For example, an initial query may be a cursory inspection to discover suitable datasets with given parameters, e.g., what the dataset is about, the type of dimensions and their values, and subsequent queries may be to retrieve the matching datasets or slices with observations and their measure values.</p> </div> </section> <section id="static-and-dynamic-sparqlines" inlist="" rel="schema:hasPart" resource="#static-and-dynamic-sparqlines"> <h2 property="schema:name">Static and Dynamic Sparqlines</h2> <div datatype="rdf:HTML" property="schema:description"> <p>The data behind a sparqline can be static: a fixed historical set to which no new points are added; or dynamic: subject to change as new data is gathered. Both of these cases are accommodated by our implementation.</p> <table> <caption>Static and Dynamic Sparklines</caption> <thead> <tr><th></th><th>Use</th><th>Methods</th><th>Example</th></tr> </thead> <tbody> <tr> <th>Static</th> <td>Historical data or a fixed snapshot</td> <td> <ul> <li>Pre-rendered SVG</li> <li>Embedded directly from datastore</li> </ul> </td> <td><embed class="sparkline" src="http://csarven.camedia/images/articles/GDP-per-capita-growth--annual---.svg" height="240" rel="schema:image" type="image/svg+xml" width="640" /></td> </tr> <tr> <th>Dynamic</th> <td>Data which may be subject to updates</td> <td> <ul> <li>Re-fetches data on page load or polls in real-time</li> <li>Embed source as API endpoint which returns the sparkline</li> </ul> </td> <td><embed class="sparkline" src="http://stats.270a.info/sparkline.svg?void:sparqlEndpoint=http%3A%2F%2Fworldbank.270a.info%2Fsparql&amp;qb:DataSet=http%3A%2F%2Fworldbank.270a.info%2Fdataset%2FNY.GDP.MKTP.CD&amp;refArea=CA" type="image/svg+xml" /> (reload article in browser)</td> </tr> </tbody> </table> </div> </section> <section id="embedding-sparqlines" inlist="" rel="schema:hasPart" resource="embedding-sparqlines"> <h2 property="schema:name">Embedding Sparqlines</h2> <div datatype="rdf:HTML" property="schema:description"> <p>Our implementation allows authors to select text they have written which describes the data they want to visualise; it searches available datasets for those relevant to the text, and lets the user choose the most appropriate if there’s more than one. The sparqline is inserted along with a reference to the source.</p> <p>A specific example workflow is demonstrated when this article is viewed in a Web browser (at its canonical URL: http://csarven.ca/sparqlines-sparql-to-sparkline). Enable the <button class="editor-enable" title="Enable editor"><i class="fa fa-i-cursor"></i>Edit</button> mode from the <button>☰</button> menu and highlight the text <samp id="interactive-annotation-example">GDP of Canada</samp>. What occurs is as follows:</p> <ol property="schema:hasPart" resource="#embedding-sparqlines-workflow" typeof="opmw:WorkflowTemplate deo:Model"> <li id="interactive-annotation-text-entry" about="#embedding-sparqlines-text-entry" typeof="opmw:WorkflowTemplateProcess" rel="opmw:isStepOfTemplate" resource="#embedding-sparqlines-workflow" property="rdfs:label">User enters text in a sentence e.g., <samp>GDP of Canada</samp>.</li> <li id="interactive-annotation-text-selection" about="#embedding-sparqlines-text-selection" typeof="opmw:WorkflowTemplateProcess" rel="opmw:isStepOfTemplate" resource="#embedding-sparqlines-workflow" property="rdfs:label">User selects text <samp>GDP of Canada</samp> with their mouse or keyboard.</li> <li id="interactive-annotation-toolbar-selection" about="#embedding-sparqlines-toolbar-selection" typeof="opmw:WorkflowTemplateProcess" rel="opmw:isStepOfTemplate" resource="#embedding-sparqlines-workflow" property="rdfs:label">The user select the <q>sparkline</q> option from presented authoring toolbar.</li> <li id="interactive-annotation-tokenise-text" about="#embedding-sparqlines-tokenise-text" typeof="opmw:WorkflowTemplateProcess" rel="opmw:isStepOfTemplate" resource="#embedding-sparqlines-workflow" property="rdfs:label">The input text is split into two: 1) <samp>GDP</samp> and 2) <samp>Canada</samp> segments, whereby the first term is the concept, and the second is a reference area. Reference areas are disambiguated against an internal dictionary.</li> <li id="interactive-annotation-sparql-query-for-input" about="#embedding-sparqlines-sparql-query-for-input" typeof="opmw:WorkflowTemplateProcess" rel="opmw:isStepOfTemplate" resource="#embedding-sparqlines-workflow" property="rdfs:label">System constructs a SPARQL query URL and sends it to the World Bank Linked Dataspace endpoint, looking for a graph pattern where the datasets of labels have <q>GDP</q> in them in which there is at least one observation for the reference area <q>Canada</q>.</li> <li id="interactive-annotation-dataset-selection" about="#embedding-sparqlines-dataset-selection" typeof="opmw:WorkflowTemplateProcess" rel="opmw:isStepOfTemplate" resource="#embedding-sparqlines-workflow" property="rdfs:label">User is given a list of datasets to select from which match the above criteria, and the user selects desired dataset.</li> <li id="interactive-annotation-sparql-query-observations" about="#embedding-sparqlines-sparql-query-observations" typeof="opmw:WorkflowTemplateProcess" rel="opmw:isStepOfTemplate" resource="#embedding-sparqlines-workflow" property="rdfs:label">System sends a SPARQL query to get the observations of the selected dataset for Canada.</li> <li id="interactive-annotation-create-sparkline" about="#embedding-sparqlines-create-sparkline" typeof="opmw:WorkflowTemplateProcess" rel="opmw:isStepOfTemplate" resource="#embedding-sparqlines-workflow" property="rdfs:label">A sparkline is created and displayed for the user, also indicating the number of observations it has.</li> <li id="interactive-annotation-embed-sparkline" about="#embedding-sparqlines-embed-sparkline" typeof="opmw:WorkflowTemplateProcess" rel="opmw:isStepOfTemplate" resource="#embedding-sparqlines-workflow" property="rdfs:label">If the user is happy with this visualisation they include it in the text. A hyperlink to the dataset, and a sparkline SVG is inserted back into the sentence replacing <samp>GDP of Canada</samp> with <samp>GDP per capita growth (annual %)</samp>.</li> </ol> <p>Figure [<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#figure-dokieli-sparkline">2</a>] is a video screencast of this interaction.</p> <figure id="figure-dokieli-sparqlines" rel="schema:hasPart" resource="#figure-dokieli-sparqlines"> <video controls="controls" height="400" id="video-dokieli-sparqlines" poster="https://dokie.li/media/images/GDP-per-capita-growth--annual---.svg" preload="none" rel="schema:hasPart" width="800"> <source about="#video-dokieli-sparqlines" rel="schema:hasPart" resource="https://dokie.li/media/video/dokieli-sparqlines.webm" src="https://dokie.li/media/video/dokieli-sparqlines.webm" type="video/webm" typeof="fabio:Film" /> </video> <figcaption property="schema:name">Video of Sparqlines interaction in dokieli</figcaption> </figure> <style type="text/css">/*<![CDATA[*/ #embedding-sparqlines button { font-family:sans-serif; font-size:initial; font-weight:normal; line-height:1; background-color:inherit; border:0 none; margin:0; padding:0; } #embedding-sparqlines .editor-enable i, #embedding-sparqlines .editor-disable i { margin-right:0.25em; } #embedding-sparqlines .editor-disable { background-color:#eee; } /*]]>*/</style> </div> </section> <section id="semantic-publishing"> <h2 property="schema:name">Semantic Publishing</h2> <div datatype="rdf:HTML" property="schema:description"> <p>Our implementation in dokieli automatically includes semantic annotations within the embedded sparqlines. The sparqline resource has its own URI that can be used for global referencing. The RDF statements are represented using the HTML+RDFa syntax, and they preserve the following information:</p> <ul> <li>The part of the document to which the sparqline belongs (<code>rel="schema:hasPart"</code>).</li> <li>The human-readable name for the figure (based on the dataset used), where it was derived from (the <code>qb:DataSet</code> instance), and the generated SVG.</li> <li>The SVG resource has statements to indicate: <ul> <li>linked statistical dataset which was used (<code>rel="prov:wasDerivedFrom"</code>).</li> <li>human-readable name of the dataset (<code>property="schema:name"</code>).</li> <li>license for the generated SVG (<code>rel="schema:license"</code>).</li> <li>further information for each <code>qb:Observation</code> (<code>rel="rdfs:seeAlso"</code>).</li> </ul> </li> </ul> <p>This information can be discovered and parsed as RDF, thus making easy to access and reuse by third-party applications. For example, another author can cite or include these sparqlines in their work.</p> </div> </section> <section id="discussion-and-conclusions" inlist="" rel="schema:hasPart" resource="#discussion-and-conclusions"> <h2 property="schema:name">Discussion and Conclusions</h2> <div datatype="rdf:HTML" property="schema:description" resource="#discussion-and-conclusions" typeof="deo:Discussion"> <p>We have presented a preliminary implementation of sparklines generated from SPARQL endpoints and embedded directly through authoring tool. This allows authors to visualise their data in an optimal way without breaking their workflow. However, there is a lot of scope for future work in this area. We now discuss some areas for further development.</p> <p><strong>Design principles</strong>: Tufte makes recommendations on readability, as well as applying Cleveland’s analytical method of choosing aspect ratios <em>banking to 45°</em> [<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-2">2</a>, <a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-10">10</a>, <a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-11">11</a>]. Cleveland’s method has been extended to generate banked sparklines by providing the vertical dimension to fit a typographical line. These approaches help maximize the clarity of the line segments [<a href="http://csarven.ca/sparqlines-sparql-to-sparkline#ref-12">12</a>]. Applying these methods is a future implementation in dokieli (<a href="https://github.com/linkeddata/dokieli/issues/159">issue 159</a>).</p> <p><strong>Dataset interaction</strong>: Building on existing work in faceted searching and browsing of RDF data, authors can explore suitable datasets with a combination of searching using natural-language and filtering through available datasets and dimensions of interest. This approach is convenient for datasets in RDF Data Cubes since they are highly structured and classified. Further work is needed to improve the process for disambiguation of the author’s input in natural language in order to discover appropriate URIs in the dataset.</p> <p><strong>Privacy considerations</strong>: Many researchers collect experimental data which has sensitive or identifiable information. This information should not be exposed through public SPARQL endpoints. Measures such as access control lists can allow researchers to generate sparqlines over sensitive data.</p> <p><strong>Data availability</strong>: SPARQL endpoints are notoriously unreliable and they may have high setup costs for new datasets. Applications which rely on endpoints to generate sparqlines with dynamic data, may want to initially include a local cached copy from the last access point in the article. The application can then asynchronously fetch or subscribe for new updates.</p> </div> </section> <section id="acknowledgements" inlist="" rel="schema:hasPart" resource="#acknowledgements"> <h2 about="#acknowledgements" property="schema:name" typeof="deo:Acknowledgements">Acknowledgements</h2> <div datatype="rdf:HTML" property="schema:description"> <p>The motivation and work on sparqlines was inspired by Edward Tufte’s education and popularisation of sparklines. Special thanks to <a href="http://rhiaro.co.uk/#me">Amy Guy</a> and <a href="http://people.csail.mit.edu/ilaria/">Ilaria Liccardi</a> for their great support and tireless nagging to get this written up, as well as <a href="http://mynarz.net/">Jindřich Mynarz</a> for help with SPARQL query optimisations.</p> </div> </section> <section id="references"> <h2>References</h2> <div> <ol> <li id="ref-1">Zelchenko, P., Medved, M.: QuoteTracker, <a href="http://pete.zelchenko.com/portfolio/screen/2gk.htm" rel="schema:citation">http://pete.zelchenko.com/portfolio/screen/2gk.htm</a></li> <li id="ref-2">Tufte, E.: Beautiful Evidence, Graphics Press, 2006, ISBN 9781930824164, <a href="http://www.worldcat.org/title/beautiful-evidence/oclc/70203994&amp;referer=brief_results" rel="schema:citation">http://www.worldcat.org/title/beautiful-evidence/oclc/70203994&amp;referer=brief_results</a></li> <li id="ref-3">P. Meharia: Use of Visualization in Digital Financial Reporting: The effect of Sparkline (2012). Theses and Dissertations--Business Administration. <a href="http://uknowledge.uky.edu/busadmin_etds/1/">Paper 1</a>, <a href="http://uknowledge.uky.edu/cgi/viewcontent.cgi?article=1000&amp;context=busadmin_etds" rel="schema:citation">http://uknowledge.uky.edu/cgi/viewcontent.cgi?article=1000&amp;context=busadmin_etds</a></li> <li id="ref-4">Google Docs Sparklines, <a href="https://support.google.com/docs/answer/3093289?hl=en">https://support.google.com/docs/answer/3093289?hl=en</a></li> <li id="ref-5">Cyganiak, R., Reynolds, D.: The RDF Data Cube vocabulary, W3C Recommendation, 2014, <a href="https://www.w3.org/TR/vocab-data-cube/" rel="schema:citation">https://www.w3.org/TR/vocab-data-cube/</a></li> <li id="ref-6">Skjæveland, M. G.: Sgvizler: A JavaScript Wrapper for Easy Visualization of SPARQL Result Sets, 2012, <a href="http://2012.eswc-conferences.org/sites/default/files/eswc2012_submission_303.pdf">http://2012.eswc-conferences.org/sites/default/files/eswc2012_submission_303.pdf</a></li> <li id="ref-7">Hage, W. R. v., Marieke v., Malaisé., V.: Linked Open Piracy: A story about e-Science, Linked Data, and statistics (2012), <a href="http://www.few.vu.nl/~wrvhage/papers/LOP_JoDS_2012.pdf" rel="schema:citation">http://www.few.vu.nl/~wrvhage/papers/LOP_JoDS_2012.pdf</a></li> <li id="ref-8">Percy E. Rivera Salas, P. E. R., Mota, F. M. D., Martin, M., Auer, S., Breitman, K., Casanova, M. A.: Publishing Statistical Data on the Web, ISWC (2012), <a rel="schema:citation" href="http://svn.aksw.org/papers/2012/ESWC_PublishingStatisticData/public.pdf">http://svn.aksw.org/papers/2012/ESWC_PublishingStatisticData/public.pdf</a></li> <li id="ref-9">Capadisli, S., Auer, S. Riedl, R.: Linked Statistical Data Analysis, ISWC SemStats (2013), <a href="http://csarven.ca/linked-statistical-data-analysis" rel="schema:citation">http://csarven.ca/linked-statistical-data-analysis</a></li> <li id="ref-10">Edward Tufte forum: Sparkline theory and practice Edward Tufte, <a href="http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR&amp;topic_id=1" rel="schema:citation">http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001OR&amp;topic_id=1</a></li> <li id="ref-11">Cleveland, W.: Visualizing Data, Hobart Press, 1993, ISBN 9780963488404, <a href="http://dl.acm.org/citation.cfm?id=529269" rel="schema:citation">http://dl.acm.org/citation.cfm?id=529269</a></li> <li id="ref-12">Heer, J., Maneesh, A.: Multi-Scale Banking to 45°, IEEE Transactions on Visualization and Computer Graphics, Vol. 12, No. 5, 2006, <a href="http://vis.berkeley.edu/papers/banking/2006-Banking-InfoVis.pdf" rel="schema:citation">http://vis.berkeley.edu/papers/banking/2006-Banking-InfoVis.pdf</a></li> </ol> </div> </section> </div> http://csarven.ca/sparqlines-sparql-to-sparkline Sun, 01 May 2016 00:00:00 <h1 property="schema:name">Linked Data Notifications: a resource-centric communication protocol</h1> <div id="authors"> <dl id="author-name"> <dt>Authors</dt> <dd id="Sarven-Capadisli" inlist="" rel="bibo:authorList" resource="http://csarven.ca/#i"><span about="" rel="schema:creator schema:publisher schema:author"><span about="http://csarven.ca/#i" typeof="schema:Person"><a href="http://csarven.ca/" rel="schema:url"><span about="http://csarven.ca/#i" property="schema:name"><span property="schema:givenName">Sarven</span> <span property="schema:familyName">Capadisli</span></span></a></span></span>^{<a about="http://csarven.ca/#i" href="http://csarven.ca/linked-data-notifications#author-org-1" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">1</a>}^{<a href="http://csarven.ca/linked-data-notifications#author-email-1">✊</a>}</dd> <dd id="Amy-Guy" inlist="" rel="bibo:authorList" resource="https://rhiaro.co.uk/#me"><span about="" rel="schema:author"><span about="https://rhiaro.co.uk/#me" typeof="schema:Person"><a href="https://rhiaro.co.uk/" rel="schema:url"><span about="https://rhiaro.co.uk/#me" property="schema:name"><span property="schema:givenName">Amy</span> <span property="schema:familyName">Guy</span></span></a></span></span>^{<a about="https://rhiaro.co.uk/#me" href="http://csarven.ca/linked-data-notifications#author-org-2" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Edinburgh">2</a>}^{<a href="http://csarven.ca/linked-data-notifications#author-email-2">🐦</a>}</dd> <dd id="Christoph-Lange" inlist="" rel="bibo:authorList" resource="http://eis.iai.uni-bonn.de/ChristophLange"><span about="" rel="schema:author"><a about="http://eis.iai.uni-bonn.de/ChristophLange" href="https://langec.wordpress.com/about/" property="schema:name" rel="schema:url" typeof="schema:Person">Christoph Lange</a></span>^{<a about="http://eis.iai.uni-bonn.de/ChristophLange" href="http://csarven.ca/linked-data-notifications#author-org-1" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">1</a>}^{<a href="http://csarven.ca/linked-data-notifications#author-email-3">∫</a>}</dd> <dd id="Sören-Auer" inlist="" rel="bibo:authorList" resource="http://eis.iai.uni-bonn.de/SoerenAuer"><span about="" rel="schema:author"><a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://eis.iai.uni-bonn.de/SoerenAuer.html" property="schema:name" rel="schema:url" typeof="schema:Person">Sören Auer</a></span>^{<a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://csarven.ca/linked-data-notifications#author-org-1" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">1</a>}^{<a href="http://csarven.ca/linked-data-notifications#author-email-4">⚛</a>}</dd> <dd id="Andrei-Sambra" inlist="" rel="bibo:authorList" resource="https://deiu.me/profile#me"><span about="" rel="schema:author"><a about="https://deiu.me/profile#me" href="https://deiu.me/profile#me" property="schema:name" rel="schema:url" typeof="schema:Person">Andrei Sambra</a></span>^{<a about="https://deiu.me/profile#me" href="http://csarven.ca/linked-data-notifications#author-org-3" rel="schema:memberOf" resource="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology">3</a>}^{<a href="http://csarven.ca/linked-data-notifications#author-email-5">💻</a>}</dd> <dd id="Tim-Berners-Lee" inlist="" rel="bibo:authorList" resource="https://www.w3.org/People/Berners-Lee/card#i"><span about="" rel="schema:author"><a about="https://www.w3.org/People/Berners-Lee/card#i" href="https://www.w3.org/People/Berners-Lee/" property="schema:name" rel="schema:url" typeof="schema:Person">Tim Berners-Lee</a></span>^{<a about="https://www.w3.org/People/Berners-Lee/card#i" href="http://csarven.ca/linked-data-notifications#author-org-3" rel="schema:memberOf" resource="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology">3</a>}^{<a href="http://csarven.ca/linked-data-notifications#author-email-6">🕸</a>}</dd> </dl> <ul id="author-org"> <li id="author-org-1">¹Enterprise Information Systems Department, <a about="http://dbpedia.org/resource/University_of_Bonn" href="http://uni-bonn.de/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Bonn</a>, Bonn, DE</li> <li id="author-org-2">²School of Informatics, <a about="http://dbpedia.org/resource/University_of_Edinburgh" href="http://inf.ed.ac.uk/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Edinburgh</a>, Edinburgh, UK</li> <li id="author-org-3">³Decentralized Information Group, CSAIL, <a about="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology" href="https://mit.edu/" property="schema:name" rel="schema:url" typeof="schema:Organization">MIT</a>, Cambridge, US</li> </ul> <ul id="author-email"> <li id="author-email-1">^✊<a about="http://csarven.ca/#i" href="http://csarven.camailto:info@csarven.ca" rel="schema:email">info@csarven.ca</a></li> <li id="author-email-2">^🐦<a about="https://rhiaro.co.uk/#me" href="http://csarven.camailto:amy@rhiaro.co.uk" rel="schema:email">amy@rhiaro.co.uk</a></li> <li id="author-email-3">^∫<a about="http://eis.iai.uni-bonn.de/ChristophLange" href="http://csarven.camailto:langec@cs.uni-bonn.de" rel="schema:email">langec@cs.uni-bonn.de</a></li> <li id="author-email-4">^⚛<a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://csarven.camailto:auer@cs.uni-bonn.de" rel="schema:email">auer@cs.uni-bonn.de</a></li> <li id="author-email-5">^💻<a about="https://deiu.me/profile#me" href="http://csarven.camailto:deiu@mit.edu" rel="schema:email">deiu@mit.edu</a></li> <li id="author-email-6">^🕸<a about="https://www.w3.org/People/Berners-Lee/card#i" href="http://csarven.camailto:timbl@w3.org" rel="schema:email">timbl@w3.org</a></li> </ul> </div> <dl id="document-identifier"> <dt>Identifier</dt> <dd><a href="http://csarven.ca/linked-data-notifications" rel="owl:sameAs">http://csarven.ca/linked-data-notifications</a></dd> </dl> <dl id="document-in-reply-to"> <dt>In Reply To</dt> <dd><a href="https://linkedresearch.org/calls" rel="as:inReplyTo">Calls for Linked Research</a></dd> <dd><a href="http://2017.eswc-conferences.org/call-papers" rel="as:inReplyTo">ESWC 2017 Call for Papers</a></dd> </dl> <dl id="document-inbox"> <dt>Notifications Inbox</dt> <dd><a href="https://linkedresearch.org/inbox/csarven.ca/linked-data-notifications/" rel="ldp:inbox">inbox/</a></dd> </dl> <dl id="document-annotation-service"> <dt>Annotation Service</dt> <dd><a href="https://linkedresearch.org/annotation/csarven.ca/linked-data-notifications/" rel="oa:annotationService">annotation/</a></dd> </dl> <dl id="document-published"> <dt>Published</dt> <dd><time datatype="xsd:dateTime" content="2016-12-15T00:00:00Z" datetime="2016-05-01T00:00:00Z" property="schema:datePublished">2016-05-01</time></dd> </dl> <dl id="document-modified"> <dt>Modified</dt> <dd><time datatype="xsd:dateTime" content="2016-12-15T00:00:00Z" datetime="2016-12-15T00:00:00Z" property="schema:dateModified">2016-12-15</time></dd> </dl> <dl id="document-license"> <dt>License</dt> <dd><a href="https://creativecommons.org/licenses/by/4.0/" rel="schema:license" title="Creative Commons Attribution 4.0 Unported">CC BY 4.0</a></dd> </dl> <div id="content"> <section id="abstract"> <h2>Abstract</h2> <div datatype="rdf:HTML" property="schema:abstract"> <p>In this article we describe the Linked Data Notifications (LDN) protocol, which is a <a href="https://www.w3.org/TR/ldn/">W3C Candidate Recommendation</a>. Notifications are sent over the Web for a variety of purposes, for example, by social applications. The information contained within a notification is structured arbitrarily, and typically only usable by the application which generated it in the first place. In the spirit of Linked Data, we propose that notifications should be reusable by multiple authorised applications. Through separating the concepts of <em>senders</em>, <em>receivers</em> and <em>consumers</em> of notifications, and leveraging Linked Data principles of shared vocabularies and URIs, LDN provides a building block for decentralised Web applications. This permits end users more freedom to switch between the online tools they use, as well as generating greater value when notifications from different sources can be used in combination. We situate LDN alongside related initiatives, and discuss additional considerations such as security and abuse prevention measures. We evaluate the protocol’s effectiveness by analysing multiple, independent implementations, which pass a suite of formal tests and can be demonstrated interoperating with each other.</p> </div> </section> <section id="keywords"> <h2>Keywords</h2> <div> <ul rel="schema:about"> <li><a href="https://en.wikipedia.org/wiki/Communications_protocol" resource="http://dbpedia.org/resource/Communications_protocol">Communications protocol</a></li> <li><a href="https://en.wikipedia.org/wiki/Decentralization" resource="http://dbpedia.org/resource/Decentralization">Decentralisation</a></li> <li><a href="https://en.wikipedia.org/wiki/Linked_data" resource="http://dbpedia.org/resource/Linked_data">Linked Data</a></li> <li><a href="https://en.wikipedia.org/wiki/Social_web" resource="http://dbpedia.org/resource/Social_web">Social web</a></li> </ul> </div> </section> <section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction"> <h2 property="schema:name">Introduction</h2> <div datatype="rdf:HTML" property="schema:description"> <p>Notifications are sent over the Web for a variety of purposes, including social applications: <q>You have been invited to a graduation party!</q>, <q>Tim commented on your blog post!</q>, <q>Liz tagged you in a photo</q>. The notification data may be displayed to a human to acknowledge, or used to trigger some other application-specific process (or both). <span id="issue" about="#design-issue" datatype="rdf:HTML" property="schema:description" rel="dio:generatedByIntent" resource="#design-intent" typeof="dio:DesignIssue">In a decentralised architecture, notifications can be a key element for federation of information, and application integration. However in <span rel="dio:hasStatus" resource="#design-issue-status" typeof="dio:Active">centralised systems which prevail today</span>, this data is structured arbitrarily and typically only usable by the application that generated it in the first place. Current efforts towards <em>re-decentralising</em> the Web [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-1">1</a>, <a class="ref" href="http://csarven.ca/linked-data-notifications#ref-2">2</a>, <a class="ref" href="http://csarven.ca/linked-data-notifications#ref-3">3</a>] are moving towards architectures in which data storage is decoupled from application logic, freeing end users to switch between applications, or to let multiple applications operate over the same data. So far, notifications are considered to be <em>ephemeral</em> resources which may disappear after transport, and thus are excluded from being designed for reuse.</span></p> <p id="design-intent" about="#design-intent" datatype="rdf:HTML" property="schema:description" rel="dio:generatesIssue" resource="#design-issue" typeof="dio:Intent">We argue that notification data should not be locked into particular systems. We designed the <em>Linked Data Notifications (LDN)</em> protocol to support sharing and reuse of notifications <em>across</em> applications, regardless of how they were generated or what their contents are. We describe how the principles of identification, addressability and semantic representation can be applied to notifications on the Web. Specifying LDN as a formal protocol allows independently implemented, heterogeneous applications which generate and use notifications, to seamlessly work together. Thus, LDN supports the decentralisation of the Web as well as encourages the generation and consumption of Linked Data.</p> <p about="#design-decision" datatype="rdf:HTML" property="schema:description" rel="dio:governsDesign" resource="#protocol" typeof="dio:DesignDecision">We build on existing W3C standards and Linked Data principles. In particular, the storage of notifications is compatible with the <cite>Linked Data Platform</cite> standard; notifications are identified by HTTP URIs; and notification contents are available as JSON-LD. A key architectural decision is the separation of concerns between <em>senders</em>, <em>receivers</em>, and <em>consumers</em> of notifications. Implementations of the protocol can play one or more of these roles, and interoperate successfully with implementations playing the complementary roles. This means that notifications generated by one application can be reused by a completely different application, accessed via the store where the notification data resides, through shared Linked Data vocabularies. LDN also pushes the decentralised approach further by allowing any <em>target</em> resource to advertise its Inbox anywhere on the Web; that is, targets do not need to be coupled to or controlled by a receiver, and can make use of a third-party <em>Inbox as a service</em>.<span about="#design-decision" rel="dio:supportedBy"><meta resource="http://csarven.ca/#i" /><meta resource="https://rhiaro.co.uk/#me" /></span></p> <p>LDN is a W3C <a about="" rel="cito:citesAsAuthority cito:citesAsSourceDocument" href="https://www.w3.org/TR/ldn/">Candidate Recommendation</a> via the <cite><a href="https://www.w3.org/wiki/Socialwg">Social Web Working Group</a></cite> [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-4">4</a>]. The first two authors of this article are the co-editors of the specification.</p> <p>Use cases for decentralised notifications are particularly evident in social networking (status updates, interactions, games); scholarly communication (reviews, citations); and changes of state of resources (datasets, versioning, sensor readings, experimental observations). We describe the requirements which guided the development of the protocol and discuss related work, including current alternative approaches and complementary protocols which can work alongside LDN. We summarise the protocol itself, and specific architectural considerations that were made. We built a test suite which can be used to confirm that implementations conform with the specification, and we describe 17 implementations which interoperate with each other.</p> <div about="" id="concept-scheme" rel="schema:hasPart" resource="#concept-scheme"> <p resource="#concept-scheme" typeof="skos:ConceptScheme"><span property="skos:definition">As the following terms used throughout this article may be subject to different interpretations by different communities, we provide some definitions here.</span></p> <p rel="skos:hasTopConcept">By <strong about="#concept-decentralisation" id="concept-decentralisation" property="skos:prefLabel" rel="skos:topConceptOf" resource="#concept-scheme" typeof="skos:Concept">decentralisation</strong>, we mean <span about="#concept-decentralisation" property="skos:definition">data and applications are loosely coupled, and users are empowered to choose where their data is stored or held. We focus on Web-based decentralisation, where content is transported over HTTP, and resources are identified with URIs.</span> An <strong about="#concept-inbox" id="concept-inbox" property="skos:prefLabel" rel="skos:topConceptOf" resource="#concept-scheme" typeof="skos:Concept">Inbox</strong> is <span about="#concept-inbox" property="skos:definition">a container or directory (attached to a Web resource) which is used to store and serve a collection of notifications.</span> A <strong about="#concept-notification" id="concept-notification" property="skos:prefLabel" rel="skos:topConceptOf" resource="#concept-scheme" typeof="skos:Concept">notification</strong> is <span about="#concept-notification" property="skos:definition">a retrievable resource which returns RDF. The contents of notifications are intended to describe a change in state of some other resource, or contain new information for the attention of a user or process, and may be subject to constraints of the Inbox it is contained in.</span> </p> </div> <!-- <p>Using this article as the target for notifications, we welcome readers' feedback via LDN.</p> --> </div> </section> <section id="related-work" inlist="" rel="schema:hasPart" resource="#related-work"> <h2 property="schema:name">Related Work</h2> <div datatype="rdf:HTML" property="schema:description" resource="#related-work" typeof="deo:RelatedWork"> <p>Here we review previous and ongoing efforts towards delivering notifications in a decentralised manner. Many systems which make use of notifications operate either in a completely centralised way, or are decentralised only in the sense that different instances of the <em>same</em> codebase need to interoperate; we restrict our review to mechanisms which do not expect the notification to be received or used only by the same software or platform which sent it.</p> <p>The contents of a notification is either: 1) URLs, indicating relations between Web resources, or 2) a ‘fat ping’ containing a blob of information. Semantic Pingback, Webmention, and Provenance Pingback follow the first form, and are also known as <cite>linkbacks</cite>, the suite of protocols that essentially allows Web documents to automatically reciprocate hyperlinks. This has the advantage that a verification mechanism can be tightly specified (the URL of the target must appear in the content of the source), but the disadvantage that notifications are only available for use cases involving Web publishing.</p> <p id="semantic-pingback-and-webmention"><cite><a href="https://aksw.github.io/SemanticPingback/">Semantic Pingback</a></cite> [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-2">2</a>] and <cite><a href="https://www.w3.org/TR/webmention">Webmention</a></cite> [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-5">5</a>] both update the original <cite><a href="http://www.hixie.ch/specs/pingback/pingback">Pingback</a></cite> [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-6">6</a>] mechanism by replacing the XML-RPC transport mechanism by a <code>x-www-form-urlencoded</code> request with two parameters (<code>source</code> and <code>target</code>). Resources which are the target for a notification advertise the respective receiving service or endpoint via a <code>Link</code> relation, either in HTTP headers or HTML. Semantic Pingback additionally enables discovery of the Pingback service where target is available as RDF. While the content at source may indicate (in any convention or serialisation format) the type of relation between the source and target URLs, this information about the relation is not transmitted to the receiver’s endpoint; only the source and target URLs are sent. As such, there is also no way to distinguish between multiple potential mentions of the target at the source; this is left up to the receiver to interpret. Semantic Pingback does encourage generation of additional semantics about the relation(s) between the source and the target by processing the source as RDF if possible, and also defines specific ways for a receiving server to handle incoming pingback data in order to add the source data to an RDF knowledge base [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-2">2</a>]. Beyond verifying that the source contains the URL of the target, Webmention does not specify any further requirements of the receiving server; nor is it expected that “mentions” are retrievable once they have been sent. </p> <p id="provenance-pingback">A <cite><a href="http://www.w3.org/TR/prov-aq/#provenance-pingback">Provenance Pingback</a></cite> endpoint is also advertised via the HTTP <code>Link</code> header; it accepts a list of URIs for provenance records describing uses of the resource [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-7">7</a>]. Provenance Pingback does not specify any further behaviour by the receiving server, but the contents at the URIs listed in the notification body must be semantic data.</p> <p>Other notification mechanisms send more information than just URLs in the notification body; due to each mechanism’s focused use case, the payload is restricted to a particular vocabulary.</p> <p><cite><a href="http://www.cibiv.at/~niko/dsnotify/">DSNotify</a></cite> is a centralised service which crawls datasets and observes changes to links with the specific use case of preserving link integrity between Linked Open Data resources. Third-party applications can register with the sending service to receive notifications of changes in the form of a specific XML payload [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-8">8</a>]. With the <cite><a href="https://www.w3.org/2001/sw/wiki/SparqlPuSH">sparqlPuSH</a></cite> service, users may input a SPARQL query, the results of which are the specific updates they are interested in. The query is run periodically by the service, and the results are converted to RSS and Atom feeds, which is sent to a <a href="http://pubsubhubbub.github.io/PubSubHubbub/pubsubhubbub-core-0.4.html">PubSubHubbub</a> hub to which the user can subscribe [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-9">9</a>]. The <cite><a href="http://www.openarchives.org/rs/notification/1.0/notification">ResourceSync Change Notification</a></cite> specification also sends update notifications via a <abbr title="PubSubHubbub">PuSH</abbr> hub, this time with an XML payload based on the Sitemap format [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-10">10</a>]. Each of these mechanisms is triggered by subscription requests. That is, a user must actively solicit messages from a particular service, rather than having a way for a service to select a notification target and autonomously discover where to send notifications to.</p> </div> </section> <section id="requirements-and-design-considerations" inlist="" rel="schema:hasPart" resource="#requirements-and-design-considerations"> <h2 property="schema:name">Requirements and Design Considerations</h2> <div datatype="rdf:HTML" property="schema:description"> <p>In this section we discuss our considerations for a <span about="#design-intent-linked-data" datatype="rdf:HTML" property="schema:description" typeof="dio:DesignIntent">Web notification protocol that conforms to the Linked Data design principles</span>, as well as <span about="#design-intent-best-practices" datatype="rdf:HTML" property="schema:description" typeof="dio:DesignIntent">best practices for applications</span>. We use these considerations to establish both concrete requirements and points of implementation-specific flexibility for the protocol.</p> <section id="modularity" inlist="" rel="schema:hasPart" resource="#modularity"> <h3 property="schema:name">R1 Modularity</h3> <div about="#modularity" datatype="rdf:HTML" property="schema:description" rel="dio:addressedBy" resource="#design-intent" typeof="dio:DesignRequirement"> <p>To encourage modularity of applications, one should differentiate between different classes of implementation of the protocol. Two parties are involved in the creation of a notification: a <em>sender</em>, generating the notification data, and a <em>receiver</em>, storing the created resource. We also have the role of a <em>consumer</em>, which reads the notification data and repurposes it in some way. A software implementation can of course play two or all three of these roles; the important part is that it need not. A consuming application can read and use notification data without being concerned about ever sending or storing notifications.</p> </div> </section> <section id="reusable-notifications" inlist="" rel="schema:hasPart" resource="#reusable-notifications"> <h3 property="schema:name">R2 Reusable notifications</h3> <div about="#reusable-notifications" datatype="rdf:HTML" property="schema:description" rel="dio:addressedBy" resource="#design-intent" typeof="dio:DesignRequirement"> <p>The relationship between the <em>consumer</em> and <em>receiver</em> roles is key to notifications being reusable. A consumer must be able to autonomously find the location of notifications for or about the particular resource it is interested in. To achieve this we place a requirement on the receiver to expose notifications it has been sent in such away to permit other applications to access them; and specify how any resource can advertise its receiving endpoint for consumers to discover. To promote fair use or remixing of notification contents, applications can incorporate rights and licensing information into the data. Similarly, applications may include additional information on licensing resources that the notification refers to. The presence of this type of information is important for consumers to assess the (re)usability of data.</p> </div> </section> <section id="persistence-and-retrievability" inlist="" rel="schema:hasPart" resource="#persistence-and-retrievability"> <h3 property="schema:name">R3 Persistence and Retrievability</h3> <div about="#persistence-and-retrievability" datatype="rdf:HTML" property="schema:description" rel="dio:addressedBy" resource="#design-intent" typeof="dio:DesignRequirement"> <meta rel="dio:addressedBy" resource="#design-intent-best-practices" /> <meta rel="dio:identifies" resource="#design-issue-optimising-implementation" /> <p>There is a social expectation and technical arguments for ensuring the persistence of identifiers of Web resources [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-11">11</a>]. This is inconsistent with the traditionally ephemeral nature of notifications. Applications may benefit from referring to or reusing notifications if the notifications are known to be available in the long term, or indicate their expected lifespan [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-12">12</a><!-- , <a href="https://www.w3.org/TR/dwbp/#UniqueIdentifiers" title="Best Practice 9: Use persistent URIs as identifiers of datasets"></a>, <a href="https://tools.ietf.org/html/rfc7089"></a>-->].</p> <p>A <em>RESTful architecture</em> [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-13">13</a>] is well suited for persistent notifications, as it involves organisation of atomic resources, their discovery and description, and a lightweight API for the <abbr title="create, read, update, and delete">CRUD</abbr> (create, read, update, and delete) operations [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-14">14</a>]. This enforces the notion that notifications are considered resources in their own right, with their own dereferencable URIs.</p> <p>We need to consider both the needs of software systems and humans when large amounts of notification data are being generated and shared between diverse applications which may be operating without knowledge of each other. To organise and manage large amount of notifications over time, mechanisms should be in place to break representations of collections of notifications into multiple paged responses that may be easier to consume by applications.</p> <p>Relatedly, receivers may carry out resource management or garbage collection, or permit consumers or other applications to do so. For example, an application to consume messages might let an authenticated and authorised user ‘mark as read’ by adding a triple to the notification contents.</p> </div> </section> <section id="adaptability" inlist="" rel="schema:hasPart" resource="#adaptability"> <h3 property="schema:name">R4 Adaptability</h3> <div about="#adaptability" datatype="rdf:HTML" property="schema:description" typeof="dio:DesignRequirement"> <meta rel="dio:addressedBy" resource="#design-intent-linked-data" /> <meta rel="dio:identifies" resource="#design-issue-data-formats" /> <p>Linked Data applications benefit from domain-driven designs; that is, functionality being small and focussed on a particular purpose, rather than generic. We believe a notification protocol should be adaptable for different domains, but that there is no need to create multiple domain-specific notification protocols; the fundamental mechanics are the same.</p> <p id="target-representation" about="#target-representation" datatype="rdf:HTML" property="schema:description" rel="dio:refines" resource="#adaptability" typeof="dio:DesignRequirement"><strong>R4-A</strong>: Any resource may be the <em>target</em> of a notification. By target, we mean a notification may be addressed <em>to</em> the resource, be <em>about</em> the resource, or for a sender to otherwise decide that it is appropriate to draw the attention of the resource (or resource owner) to the information in the notification body. As such, any Web resource must be able to advertise an endpoint to which it can receive notifications. Resources can be RDF or non-RDF (such as an image, or CSV dataset), and may be informational (a blog post, a user profile) or non-informational (a person).</p> <p id="notification-body" about="#notification-body" datatype="rdf:HTML" property="schema:description" rel="dio:refines" resource="#adaptability" typeof="dio:DesignRequirement"><strong>R4-B</strong>: We do not purport to be able to design a notifications ontology which is appropriate for every domain. Thus we consider the <em>contents</em> of a notification to be application specific. From a sender’s perspective, we derive two core principles: a notification can contain <em>any data</em>; a notification can use <em>any vocabulary</em>. From a consumer’s perspective, interoperability between different applications occurs through vocabulary reuse, and shared understanding of terms. This is in accordance with Linked Data principles in general. The practical upshot of this is that a calendar application which consumes event invitations using the <cite><a href="https://www.w3.org/TR/rdfcal/">RDF Calendar</a></cite> vocabulary is likely to completely ignore notifications containing the <cite><a href="http://csarven.cawww.w3.org/TR/prov-o/">PROV Ontology</a></cite>, even if it finds them all stored in the same place. For two independent applications operating in the <em>same</em> domain, a shared understanding of appropriate vocabulary terms is assumed.</p> <div id="notification-verification" about="#notification-verification" datatype="rdf:HTML" property="schema:description" rel="dio:refines" resource="#adaptability" typeof="dio:DesignRequirement"> <p>However from a receiver’s perspective, exposing itself to receive any blobs of RDF data from unknown senders may be problematic. Thus, <strong>R4-C</strong>: it should be possible for the receiver to enforce restrictions and accept only notifications that are acceptable according to its own criteria (deemed by e.g., user configuration; domain-specific receivers). This can be used as an anti-spam measure, a security protection, or for attaining application and data integrity.</p> <p>Rejecting notifications which do not match a specific pattern in their contents, or the <em>shape</em> of the data, is one way to filter. For example, if the Inbox owner knows that they will only ever use a consuming application which processes friend requests, they can configure their receiver to filter out anything that does not match the pattern for a friend request, helping their consumer to be more efficient. If the notification constraints are also advertised by the receiving service as structured descriptions, generation and consumption of the notifications can be further automated. Possible specifications for doing so are W3C <cite><a href="https://www.w3.org/TR/shacl/">Shapes Constraint Language (SHACL)</a></cite> [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-15">15</a>] or <cite><a href="https://shexspec.github.io/spec/">ShEx</a></cite>.</p> <p>Receivers may wish to filter notifications by verifying the sender, through for example a whitelist or a Web of trust. This requires an authentication mechanism and since different authentication mechanisms are appropriate for different applications, the notification protocol should ideally be usable alongside various methods such as clientside certificates, e.g., WebID+TLS, token-based, e.g., OAuth 2.0, or digital signatures.</p> <p>As <q>anyone can say anything about anything</q> a receiver may choose to resolve any external resources referred to by the notification, and cross-check the notification contents against authoritative sources. This is similar to how Semantic Pingback and Webmention require fetching and parsing of the source URL to verify existence of the target link.</p> </div> </div> </section> <section id="subscribing" inlist="" rel="schema:hasPart" resource="#subscribing"> <h3 property="schema:name">R5 Subscribing</h3> <div about="#subscribing" datatype="rdf:HTML" property="schema:description" rel="dio:addressedBy" resource="#design-intent" typeof="dio:DesignRequirement"> <p>In general, applications may require that new notifications are pushed to them in real-time, or to request them at appropriate intervals. To take this into account, we expand our definition of senders, receivers and consumers with the following interaction expectations: notifications are <em>pushed</em> from senders to receivers; and <em>pulled</em> from receivers by consumers.</p> <p>Thus, an application which offers an endpoint or callback URL to which notifications should be sent directly is a receiver, and an application which fetches notifications from an endpoint on its own schedule is a consumer. Much of the related work <em>requires</em> notifications to be explicitly solicited to trigger sending. Since in a decentralised model, receivers may not be aware of possible sources for notifications, our sender-receiver relationship depends on the sender’s autonomy to make such decisions by itself. This does not preclude the scenario in which a receiver may wish to solicit notifications from a particular sender, but as there are already subscription mechanisms in wide use on the Web, we do not need to specify it as part of LDN. For example, <cite><a href="https://www.w3.org/TR/websub/">WebSub</a></cite> (recent W3C evolution of PubSubHubbub), the <cite>WebSocket Protocol</cite>, or <cite>HTTP Web Push</cite>.</p> </div> </section> <p>Given our adoption of Linked Data principles and a RESTful architecture, a further design decision was to ensure minimal compatibility with the <cite><a href="https://www.w3.org/TR/ldp/">Linked Data Platform</a></cite> (LDP) specification [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-16">16</a>]. LDP is a RESTful read-write API for RDF resources, which groups related resources together into constructs known as <q>Containers</q>. Thus, existing LDP servers can be used to store notifications, as new notifications can be created by <code>POST</code>ing RDF to a container.</p> </div> </section> <section id="protocol" inlist="" rel="schema:hasPart" resource="#protocol"> <h2 property="schema:name">The LDN Protocol</h2> <div datatype="rdf:HTML" property="schema:description" resource="#protocol" typeof="deo:Contribution dio:Design"> <p>The <dfn id="ldn">Linked Data Notifications (<abbr title="Linked Data Notifications">LDN</abbr>)</dfn> protocol describes how servers (receivers) can receive messages pushed to them by applications (senders), as well as how other applications (consumers) may retrieve those messages. Any resource can advertise a receiving endpoint (Inbox) for notification messages. Messages are expressed in RDF, and can contain arbitrary data. It is not dependent on a complete implementation of LDP, but comprises an easy-to-implement subset. LDN is a <cite><a href="https://www.w3.org/TR/ldn">W3C Candidate Recommendation</a></cite> [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-4">4</a>].</p> <figure id="figure-linked-data-notifications-overview" inlist="" rel="schema:hasPart" resource="#figure-linked-data-notifications-overview"> <object data="https://www.w3.org/TR/ldn/linked-data-notifications-overview.svg" height="305" rel="schema:image" type="image/svg+xml" width="640"></object> <figcaption property="schema:name">Overview of Linked Data Notifications</figcaption> </figure> <section id="sender-to-receiver" inlist="" rel="schema:hasPart" resource="#sender-to-receiver"> <h3 property="schema:name">Sender to receiver interactions</h3> <div datatype="rdf:HTML" property="schema:description"> <p>The following steps (in order without skipping) describe the interaction between sender and receiver:</p> <p>(1) A sender is triggered, either by a human or an automatic process, to deliver a notification; (2) The sender chooses a target resource to send notifications to; (3) The sender discovers the location of the target’s <em>Inbox</em> through the <code>ldp:inbox</code> relation in the HTTP <code>Link</code> header or RDF body of the target resource; (4) The sender creates the body of the notification according to the needs of application; (5) The sender makes a <code>POST</code> to the Inbox URL, containing the body in JSON-LD or in another serialisation acceptable by the server; (6) The receiver optionally applies filtering rules, and sends the appropriate HTTP response code to accept or reject the notification; (7) The receiver exposes the notification data (according to appropriate access control) for use by consumers.</p> </div> </section> <section id="consumer-to-receiver" inlist="" rel="schema:hasPart" resource="#consumer-to-receiver"> <h3 property="schema:name">Consumer to receiver interactions</h3> <div datatype="rdf:HTML" property="schema:description"> <p>The following steps (in order without skipping) describe the interaction between consumer and receiver:</p> <p>(1) A consumer selects a target and discovers the location of its Inbox in the same way as the sender; (2) A receiver responds to <code>GET</code> requests made to the Inbox URL with a listing of the URLs of notifications that have previously been accepted, linked to the Inbox with the <code>ldp:contains</code> predicate; <span about="#protocol" rel="dio:fulfillsRequirement" resource="#persistence-and-retrievability">(3) The receiver responds to <code>GET</code> requests made to the individual notification URLs with JSON-LD (or optionally other serialisations);</span> <span about="#protocol" rel="dio:fulfillsRequirement" resource="#reusable-notifications">(4) Following the retrieval of notification listings or individual notifications, the consumer may perform further processing, combine with some other data, or simply present the results in a suitable human-readable way.</span></p> </div> </section> <section id="example-notifications" inlist="" rel="schema:hasPart" resource="#example-notifications"> <h3 property="schema:name">Example Notifications</h3> <div datatype="rdf:HTML" property="schema:description"> <p>For more example notification payloads, see the <a href="https://www.w3.org/TR/ldn/">LDN specification</a>.</p> <figure class="listing" id="sending-notification-request" inlist="" rel="schema:hasPart" resource="#sending-notification-request"> <pre about="#sending-notification-request" property="schema:description" typeof="fabio:Script"><code>{</code> <code> "@context": { "sioc": "http://rdfs.org/sioc/ns#" }</code> <code> "@id": "",</code> <code> "@type": "sioc:Comment",</code> <code> "sioc:content": "This is a great article!",</code> <code> "as:inReplyTo": { "@id": "http://example.org/article" },</code> <code> "sioc:created_at": { "@value": "2015-12-23T16:44:21Z" }</code> <code>}</code></pre> <figcaption property="schema:name">A notification about a comment created by a user (JSON-LD).</figcaption> </figure> <figure class="listing" id="notification-qualified-relation" inlist="" rel="schema:hasPart" resource="#notification-qualified-relation"> <pre about="#notification-qualified-relation" property="schema:description" typeof="fabio:Script"><code>@prefix as: &lt;https://www.w3.org/ns/activitystreams#&gt; .</code> <code>@prefix cito: &lt;http://purl.org/spar/cito/&gt; .</code> <code>&lt;&gt; a as:Announce</code> <code> as:object &lt;https://linkedresearch.org/resources#r-903b83&gt; ;</code> <code> as:target &lt;http://csarven.ca/dokieli#architecture&gt; .</code> <code>&lt;https://linkedresearch.org/resources#r-903b83&gt;</code> <code> cito:citesAsPotentialReading</code> <code> &lt;http://csarven.ca/linked-data-notifications#protocol&gt; .</code></pre> <figcaption property="schema:name">An announcement of a specific citation relation between two entities (Turtle).</figcaption> </figure> </div> </section> </div> </section> <section id="implementations" inlist="" rel="schema:hasPart" resource="#implementations"> <h2 property="schema:name">Implementations</h2> <div datatype="rdf:HTML" property="schema:description"> <p>Here we summarise the 17 LDN implementations we are aware of to date. They are built by 10 different teams or individuals using different tool stacks (5 clientside JavaScript, 3 PHP, 3 NodeJS, 3 Python, 1 Perl, 1 Virtuoso Server Pages, 1 Java) and have submitted <a href="https://github.com/w3c/ldn/tree/master/implementations">implementation reports</a> as part of the W3C standardisation process. We note that any <a href="https://www.w3.org/wiki/LDP_Implementations">LDP implementation</a> is a conforming LDN receiver; we refer here to the ones we have tested. We discuss the value of these implementations further in the <a href="http://csarven.ca/linked-data-notifications#analysis-and-evaluation">Evaluation</a> section.</p> <table id="ldn-implementations"> <caption>LDN Implementations</caption> <thead> <tr> <th>Implementation</th> <th>Class^{<a href="http://csarven.ca/linked-data-notifications#implementations-key">*</a>}</th> <th>Description</th> </tr> </thead> <tfoot><tr> <td colspan="3"> <dl class="abbr"> <dt><sup id="implementations-key">*</sup></dt><dd>Conformance classes: S – sender, C – consumer, R – receiver.</dd> <dt><sup id="author-implementations">a</sup></dt><dd>Implementations by the authors</dd> </dl> <p>Source: <a href="https://github.com/w3c/ldn/tree/master/implementations">https://github.com/w3c/ldn/tree/master/implementations</a></p> </td> </tr></tfoot> <tbody> <tr> <th><a href="https://carbonldp.com">CarbonLDP</a></th> <td>R</td> <td>Data storage platform (LDP)</td> </tr> <tr> <th><a href="https://dokie.li/">dokieli</a>^a</th> <td>S,C</td> <td>Clientside editor and annotator</td> </tr> <tr> <th><a href="https://github.com/linkeddata/errol">errol</a>^a</th> <td>S</td> <td>Generic message sending client</td> </tr> <tr> <th><a href="http://fedora-commons.org/">Fedora Commons</a></th> <td>R</td> <td>Open source repository platform (LDP)</td> </tr> <tr> <th><a href="https://github.com/Kongaloosh/IndieAnndroid">IndieAnndroid</a></th> <td>R</td> <td>Personal blogging platform</td> </tr> <tr> <th><a href="https://github.com/albertmeronyo/linked-edit-rules">Linked Edit Rules</a></th> <td>S</td> <td>Statistical dataset consistency checker</td> </tr> <tr> <th><a href="https://github.com/csarven/mayktso">mayktso</a>^a</th> <td>R</td> <td>Personal data store (LDP)</td> </tr> <tr> <th><a href="https://github.com/rhiaro/onscreen">OnScreen</a>^a</th> <td>C</td> <td>Notifications display client</td> </tr> <tr> <th><a href="https://github.com/albertmeronyo/pyldn">pyldn</a></th> <td>R</td> <td>Standalone Inbox</td> </tr> <tr> <th><a href="https://github.com/kjetilk/p5-rdf-linkeddata-notifications">RDF-LinkedData-Notifications</a></th> <td>R</td> <td>Standalone Inbox</td> </tr> <tr> <th><a href="https://github.com/rhiaro/sloph">sloph</a>^a</th> <td>S,R</td> <td>Social publishing &amp; quantified self</td> </tr> <tr> <th><a href="https://github.com/melvincarvalho/vocab">Solid Words</a></th> <td>S</td> <td>Foreign language learning app</td> </tr> <tr> <th><a href="https://github.com/solid/solid-client">solid-client</a></th> <td>S</td> <td>Clientside library for LDP</td> </tr> <tr> <th><a href="https://github.com/solid/solid-inbox">solid-inbox</a></th> <td>C</td> <td>Clientside social message reader</td> </tr> <tr> <th><a href="https://github.com/solid/solid-notifications">solid-notifications</a></th> <td>S,C</td> <td>Clientside library for LDN</td> </tr> <tr> <th><a href="https://github.com/solid/node-solid-server">solid-server</a></th> <td>R</td> <td>Personal data storage server (LDP)</td> </tr> <tr> <th><a href="https://github.com/openlink/virtuoso-opensource">Virtuoso</a>+<a href="http://ods.openlinksw.com/wiki/ODS/OdsBriefcase">ODS Briefcase</a></th> <td>R,C</td> <td>Personal data storage server (LDP)</td> </tr> </tbody> </table> <p>We highlight social scholarly communication use cases with <cite><a href="https://dokie.li/">dokieli</a></cite>, a clientside editor for decentralised scientific article publishing, annotations and social interactions [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-17">17</a>]. dokieli uses LDN to send and consume notifications: When a reader comments on a fragment of text in an article, the application discovers the article’s Inbox and sends a notification about the annotation. dokieli also consumes notifications from this Inbox to fetch and display the annotation as marginalia (<a href="http://csarven.ca/linked-data-notifications#figure-dokieli-annotation">figure 2</a>). A reader can share a dokieli-enabled article with their contacts; dokieli discovers each contact’s Inbox and sends a notification there (<a href="http://csarven.ca/linked-data-notifications#figure-dokieli-share">figure 3</a>). When editing an article, the author can add a citation. If an Inbox is discovered in the cited article, dokieli sends a notification there to indicate what part of the article was cited by whom and where. dokieli-enabled articles also consume citation notifications to display these metrics for the author and other readers (<a href="http://csarven.ca/linked-data-notifications#figure-dokieli-citation">figure 4</a>).</p> <!-- <div class="figure-column-2"> --> <figure id="figure-dokieli-annotation" inlist="" rel="schema:hasPart" resource="#figure-dokieli-annotation"> <video id="video-dokieli-annotation" inlist="" rel="schema:hasPart" preload="none" controls="controls" width="800" poster="https://dokie.li/media/images/dokieli-annotation.jpg"> <source about="#video-dokieli-annotation" rel="schema:hasPart" resource="https://dokie.li/media/video/dokieli-annotation.webm" typeof="fabio:Film" src="https://dokie.li/media/video/dokieli-annotation.webm" type="video/webm" /> </video> <figcaption property="schema:name"><a href="https://dokie.li/media/video/dokieli-annotation.webm">Video</a> of dokieli Web Annotation</figcaption> </figure> <figure id="figure-dokieli-share" inlist="" rel="schema:hasPart" resource="#figure-dokieli-share"> <video id="video-dokieli-share" rel="schema:hasPart" preload="none" controls="controls" width="800" poster="https://dokie.li/media/images/dokieli-share.jpg"> <source about="#video-dokieli-share" rel="schema:hasPart" resource="https://dokie.li/media/video/dokieli-share.webm" typeof="fabio:Film" src="https://dokie.li/media/video/dokieli-share.webm" type="video/webm" /> </video> <figcaption property="schema:name"><a href="https://dokie.li/media/video/dokieli-share.webm">Video</a> of dokieli Share</figcaption> </figure> <!-- </div> --> <figure id="figure-dokieli-citation" inlist="" rel="schema:hasPart" resource="#figure-dokieli-citation"> <video controls="controls" id="video-dokieli-citation" poster="https://dokie.li/media/images/dokieli-citation.jpg" preload="none" width="800" about="" rel="schema:hasPart"> <source about="#video-dokieli-citation" rel="schema:hasPart" resource="https://dokie.li/media/video/dokieli-citation.webm" src="https://dokie.li/media/video/dokieli-citation.webm" type="video/webm" typeof="fabio:Film" /> </video> <figcaption property="schema:name"><a href="https://dokie.li/media/video/dokieli-citation.webm">Video</a> of semantic inline citations</figcaption> </figure> <p>Notifications sent by dokieli can be reused by any consuming applications that recognise the vocabulary terms; similarly, dokieli can consume notifications sent by different applications.</p> <p>Further social use cases are demonstrated by <cite><a href="https://rhiaro.co.uk/sloph">sloph</a></cite>, a personal publishing and quantified self platform which acts as a node in a decentralised social network. When new content is created on the server, sloph performs discovery on URLs it finds as values of particular properties of the new content, as well as any URLs in the body of the content, and sends notifications accordingly. For instance:</p> <ul> <li>If a <em>Like</em> activity is generated on the server, sloph uses the <code>object</code> of the <em>Like</em> as the target for a notification. Since dokieli uses the same vocabulary for social interactions (<cite><a href="https://www.w3.org/ns/activitystreams-core">ActivityStreams 2.0</a></cite> [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-18">18</a>]), if the target is a dokieli article, this <em>Like</em> will be displayed (<a href="http://csarven.ca/linked-data-notifications#figure-sloph-dokieli">figure 5</a>).</li> <li>If the user publishes a blog post containing a link, which may be semantically annotated to indicate the reason for linking, sloph sends a notification to any Inbox discovered at that link.</li> <li>As a receiver, sloph accepts all incoming notifications, but holds for moderation (i.e. places behind access control) any that it cannot automatically verify refer to third-party content published on another domain. If an article written with dokieli publishes a citation of a blog post which advertises a sloph Inbox, sloph will fetch the article and verify whether the relation matches the contents of the notification before exposing the notification for re-use.</li> </ul> <p><cite><a href="http://www.linkededitrules.org/">Linked Edit Rules</a></cite> and <cite><a href="https://melvincarvalho.github.io/vocab/">Solid Words</a></cite> are specialised senders. Linked Edit Rules checks the consistency of statistical datasets against structured constraints, and delivers the consistency report as a notification to the user. Solid Words is a clientside game for learning new words in a foreign language; it delivers the player’s score for each round to their Inbox. <cite><a href="https://apps.rhiaro.co.uk/onscreen">OnScreen</a></cite> is a (crude) generic consumer; as such, it can display notifications sent by both of the aforementioned senders (<a href="http://csarven.ca/linked-data-notifications#figure-ldn-senders">figure 6</a>).</p> <figure id="figure-sloph-dokieli" inlist="" rel="schema:hasPart" resource="#figure-sloph-dokieli"> <img src="http://csarven.ca/media/images/articles/screenshot-ldn-sloph-dokieli.jpg" alt="Screenshots of sloph and dokieli" /> <figcaption property="schema:name">A <em>Like</em> notification created by sloph, displayed by dokieli.</figcaption> </figure> <figure id="figure-ldn-senders" inlist="" rel="schema:hasPart" resource="#figure-ldn-senders"> <img src="http://csarven.ca/media/images/articles/screenshot-ldn-senders.jpg" alt="Screenshots of Solid Words, Linked Edit Rules, and OnScreen" /> <figcaption property="schema:name">A: Solid Words (a sender), B: Linked Edit Rules (a sender), C: OnScreen (a consumer) displaying notifications sent by A and B.</figcaption> </figure> </div> </section> <section id="analysis-and-evaluation" inlist="" rel="schema:hasPart" resource="#analysis-and-evaluation"> <h2 property="schema:name">Analysis and Evaluation</h2> <div datatype="rdf:HTML" property="schema:description" resource="#analysis-and-evaluation" typeof="deo:Evaluation"> <p>The LDN protocol describes the discovery of a resource’s Inbox whence notifications are sent or consumed, and the sending and exposure of those notifications. Here we analyse how well features of LDN achieve the <a href="http://csarven.ca/linked-data-notifications#requirements-and-design-considerations">requirements</a> identified previously, and compare this to related work.</p> <p>We have already examined <a href="http://csarven.ca/linked-data-notifications#implementations">implementations</a> of the specification and described how they interoperate with each other; this can be further tested by running the <a href="https://linkedresearch.org/ldn/tests/">test suite</a>: https://linkedresearch.org/ldn/tests/. We can use this towards an evaluation of its feasibility and effectiveness at interoperability. Given the relatively early stage in the standardisation process (LDN entered Candidate Recommendation in 2016-11), the fast adoption of the LDN specification, quantity of the implementations, and their diversity is promising and further shows LDN’s feasibility. Furthermore, during the development of the specification issues have been raised or discussed by 28 different people (excluding the authors; 21 outside of the Social Web Working Group, 7 within) and the specification has undergone formal review by internationalisation, accessibility, and security specialists. We also discuss in more depth particular challenges that were raised and resolved as part of this process.</p> <section id="comparison-summary" inlist="" rel="schema:hasPart" resource="#comparison-summary"> <h3 property="schema:name">Comparison summary</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Here we compare existing notification mechanisms from related work. The criteria includes our <a href="http://csarven.ca/linked-data-notifications#requirements-and-design-considerations">requirements and design considerations</a> (<em>Rx</em>) along with additional technical information which helps to capture some design differences (<em>Tx</em>).</p> <table id="comparison-of-notification-mechanisms"> <caption>Comparison of notification mechanisms</caption> <thead> <tr> <th>Mechanism</th> <th>T1</th> <th>T2</th> <th>T3</th> <th>R1</th> <th>R2</th> <th>R3</th> <th>R4-A</th> <th>R4-B</th> <th>R4-C^p</th> <th>R4-C^v</th> <th>R4-C^o</th> <th>R5</th> </tr> </thead> <tfoot> <tr> <td colspan="14"> <dl class="abbr"> <dt>T1</dt><dd>Notification type</dd> <dt>T2</dt><dd>Delivery method</dd> <dt>T3</dt><dd>Dependencies</dd> <dt>R1</dt><dd>Modularity (application classes: S Sender, R Receiver, C Consumer, U Subscriber/User)</dd> <dt>R2</dt><dd>Reusability</dd> <dt>R3</dt><dd>Persistence - required? how?</dd> <dt>R4-A</dt><dd>Target representation</dd> <dt>R4-B</dt><dd>Notification body</dd> <dt>R4-C^p</dt><dd>Payload processing required?</dd> <dt>R4-C^v</dt><dd>Verification - required? how?</dd> <dt>R4-C^o</dt><dd>Requirements for referenced resources?</dd> <dt>R5</dt><dd>Subscription</dd> </dl> <hr/> <dl class="abbr"> <dt>–</dt><dd>not applicable, out of scope</dd> <dt>/</dt><dd>not specified, in scope</dd> <dt>X</dt><dd>explicitly disallowed</dd> <dt>app</dt><dd>application specific decision</dd> <dt>!</dt><dd>required (<em>MUST</em>)</dd> <dt>+</dt><dd>recommended (<em>SHOULD</em>)</dd> <dt>O</dt><dd>optional (<em>MAY</em>)</dd> <dt>PuSH</dt><dd>PubSubHubbub</dd> </dl> <hr/> <dl class="abbr"> <dt>^h</dt><dd>HTML recommended</dd> <dt>^j</dt><dd>Alternate RDF formats can be negotiated</dd> <dt>^k</dt><dd><code>source</code> and <code>target</code> key–value pairs is required</dd> <dt>^q</dt><dd>Provenance records with <a href="http://www.w3.org/TR/prov-o/">PROV Ontology</a></dd> <dt>^r</dt><dd>RDF representation recommended</dd> <dt>^ra</dt><dd>SPARQL results transformed to RSS/Atom</dd> <dt>^s</dt><dd><a href="https://www.sitemaps.org/protocol.html">Sitemaps</a></dd> <dt>^t</dt><dd>Described in an RDF store or dataset</dd> </dl> </td> <!-- Notes for how I removed some ?s: * target representation is - when there’s no discovery step for the sender ie. subscription based * verification required is - when there’s a subscription relationship because we assume the receiver trusts the sender -rhiaro --> </tr> </tfoot> <tbody> <tr> <th>Semantic Pingback</th> <td>Linkback</td> <td>POST</td> <td>RDF</td> <td>S R</td> <td>/</td> <td>/</td> <td>Any^r</td> <td>form urlencoded^k</td> <td>!</td> <td>! parse source</td> <td>Any^r</td> <td>X</td> </tr> <tr> <th>Webmention</th> <td>Linkback</td> <td>POST</td> <td>HTML</td> <td>S R</td> <td>–</td> <td>–</td> <td>Any^h</td> <td>form urlencoded^k</td> <td>!</td> <td>! parse source</td> <td>Any^h</td> <td>X</td> </tr> <tr> <th>Provenance Pingback</th> <td>Linkback</td> <td>POST</td> <td>RDF</td> <td>S R</td> <td>/</td> <td>/</td> <td>/</td> <td>URI list</td> <td>/</td> <td>/</td> <td>RDF^q</td> <td>X</td> </tr> <tr> <th>DSNotify</th> <td>Fat ping</td> <td>POST, PUT</td> <td>XML, PuSH</td> <td>S U</td> <td>/</td> <td>–</td> <td>–</td> <td>XML</td> <td>/</td> <td>–</td> <td>RDF^t</td> <td>!</td> </tr> <tr> <th>sparqlPuSH</th> <td>Fat ping</td> <td>POST</td> <td>XML, SPARQL, PuSH</td> <td>S U</td> <td>–</td> <td>–</td> <td>–</td> <td>XML^ra</td> <td>/</td> <td>–</td> <td>RDF^t</td> <td>!</td> </tr> <tr> <th>ResourceSync</th> <td>Fat ping</td> <td>POST</td> <td>XML, PuSH</td> <td>S U</td> <td>/</td> <td>–</td> <td>–</td> <td>XML^s</td> <td>/</td> <td>–</td> <td>?</td> <td>!</td> </tr> <tr> <th>Linked Data Notifications</th> <td>Fat ping</td> <td>POST</td> <td>JSON-LD</td> <td>S R C</td> <td>!</td> <td>! URI</td> <td>Any</td> <td>JSON-LD^j</td> <td>+ app</td> <td>+ app</td> <td>–</td> <td>O app</td> </tr> </tbody> </table> <p>Given that each application requires to follow the steps listed in <q><a href="http://csarven.ca/linked-data-notifications#sender-to-receiver">Sender to receiver interaction</a></q> and <q><a href="http://csarven.ca/linked-data-notifications#consumer-to-receiver">Consumer to receiver interactions</a></q> the metrics are dependent on the performance of client and server to do HTTP requests and responses, and their respective payloads.</p> </div> </section> <section id="compatibility-with-existing-systems" inlist="" rel="schema:hasPart" resource="#compatibility-with-existing-systems"> <h3 property="schema:name">Compatibility with existing systems</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Per <a about="#protocol" rel="dio:fulfillsRequirement" href="http://csarven.ca/linked-data-notifications#modularity">R1</a> and <a about="#protocol" rel="dio:fulfillsRequirement" href="http://csarven.ca/linked-data-notifications#adaptability">R4</a> we have tried to optimise LDN for use as a module of a larger system. The success of this is demonstrated by implementations which use LDN alongside existing protocols according to their specific needs.</p> <p>The Solid suite of tools, Virtuoso+ODS-Briefcase, and dokieli use <cite><a href="https://www.w3.org/wiki/WebAccessControl">Web Access Control</a></cite> along with an authentication mechanism to apply fine grained access controls to restrict who can send notifications, or who can retrieve notifications from the Inbox. sloph demonstrates an Inbox as a <cite><a href="http://www.webhooks.org/">Webhooks</a></cite> callback URL, for requesting notifications from APIs which post JSON-based payloads. <cite><a href="https://www.w3.org/TR/activitypub/">ActivityPub</a></cite> is a W3C <abbr title="Candidate Recommendation">CR</abbr> for decentralised social media [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-19">19</a>]. It uses LDN for delivery of notifications with the <a href="https://www.w3.org/ns/activitystreams">ActivityStreams 2.0</a> (AS2) vocabulary, and specifies additional specialised receiver behaviour; also used by sloph. dokieli uses the <cite><a href="https://www.w3.org/TR/annotation-protocol/">Web Annotation Protocol</a></cite>, an LDP-based mechanism for creating new content, which acts as a trigger for notifications to be sent to the Inbox of the annotation target. The <cite><a href="http://fcrepo.github.io/fcrepo-specification/">Fedora API Specification</a></cite> is in the process of being formalised (as an extension of LDP) by the Fedora community. The repository event stream draws upon the LDN specification, allowing LDN consumers and senders to react asynchronously to repository events.</p> <p>Any existing <abbr title="Linked Data Platform">LDP</abbr> implementation can serve as an LDN receiver. Simply advertising any <code>ldp:Container</code> as the Inbox for a resource is sufficient. We confirmed this with four LDP servers which were developed independently with different code bases, prior to the LDN specification (CarbonLDP, Fedora Commons, Solid Server, Virtuoso).</p> <p>LDN has been integrated into existing domain specific systems: dokieli, Fedora Commons, IndieAnndroid, Linked Edit Rules, sloph, solid-client, Solid Words. Standalone implementations of LDN are also straightforward as a result of this modularity, ie: errol, mayktso, onscreen, pyLDN, RDF-LinkedData-Notifications, solid-inbox, solid-notifications.</p> </div> </section> <section id="optimising-implementation" inlist="" rel="schema:hasPart" resource="#optimising-implementation"> <h3 property="schema:name">Optimising implementation</h3> <div datatype="rdf:HTML" property="schema:description"> <p about="#design-intent-best-practices" rel="dio:generatesIssue"><span about="#design-issue-optimising-implementation" datatype="rdf:HTML" property="schema:description" rel="dio:generatedByIntent" resource="#design-intent-best-practices" typeof="dio:DesignIssue">We have considered tradeoffs between the HTTP operations receivers and publishers are <em>required</em> to respond to, and ways in which developers may wish to optimise senders or consumers by reducing outbound requests.<meta about="#design-issue-optimising-implementation" rel="dio:hasStatus" resource="dio:Resolved" /></span></p> <p about="#design-issue-optimising-implementation" rel="dio:hasMandatedSolution" resource="#solution-optimising-implementation-get-head-link"> <meta rel="dio:leadsTo" resource="#design-decision" typeof="dio:MandatedSolution" /> <span property="dio:hasArgument" resource="#argument-optimising-implementation-get-head-link" typeof="dio:Argument"><span datatype="rdf:HTML" property="schema:description"><code>HEAD</code> requests are low cost, and <code>GET</code> requests may be high cost if the body of the resource is large.</span></span> <span property="dio:hasJustification" resource="#justification-optimising-implementation-get-head-link" typeof="dio:Justification"><span datatype="rdf:HTML" property="schema:description">Given that an Inbox may be discovered from the HTTP headers of a resource, senders and consumers can optimise by attempting a <code>HEAD</code> request for discovery, and only continuing with a <code>GET</code> request if the <code>HEAD</code> is not successful. On the other hand, senders and consumers may be attempting discovery upon RDF resources which they already intend to parse into their own storage. In this case, there is no need for a <code>HEAD</code> request, as a <code>GET</code> will yield both HTTP <code>Link</code> headers and an RDF body, either of which could include the Inbox triple. This means that resources advertising an Inbox must respond to <code>GET</code> requests (even if only with HTTP headers) and may respond to <code>HEAD</code> requests.</span></span> </p> </div> </section> <section id="data-formats" inlist="" rel="schema:hasPart" resource="#data-formats"> <h3 property="schema:name">Data Formats and Content Negotiation</h3> <div datatype="rdf:HTML" property="schema:description"> <p about="#design-intent-linked-data" rel="dio:generatesIssue"><span about="#design-issue-data-formats" datatype="rdf:HTML" property="schema:description" rel="dio:hasStatus" resource="#design-intent-linked-data" typeof="dio:DesignIssue">Handling data irrespective of the particular RDF serialisation permits some flexibility, but can be costly to support. We take into account: (a) application interoperability, (b) maintenance of RDF parsers and serialisation libraries, (c) complexity of their inclusion in applications, (d) run-time efficiency.<meta about="#design-issue-data-formats" rel="dio:hasStatus" resource="dio:Resolved" /></span></p> <p about="#design-issue-data-formats" rel="dio:hasMandatedSolution" resource="#solution-data-formats-json-ld"> <meta rel="dio:leadsTo" resource="#design-decision" typeof="dio:MandatedSolution" /> <span property="dio:hasArgument" resource="#argument-data-formats-json-ld" typeof="dio:Argument"><span datatype="rdf:HTML" property="schema:description">To address these issues, LDN requires all applications to create and understand the JSON-LD syntax, both for the contents of Inbox as well as for individual notifications. Choosing a single serialisation to <em>require</em> is necessary for consistent interoperability, as well as keeping processing requirements or external code dependencies minimal.</span></span> <span property="dio:hasJustification" resource="#justification-data-formats-json-ld" typeof="dio:Justification"><span datatype="rdf:HTML" property="schema:description">JSON-LD is advantageous in being familiar for developers who are <cite><a rel="dio:hasEvidence" typeof="dio:Evidence" href="http://manu.sporny.org/2014/json-ld-origins-2/">used to JSON-based APIs but not RDF</a></cite> [<a class="ref" href="http://csarven.ca/linked-data-notifications#ref-20">20</a>], and it is compatible with existing JSON libraries or in some cases native programming language data structures.</span></span> </p> <p about="#design-issue-data-formats" rel="dio:hasAlternativeSolution" resource="#solution-data-formats-content-negotiation">Optionally, <span property="dio:hasArgument" resource="#argument-data-formats-content-negotiation" typeof="dio:Argument"><span datatype="rdf:HTML" property="schema:description">applications may attempt to exchange different RDF serialisations by performing content negotiation</span></span> (<span property="dio:hasJustification" resource="#justification-data-formats-content-negotiation" typeof="dio:Justification"><span datatype="rdf:HTML" property="schema:description">receivers can expose <code>Accept-Post</code> headers for senders, and consumers can send <code>Accept</code> headers to receivers</span></span>).</p> </div> </section> <section id="precision" inlist="" rel="schema:hasPart" resource="#precision"> <h3 property="schema:name">Precision</h3> <div datatype="rdf:HTML" property="schema:description"> <p>In placing no constraints on the contained information, LDN enables a sender to be precise and lossless with the data it is transmitting. Approaches which send only URLs rely on the receiver interpreting a third-party resource, which may or may not contain structured markup or be under the control of the sender. Approaches which offer additional guidance to aid the receiver in interpreting the source document(s) nonetheless still restricts the sender. LDN therefore offers flexibility to senders, increasing the potential uses for the notification mechanism. LDN compensates for increased complexity on the receiver’s end by recommending filtering mechanisms, and moving some of the burden of understanding notifications to the consumer role. As such LDN can cover a broader variety of use cases.</p> </div> </section> <section id="accommodating-different-targets" inlist="" rel="schema:hasPart" resource="#accommodating-different-targets"> <h3 property="schema:name">Accommodating different targets</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Per <em>R4 Adaptability</em>, we want LDN to be available for all resources in any publishing context. We consider lowering the bar for publishers of target resources to be a worthwhile trade-off against slightly increased complexity for senders and consumers. This is why we require that senders and consumers must be equipped to discover Inboxes through both HTTP headers and RDF content. </p> <p>Since binary formats such as images and video cannot contain an RDF relation, the HTTP header is essential for including them. It also allows the inclusion of resources for which it is undesirable or impractical to add individual Inbox relations, such as to elements in a dataset; or circumstances where the developer responsible for the Inbox relation is unable to modify the content. Conversely, non-informational resources (represented with fragment URIs or 303 redirects) are unable to express HTTP headers. Their relation to an Inbox must be expressed in an RDF source. However, if a sender or consumer has a domain-specific requirement to <em>only</em> ever target non-informational resources, they are exempt from the requirement of discovery via HTTP headers.</p> </div> </section> </div> </section> <section id="conclusions" inlist="" rel="schema:hasPart" resource="#conclusions"> <h2 property="schema:name">Conclusions</h2> <div datatype="rdf:HTML" property="schema:description" resource="#conclusions" typeof="deo:Conclusion"> <p>In this article we describe LDN, a protocol for decentralised semantic notifications, currently undergoing standardisation at the W3C. Key elements are:</p> <ul> <li>Notifications as retrievable, reusable entities with their own URIs.</li> <li>Distinct conformance classes for senders, receivers, and consumers.</li> <li>Deliberately not defining the vocabulary of notification contents to allow for use in a range of different application domains.</li> <li>Flexibility of authentication and verification, for the same reason.</li> </ul> <p>We outlined design requirements, describe how LDN meets these, and compare this with related work. We consider LDN to have greater modularity and adaptability to different scenarios, as well as good conformance with Linked Data principles. This specification has potential to have high impact in increasing interoperability between decentralised Linked Data applications in related domains, as well as generating new discoverable content for the LOD Cloud. This is evidenced by 17 diverse implementations which can be shown to interoperate with each other, including generic libraries and datastores, and domain-specific applications. Being on the W3C standards track increases the likelihood of further adoption.</p> <!-- Future work? --> <!-- <p>We have yet to assess the implications of applications modifying data that another application also makes use of. This would be a useful study for decentralisation in general.</p> --> </div> </section> <section id="acknowledgements" inlist="" prefix="scoro: http://purl.org/spar/scoro/" rel="schema:hasPart" resource="#acknowledgements"> <h2 property="schema:name">Acknowledgements</h2> <div about="#acknowledgements" datatype="rdf:HTML" property="schema:description" typeof="deo:Acknowledgements"> <p>This material is based on work supported by the Qatar Computing Research Institute (QCRI), and by the DFG project “Opening Scholarly Communication in Social Sciences” (grant agreement AU 340/9-1).</p> </div> </section> <section id="references"> <h2>References</h2> <div> <ol> <li id="ref-1">Mansour, E., Sambra, A., Hawke, S., Zereba, M., Capadisli, S., Ghanem, A., Aboulnaga, A., Berners-Lee, T.: <cite>A Demonstration of the Solid Platform for Social Web Applications</cite>, WWW, Demo, 2016, <a rel="schema:citation" href="http://www2016.net/proceedings/companion/p223.pdf">http://www2016.net/proceedings/companion/p223.pdf</a></li> <li id="ref-2">Tramp, S., Frischmuth, P., Ermilov, T., Shekarpour, S., Auer, S.: <cite>An Architecture of a Distributed Semantic Social Network</cite>, Semantic Web Journal, 2012, <a rel="schema:citation" href="http://www.semantic-web-journal.net/sites/default/files/swj201_4.pdf"></a></li> <li id="ref-3">Arndt, N., Junghanns, K., Meissner, R., Frischmuth, F., Radtke, N., Frommhold, M., Martin, M.: <cite>Structured Feedback</cite>, WWW, LDOW, 2016, <a rel="schema:citation" href="http://events.linkeddata.org/ldow2016/papers/LDOW2016_paper_02.pdf">http://events.linkeddata.org/ldow2016/papers/LDOW2016_paper_02.pdf</a></li> <li id="ref-4">Capadisli, S., Guy, A.: <cite>Linked Data Notifications</cite>, W3C Candidate Recommendation, 2016, <a rel="schema:citation" href="https://www.w3.org/TR/ldn/">https://www.w3.org/TR/ldn/</a></li> <li id="ref-5">Parecki, A.: <cite>Webmention</cite>, W3C Proposed Recommendation, 2016, <a rel="schema:citation" href="https://www.w3.org/TR/webmention/">https://www.w3.org/TR/webmention/</a></li> <li id="ref-6">Langridge, S., Hickson, I.: <cite>Pingback 1.0</cite>, 2002, <a rel="schema:citation" href="http://www.hixie.ch/specs/pingback/pingback">http://www.hixie.ch/specs/pingback/pingback</a></li> <li id="ref-7">Klyne, G., Groth, P.: <cite>PROV-AQ: Provenance Access and Query</cite>, W3C Note, 2013, <a rel="schema:citation" href="http://www.w3.org/TR/prov-aq/">http://www.w3.org/TR/prov-aq/</a></li> <li id="ref-8">Haslhofer, B., Popitsch, N.: <cite>DSNotify – Detecting and Fixing Broken Links in Linked Data Sets</cite>, WWW, 2010, <a rel="schema:citation" href="http://eprints.cs.univie.ac.at/81/1/2010_WWW_DSNotify.pdf">http://eprints.cs.univie.ac.at/81/1/2010_WWW_DSNotify.pdf</a></li> <li id="ref-9">Passant, A., Mendes, P.N.: <cite>sparqlPuSH: Proactive notification of data updates in RDF stores using PubSubHubbub</cite>, SFSW, CEUR Workshop Proceedings, Vol. 699, 2010, <a rel="schema:citation" href="http://ceur-ws.org/Vol-699/Paper6.pdf">http://ceur-ws.org/Vol-699/Paper6.pdf</a></li> <li id="ref-10">Klein, M., Van de Sompel, H., Warner, S., Klyne, G., Haslhofer, B., Nelson, M., Lagoze, C., Sanderson, R.: ResourceSync Framework Specification – Change Notification, 2016, <a rel="schema:citation" href="http://www.openarchives.org/rs/notification/1.0/notification">http://www.openarchives.org/rs/notification/1.0/notification</a></li> <li id="ref-11">Berners-Lee, T.: <cite>Cool URIs don't change</cite>, W3C, 1998, <a rel="schema:citation" href="https://www.w3.org/Provider/Style/URI.html">https://www.w3.org/Provider/Style/URI.html</a></li> <li id="ref-12">Archer, P., Loutas, N., Goedertier S., Kourtidis, S.: <cite>Study On Persistent URIs</cite>, 2012, <a rel="schema:citation" href="http://philarcher.org/diary/2013/uripersistence/">http://philarcher.org/diary/2013/uripersistence/</a></li> <li id="ref-13">Fielding, R. T.: <cite>Architectural Styles and the Design of Network-based Software Architectures</cite>. Doctoral dissertation, University of California, Irvine, 2000, <a rel="schema:citation" href="http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm">http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm</a></li> <li id="ref-14">Page, K.R., De Roure, D.C., Martinez, K.: <cite>REST and Linked Data: a match made for domain driven development?</cite>, WWW, WS-REST, 2011, <a rel="schema:citation" href="http://ws-rest.org/2011/proc/a5-page.pdf">http://ws-rest.org/2011/proc/a5-page.pdf</a></li> <li id="ref-15">Knublauch, H., Kontokostas, D.: <cite>Shapes Constraint Language</cite>, W3C Working Draft, 2016, <a rel="schema:citation" href="https://www.w3.org/TR/shacl/"></a></li> <li id="ref-16">Speicher, S., Arwe, J., Malhotra, A.: <cite>Linked Data Platform</cite>, W3C Recommendation, 2015, <a rel="schema:citation" href="https://www.w3.org/TR/ldp/">https://www.w3.org/TR/ldp/</a></li> <li id="ref-17">Capadisli, S., Guy, A., Auer S., Berners-Lee, T.: <cite>dokieli</cite>, 2016, <a rel="schema:citation" href="http://csarven.ca/dokieli">http://csarven.ca/dokieli</a></li> <li id="ref-18">Snell, J., Prodromou, E.: <cite>Activity Streams 2.0</cite>, W3C Candidate Recommendation, 2016, <a rel="schema:citation" href="https://www.w3.org/TR/activitystreams-core/">https://www.w3.org/TR/activitystreams-core/</a></li> <li id="ref-19">Webber, C., Tallon, J.: <cite>ActivityPub</cite>, W3C Candidate Recommendation, 2016, <a rel="schema:citation" href="https://www.w3.org/TR/activitypub/">https://www.w3.org/TR/activitypub/</a></li> <li id="ref-20">Sporny, M.: <cite>JSON-LD and Why I Hate the Semantic Web</cite>, 2014, <a rel="schema:citation" href="http://manu.sporny.org/2014/json-ld-origins-2/">http://manu.sporny.org/2014/json-ld-origins-2/</a></li> </ol> </div> </section> </div> http://csarven.ca/linked-data-notifications Sun, 20 Dec 2015 00:00:00 <h1 property="schema:name">Linked Research: An Approach for Scholarly Communication</h1> <div id="authors"> <dl id="author-name"> <dt>Authors</dt> <dd id="Sarven-Capadisli" inlist="" rel="bibo:authorList" resource="http://csarven.ca/#i"><span about="" rel="schema:creator schema:publisher schema:author"><a about="http://csarven.ca/#i" href="http://csarven.ca/" property="schema:name" rel="schema:url" typeof="schema:Person">Sarven Capadisli</a></span>^{<a about="http://csarven.ca/#i" href="http://csarven.ca/linked-research-scholarly-communication#author-org-1" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">1</a>}^{<a href="http://csarven.ca/linked-research-scholarly-communication#author-email-1">✊</a>}</dd> <dd id="Amy-Guy" inlist="" rel="bibo:authorList" resource="https://rhiaro.co.uk/#me"><span about="" rel="schema:author"><a about="https://rhiaro.co.uk/#me" href="https://rhiaro.co.uk/" property="schema:name" rel="schema:url" typeof="schema:Person">Amy Guy</a></span>^{<a about="https://rhiaro.co.uk/#me" href="http://csarven.ca/linked-research-scholarly-communication#author-org-2" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Edinburgh">2</a>}^{<a href="http://csarven.ca/linked-research-scholarly-communication#author-email-2">🐦</a>}</dd> <dd id="Christoph-Lange" inlist="" rel="bibo:authorList" resource="http://eis.iai.uni-bonn.de/ChristophLange"><span about="" rel="schema:author"><a about="http://eis.iai.uni-bonn.de/ChristophLange" href="https://langec.wordpress.com/about/" property="schema:name" rel="schema:url" typeof="schema:Person">Christoph Lange</a></span>^{<a about="http://eis.iai.uni-bonn.de/ChristophLange" href="http://csarven.ca/linked-research-scholarly-communication#author-org-3" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">3</a>}^{<a href="http://csarven.ca/linked-research-scholarly-communication#author-email-3">∫</a>}</dd> <dd id="Sören-Auer" inlist="" rel="bibo:authorList" resource="http://eis.iai.uni-bonn.de/SoerenAuer"><span about="" rel="schema:author"><a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://eis.iai.uni-bonn.de/SoerenAuer.html" property="schema:name" rel="schema:url" typeof="schema:Person">Sören Auer</a></span>^{<a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://csarven.ca/linked-research-scholarly-communication#author-org-4" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">4</a>}^{<a href="http://csarven.ca/linked-research-scholarly-communication#author-email-4">⚛</a>}</dd> <dd id="Nicola-Greco" inlist="" rel="bibo:authorList" resource="https://nicola.databox.me/profile/card#me"><span about="" rel="schema:author"><a about="https://nicola.databox.me/profile/card#me" href="http://nicola.io/" property="schema:name" rel="schema:url" typeof="schema:Person">Nicola Greco</a></span>^{<a about="https://nicola.databox.me/profile/card#me" href="http://csarven.ca/linked-research-scholarly-communication#author-org-5" rel="schema:memberOf" resource="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology">5</a>}^{<a href="http://csarven.ca/linked-research-scholarly-communication#author-email-5">📖</a>}</dd> </dl> <ul id="author-org"> <li id="author-org-1">¹Enterprise Information Systems Department, <a about="http://dbpedia.org/resource/University_of_Bonn" href="http://uni-bonn.de/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Bonn</a>, Bonn, Germany</li> <li id="author-org-2">²School of Informatics, <a about="http://dbpedia.org/resource/University_of_Edinburgh" href="http://www.ed.ac.uk/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Edinburgh</a>, Edinburgh, UK</li> <li id="author-org-3">³Enterprise Information Systems Department, <a about="http://dbpedia.org/resource/University_of_Bonn" href="http://uni-bonn.de/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Bonn</a>, Bonn, Germany</li> <li id="author-org-4">⁴Enterprise Information Systems Department, <a about="http://dbpedia.org/resource/University_of_Bonn" href="http://uni-bonn.de/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Bonn</a>, Bonn, Germany</li> <li id="author-org-5">⁵Decentralized Information Group, CSAIL, <a about="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology" href="https://mit.edu/" property="schema:name" rel="schema:url" typeof="schema:Organization">MIT</a>, Cambridge, US</li> </ul> <ul id="author-email"> <li id="author-email-1">^✊<a about="http://csarven.ca/#i" href="http://csarven.camailto:info@csarven.ca" rel="schema:email">info@csarven.ca</a></li> <li id="author-email-2">^🐦<a about="https://rhiaro.co.uk/#me" href="http://csarven.camailto:amy@rhiaro.co.uk" rel="schema:email">amy@rhiaro.co.uk</a></li> <li id="author-email-3">^∫<a about="http://eis.iai.uni-bonn.de/ChristophLange" href="http://csarven.camailto:langec@cs.uni-bonn.de" rel="schema:email">langec@cs.uni-bonn.de</a></li> <li id="author-email-4">^⚛<a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://csarven.camailto:auer@cs.uni-bonn.de" rel="schema:email">auer@cs.uni-bonn.de</a></li> <li id="author-email-5">^📖<a about="https://nicola.databox.me/profile/card#me" href="http://csarven.camailto:ngreco@mit.edu" rel="schema:email">ngreco@mit.edu</a></li> </ul> </div> <dl id="document-identifier"> <dt>Identifier</dt> <dd><a href="http://csarven.ca/linked-research-scholarly-communication" rel="owl:sameAs">http://csarven.ca/linked-research-scholarly-communication</a></dd> </dl> <dl id="document-inbox"> <dt>Notifications Inbox</dt> <dd><a href="https://linkedresearch.org/inbox/" rel="solid:inbox">inbox/</a></dd> </dl> <dl id="document-in-reply-to"> <dt>In Reply To</dt> <dd><a href="http://ht.acm.org/ht2016/calls" rel="as:inReplyTo">ACM Hypertext 2016 Call for Contributions</a></dd> </dl> <dl id="document-published"> <dt>Published</dt> <dd><time content="2015-02-20T00:00:00Z" datatype="xsd:dateTime" datetime="2015-02-20T00:00:00Z" property="schema:datePublished">2015-12-20</time></dd> </dl> <dl id="document-modified"> <dt>Modified</dt> <dd><time content="2016-03-11T00:00:00Z" datatype="xsd:dateTime" datetime="2016-03-11T00:00:00Z" property="schema:dateModified">2016-03-11</time></dd> </dl> <dl id="document-license"> <dt>License</dt> <dd><a href="https://creativecommons.org/licenses/by/4.0/" rel="schema:license" title="Creative Commons Attribution 4.0 Unported">CC BY 4.0</a></dd> </dl> <div id="content"> <section id="abstract"> <h2>Abstract</h2> <div datatype="rdf:HTML" property="schema:abstract"> <p>The future of scholarly communication involves research results, analysis and data all being produced, published, verified and reused interactively on the Web, with ‘papers’ linking to and from each other at a granular level. The academic process of peer review is increasingly becoming open, transparent and decentralised. More broadly, the mechanism for global knowledge sharing is becoming an ongoing conversation between experts, policy makers, implementers, and the general public. This vision is radical, and getting there requires understanding of, and change in, a number of interrelated areas. In this article we break down the problem space and define requirements for advancement towards a Web-based ecosystem for scholarly communication: <em>Linked Research</em>. We discuss our strategy for tackling each of these areas. This includes how we can build on and combine existing well-known technologies and practices for digital publishing, social interactions, decentralised data storage, and semantic data enrichment. We provide an initial assessment of our proposed strategy through an example implementation of tooling which sets out to meet the requirements.</p> </div> </section> <section id="keywords"> <h2>Keywords</h2> <div> <ul rel="schema:about"> <li><a href="https://en.wikipedia.org/wiki/Human-computer_interaction" resource="http://dbpedia.org/resource/Human-computer_interaction">Human-computer interaction</a></li> <li><a href="https://en.wikipedia.org/wiki/Linked_Data" resource="http://dbpedia.org/resource/Linked_Data">Linked Data</a></li> <li><a href="https://en.wikipedia.org/wiki/Open_access" resource="http://dbpedia.org/resource/Open_access">Open Access</a></li> <li><a href="https://en.wikipedia.org/wiki/Semantic_publishing" resource="http://dbpedia.org/resource/Semantic_publishing">Semantic publishing</a></li> <li><a href="https://en.wikipedia.org/wiki/Social_machine" resource="http://dbpedia.org/resource/Social_machine">Social machine</a></li> <li><a href="https://en.wikipedia.org/wiki/Social_web" resource="http://dbpedia.org/resource/Social_web">Social web</a></li> <li><a href="https://en.wikipedia.org/wiki/Web_science" resource="http://dbpedia.org/resource/Web_science">Web science</a></li> </ul> </div> </section> <!-- TODO: Use CCS 2012 <section id="categories-and-subject-descriptors"> <h2>Categories and Subject Descriptors</h2> <div> <ul rel="schema:about"> <li><a href="http://www.acm.org/about/class/ccs98-html#H.1.2" resource="http://acm.rkbexplorer.com/ontologies/acm#H.1.2">H.1.2</a> [<strong>Information Systems</strong>]: Human information processing</li> <li><a href="http://www.acm.org/about/class/ccs98-html#H.4.m" resource="http://acm.rkbexplorer.com/ontologies/acm#H.4.m">H.4.m</a> [<strong>Information Systems Applications</strong>]: Linked Data</li> <li><a href="http://www.acm.org/about/class/ccs98-html#H.5.3" resource="http://acm.rkbexplorer.com/ontologies/acm#H.5.3">H.5.3</a> [<strong>Information Interfaces and Presentation</strong>]: Web-based interaction</li> <li><a href="http://www.acm.org/about/class/ccs98-html#I.7.4" resource="http://acm.rkbexplorer.com/ontologies/acm#I.7.4">I.7.4</a> [<strong>Document and Text Processing</strong>]: Electronic Publishing</li> </ul> </div> </section> --> <section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction"> <h2 about="#introduction" property="schema:name" typeof="deo:Introduction">Introduction</h2> <div datatype="rdf:HTML" property="schema:description"> <p><q>You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete</q> – attributed to <cite><a href="https://en.wikipedia.org/wiki/Buckminster_Fuller">Buckminster Fuller</a></cite>.</p> <p>One of the most widely debated questions in the scientific community is the impact of digitisation on scholarly communication and knowledge exchange; the Internet and the Web have radically changed the processes of scholarship [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-1">1</a>]. In this article, we propose that digitising, and indeed <cite><a href="https://www.w3.org/DesignIssues/Webize.html">Webizing</a></cite> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-2">2</a>], scholarly communication can provide greater coherency between and within academic fields, as well as make knowledge more accessible to researchers and citizens alike. Many forms of scholarship are enabled by these technology changes, be it the ability to perform social science using social media data, or large scale data processing for physics. Despite efforts through <cite>Open Access</cite> (OA) movements and the increasing availability of online publications, the formal communications mechanisms used by scholars do little to take full advantage of either the capabilities of online media, or the cultural shift towards sharing and public commentary on social networks [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-3">3</a>, <a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-4">4</a>].</p> <p>On examination, it becomes clear that there are many interrelated problems to be tackled before it will be possible to fully realise the possibilities offered by modern Web technologies in the academic space. Many of these problems are relevant in a number of domains outside of scholarly publishing, and they are each to different degrees being considered in existing or ongoing work, in both academia and industry. Our first contribution is an overview of different issues, briefly summarising the extent to which they are addressed in current work, and how they relate to and depend upon one another in the context of scholarly communication. We attempt to articulate a complete picture of the problem space of scholarly communication by defining <em>requirements</em> in response to the problems described in existing literature, or observed ‘in the field’. These requirements fall into three broad categories:</p> <ul> <li>Publishing and ownership of documents and data.</li> <li>Discovery and reuse of knowledge and data.</li> <li>User experience and tooling.</li> </ul> <p>From these requirements, we derive user stories, and explain how these may be repurposed as an <em>acid test</em> or criteria against which to evaluate proposed solutions. Our strategy for addressing the problems identified involves building upon existing technologies, standards and best practices, each of which we discuss in detail in section 4.</p> <p>Finally, we describe an implementation of the Linked Research concept for authoring, publishing and annotating research articles in a decentralised manner, based on native Web technologies. We demonstrate how multi-modal content such as video, audio, code examples and runnable experiments can be embedded into research publications, and showcase how different views of the content can be rendered for different devices (e.g. screen, print, mobile) or audiences (e.g. slide shows). A particular strength of our approach is the integration and linking of data, which can automatically update tables and diagrams when the underlying data changes. All content can be annotated and represented using semantic knowledge representation formalisms to facilitate better search, exploration, retrieval and linking of concepts and ideas. Further, our implementation takes advantage of common social media practices to enable sharing and commentary around scholarly work in both ongoing dialogue between interested parties, and more formal conference and workshop settings. We build upon emerging standards in personal data stores, annotations and social notifications to allow our implementation to be completely decentralised, reliant on no central system or hub.</p> </div> </section> <section id="requirements" inlist="" rel="schema:hasPart" resource="#requirements"> <h2 property="schema:name">Requirements</h2> <div datatype="rdf:HTML" property="schema:description"> <p>The Linked Research requirements provide a framework for thinking about how each of the various parts of the problem space of scholarly communication are connected to each other. By establishing a framework, Linked Research can be seen as both a benchmarking exercise as well as a technique to connect various technologies and approaches. The topic areas are described below, and we have identified several interdependencies between them, whereby aspects of one problem are much more easily solved alongside of or on the back of another.</p> <!--<p>*Idea: a diagram of dependencies; how solving one of these areas would facilitate the next etc?</p>--> <p>Socially, Linked Research is embedded within the <cite>Open Science</cite> movement [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-5">5</a>]. However, it explicitly calls out the role of technical choices in meeting open science goals.</p> <section id="publishing-and-ownership" rel="schema:hasPart" resource="#publishing-and-ownership"> <h3 property="schema:name">Publishing and ownership</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="requirement-open-access"><strong>Open Access</strong>: To better enable scientific progress, research work - from raw results to completed analysis - should be widely available and accessible. Maximising reach in this way increases the likelihood of further scientific progress and new discoveries [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-6">6</a>]. Ideally this is achieved by way of free-of-charge access and reuse of all material, including code, media, source text, data and metadata, so knowledge may be distributed regardless of wealth, social status or geographical location of either the researcher or the consumer. This requirement is to some extent borrowed from the well known <em>Open Access</em> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-7">7</a>] movement (though aiming to avoid the additional restrictions often imposed by publishers such as <em>Article Processing Charges</em> or <em>Gold Access</em> fees).</p> <p id="requirement-support-for-decentralised-authoring-and-publishing"><strong>Support for decentralised authoring and publishing</strong>: Research is commonly published through centralised services today. Publishers of journals or conference proceedings act as gatekeepers to work, which may only be available behind a paywall, and is required to meet criteria specific of the publishing house before it is published. Repository services allow researchers to upload their work directly to a database, but may require proprietary processing, account creation, and may distribute work only to other users of that service. If such a service shuts down, links to the work and any additional value extracted from it by the service are lost if there are no other copies. In both cases, control over access and distribution of the work is taken out of the hands of the original author, and the author may additionally be required to give up their rights to distribute their work by other means. We propose that it must be possible for authors to opt out of such functional information silos [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-8">8</a>] and publish work on their own terms, in a storage location controlled by themselves or someone they trust, without being excluded from the wider community [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-9">9</a>].</p> <p id="requirement-access-control-and-attribution"><strong>Access control and attribution</strong>: In many fields, researchers are discouraged from publishing unfinished, inconclusive or ongoing work, or publishing outside of ‘official’ venues by the risk that their work will be plagiarised or reused by another without permission or due credit. To facilitate open scientific discourse, technologies for publishing must afford a trust that sharing work will not disadvantage the author. Thus the author must have means to unambiguously attach their identifying information to their own work, and selectively grant and revoke access to others during the research process. Presently there are many services offering identifiers to creators of scholarly work: the <cite><a href="http://id.loc.gov/">Library of Congress Linked Data Service</a></cite> for personal and family names and corporate bodies, <cite><a href="https://viaf.org/">Virtual International Authority File</a></cite> (VIAF), <cite><a href="http://isni.org/">International Standard Name Identifier</a></cite> (ISNI) and the Getty’s <cite><a href="http://www.getty.edu/research/tools/vocabularies/ulan/">Union List of Artist Names</a></cite> (ULAN), <cite><a href="https://www.researchgate.net/">ResearchGate</a></cite>, <cite><a href="https://scholar.google.com/">Google Scholar</a></cite>, <cite><a href="https://www.elsevier.com/solutions/scopus">Scopus Author Identifier</a></cite>, <cite><a href="http://www.researcherid.com/">ResearcherID</a></cite>, and <cite><a href="https://orcid.org/">Open Researcher and Contributor ID</a></cite> (ORCID). These systems are minimally, if at all, interoperable without human intervention, so creating multiple profiles is common practice. Some of these systems interoperate with – not via open standards but by proprietary solutions – certain of the others, e.g., ORCID can import data from ResearcherID. It is part of our vision to empower researchers to choose an identity provider they trust or participate with their own Web identifier, which is globally recognisable and unique.</p> <p id="requirement-provenance-and-accountability-of-information"><strong>Provenance and accountability of information</strong>: Trust and confidence in data and results can be fostered by enabling reproducibility of experiments required to validate, and demonstrating a coherent explanation of the derivation of conclusions, and the agents responsible; however this tends to be a difficult challenge under current practices. Capturing scientific processes, workflows and data origins in a machine-readable way, and exposing <cite><a href="http://researchobject.org/">Research Objects</a></cite> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-10">10</a>] will further improve the utility of the scholarly contributions.</p> <p id="requirement-persitence-and-long-term-preservation"><strong>Persistence and long term preservation</strong>: Research results must be made available in such a way that access to it is reliable and consistent over time, and irrespective of place. Studies show that significant number of referenced Web resources are not preserved or are at risk of disappearing [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-11">11</a>]. Broken links, missing data, authors who move institution, organisations which close or merge or rename, and regimes which censor can all hamper access to and reuse of knowledge. A Linked Research ecosystem strives for persistent, long-term access to information as a technical and social norm by incorporating repositories in the preservation process.</p> <p id="requirement-sharing-and-social-interactions"><strong>Sharing and social interactions</strong>: Authors largely rely on third parties, including publishers and the media, to distribute and raise awareness their work. However, increasing numbers of academics are making use of social media to this end, and sharing on the Web has become a normal part of daily life for many [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-12">12</a>]. This is valuable to make use of as part of Linked Research.</p> <p id="requirement-commentary-and-feedback"><strong>Commentary and feedback</strong>: The academic peer-review process has been used to judge whether work makes contributions to the field. Studies are beginning to show the unreliability and elitist nature of this process [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-13">13</a>, <a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-14">14</a>] and thus we call for transparency and broader participation in research discourse. It should be possible and expected for anyone to review academic work, and for this review to be attributed and recognised as a contribution of the reviewer in its own right. Moreover, research has shown that transparency in the peer-review process may be an indicator of the quality of peer-review [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-15">15</a>].</p> </div> </section> <section id="discovery-and-reuse" rel="schema:hasPart" resource="#discovery-and-reuse"> <h3 property="schema:name">Discovery and reuse</h3> <div property="schema:description"> <p id="requirement-human-and-machine-readability"><strong>Human and machine-readability</strong>: Scholarly content, mostly published in binary form (e.g., PDF, Word), is currently not machine-readable to the extent that automatic post-processing is possible. Desirable modes of post-processing include sorting, aggregation and more accessible display of information, to improve the ease of use by humans. Many aggregation and indexing systems require manual input of metadata (or careful scraping by proprietary software), and authors undertake this labour, often repeatedly across different systems, for the pay-off of improving findability of their work. This labour can be avoided by generating metadata from article content and publishing it according to a standard syntax and semantics.</p> <p id="requirement-integration-of-rich-semantics"><strong>Integration of rich semantics</strong>: Within and around the prose, scholarly communication comprises rich semantic structures:</p> <ul> <li>the structure of the content, e.g. in sections, examples, definitions, theorems, notations;</li> <li>the argumentation, e.g. premises, assumptions, deductions, conclusions;</li> <li>facts and relationships between entities expressed in sentences;</li> <li>all kinds of data (examples, experiment results).</li> </ul> <p>The <cite><a href="https://www.force11.org/datacitation">Joint Declaration of Data Citation Principles</a></cite> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-16">16</a>], endorsed by over 100 organisations, explicitly calls for data to be treated the same as papers in the scholarly ecosystem, and for machine readability of the data. Similarly, the <cite><a href="http://datafairport.org/">FAIR Data principles</a></cite> for findable, accessible, interoperable and reusable data encourage the semantically interoperable reuse of data.</p> <p>Making this level of semantic structure available to machines for querying (and ultimately automated reasoning) facilitates development of intelligent support services for scholars, such as recommendation, search and comparison for related work.</p> <p id="requirement-globally-unique-identification-of-entities"><strong>Globally unique identification of entities</strong>: Our premise: <q cite="https://www.w3.org/DesignIssues/Axioms.html#Universality2">Any resource of significance should be given a URI</q> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-17">17</a>] and <q cite="https://www.w3.org/TR/webarch/#identification">The global scope of URIs promotes large-scale "network effects": the value of an identifier increases the more it is used consistently</q> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-18">18</a>]</p> <p>A research document contains references to <em>things</em>, from abstract concepts to real-world objects; anything which may be referenced from a publication (people, methods, diseases, species, organisations, and so on). For scholars it must be possible to unambiguously indicate the subjects of discussion by creating their own identifiers for these entities or by reusing existing identifiers coined by others. This is (arguably) a more accessible way to make associations between articles and data referring to the same entities than alternative natural language processing based techniques. For instance, the progressive adoption of the <cite>Digital Object Identifier</cite> (DOI) or HTTP URIs for things, along with <cite><a href="http://nanopub.org/">Nanopublications</a></cite> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-19">19</a>], makes it possible to declare and represent scientific knowledge claims that are globally identifiable on the Web [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-10">10</a>, <a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-20">20</a>]. Such initiatives for citation of research artefacts beyond the document are a strong step towards this area of Linked Research.</p> <p id="requirement-integration-of-data"><strong>Integration of data</strong>: In many cases some form of structured data is a direct subject of scholarly communication. In social sciences, for example, statistical data plays a key role as ground truth for validating or falsifying theories. Similarly, in engineering and natural sciences, measurement or observation data is of crucial importance. In the life sciences, statistics, anonymised patient data as well as taxonomic and ontological data can be central. Ideally, such data is directly integrated into the digital representation of a scholarly article in both human- and machine-readable forms. This permits both live updates to the article (including charts and figures) as new data emerges with no extra effort to the authors, and the ability for closer exploration of the data for better understanding by consumers.</p> </div> </section> <section id="user-experience-and-tooling" inlist="" rel="schema:hasPart" resource="#user-experience-and-tooling"> <h3 property="schema:name">User experience and tooling</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="requirement-integrated-authoring-and-publication-workflow"><strong>Integrated authoring and publication workflow</strong>: Researchers should be enabled as far as possible to have a seamless experience when making their work available to their community and to the general public. This spans from basic authoring of text content according to the desired layout, to embedding data and interactive elements, to managing citations, footnotes and metadata, and finally to publishing the article in the preferred location.</p> <p id="requirement-feedback-and-interactions"><strong>Feedback and interactions</strong>: When others interact with published work, for example to cite, comment, review, share, recommend or annotate, the original authors should be notified and able to view and react to any new content produced in response to their work. Conversations and commentary may be stored across different systems, however there must be a mechanism for aggregating and displaying scientific discourse around the subject resources to benefit authors and consumers alike.</p> <p id="requirement-support-for-different-views"><strong>Support for different views</strong>: Content is consumed in a wide variety of formats online and offline, on devices of different sizes and capabilities, and with different interaction techniques (touch screens, speech input/output). Scholarly communication should exploit these different media, presentation and interaction techniques to allow scholarly content to be consumed in different situations [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-21">21</a>]. The content should adapt to the available presentation capabilities, and alter its appearance according to some combination of the author's and consumer's preferences.</p> <p id="requirement-adaptation-to-audiences"><strong>Adaptation to audiences</strong>: Depending on the audience, presentation of scholarly communication should happen on different levels of granularity. For experts in the field, explanations can be shorter, examples are not required and only few illustrations are needed. For newcomers on the other hand, more detailed explanations, illustrations and examples are helpful. Ideally, scholarly content can adapt to the audience. This should happen from a single source of content to minimise the burden on the author, where content elements are marked in such a way the adaptation to the audience can be performed largely automatically.</p> <p id="requirement-integration-of-content"><strong>Integration of interactive content</strong>: Where possible, scholarly content should provide dynamic and interactive content. Examples include:</p> <ul> <li>executable software source code snippets, which demonstrate algorithms, queries, workflows etc. ([<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-22">22</a>] calls for these to be considered as a critical research output).</li> <li>interactive data visualisations with different diagram types, which allow users to zoom in, filter etc.</li> <li>small games or self assessment tests, which allow readers to interact with the content in a playful way or to test their comprehension of the knowledge</li> <li>widgets or applications, which provide interactive domain specific interactive content (e.g. exploring a large phenotype taxonomy)</li> </ul> <p id="requirement-support-for-multimedia"><strong>Support for multimedia</strong>: Multimedia content such as videos, audio, and 3D simulations can dramatically improve the comprehension of scholarly content compared to the traditional static 2D illustrations currently found in papers. In particular, fields dealing a lot with multimedia data like engineering, arts, audio and video analysis, and medicine, would benefit.</p> <p id="requirement-impact-metrics"><strong>Impact metrics</strong>: As the volume of scholastic contributions increase, investigators rely on services and filters to choose the most relevant and significant sources. What constitutes relevant and significant may be at the discretion of the service in use, and can be diverse. For instance, traditional author-level metrics while widely employed, check only the bibliographic impact. The rise and adoption of <cite>altmetrics</cite> as an alternative, aims to incorporate a wide range of information on scholarly contributions in order to derive more immediate and contextually relevant metrics e.g., <cite>webometrics</cite> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-23">23</a>]. Based on this, reward structures can then be re-engineered if reuse or repurposing of all scholarly or other contributions (e.g., data, methods, social activities and engagement, as well as non-technical implications of science) are taken into account. The availability of machine-readable altmetrics is well aligned to further facilitate Linked Research.</p> </div> </section> </div> </section> <section id="concepts" inlist="" rel="schema:hasPart" resource="#concepts"> <h2 property="schema:name">Concepts</h2> <div datatype="rdf:HTML" property="schema:description"> <p>Having defined requirements for the problem space of scholarly communication as a whole based on observations and existing work, we now consider how each topic area fits into the overall scholarly communication workflow, and indicate which of the requirements are pertinent for each stage of the process of scholarly communication. We describe expectations for each stage of the process, and propose technical solutions and methods aiming at meeting the related requirements. The Linked Research concepts and how they relate to one another is shown in Figure 1, and their relation to the requirements, technologies and stakeholders are visualised in Figure 2.</p> <p>Our primary approach is to reuse existing technologies, techniques and specifications, combined in novel ways to meet the needs we have identified. We focus on the Web as a publishing platform for distribution and consumption and content and data in a decentralised way.</p> <figure id="figure-linked-research-ecosystem" rel="schema:hasPart" resource="#figure-linked-research-ecosystem"> <object data="http://csarven.camedia/images/articles/linked-research-ecosystem.svg" height="243" rel="schema:image" type="image/svg+xml" width="480"></object> <figcaption property="schema:name">Linked Research ecosystem.</figcaption> </figure> <figure id="figure-links" rel="schema:hasPart" resource="#figure-links"> <object data="http://csarven.camedia/images/articles/links-technologies-requirements-concepts-stakeholders.svg" height="299" rel="schema:image" type="image/svg+xml" width="480"></object> <figcaption property="schema:name">Links between technologies, requirements, concepts and stakeholders.</figcaption> </figure> <section id="research-authoring" inlist="" rel="schema:hasPart" resource="#research-authoring"> <h3 property="schema:name">Research authoring</h3> <div> <p>Frontend Web technologies – e.g., HTML, CSS and JavaScript – can be purposed towards authoring tools that are straightforward to use for authors and that require no proprietary software or special configurations; all that is needed is a Web browser. Such tools can be used to edit local files when the author is in <em>offline mode</em> or without an internet connection, but can support writing directly to a personal data store or server when the author is online to facilitate collaboration. Authors can easily go beyond textual content, and embed data, interactive or multimedia elements into their work with native Web components. This is a well-established practice in the social Web, e.g., blogging. Authoring tools built on the Web can be extended or built upon with little overhead to meet specific needs of researchers.</p> <p>Semantic Web technologies have been widely embraced by the librarian community for organising traditional scholarly content as well as exposing the rich terminological systems underlying such content [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-24">24</a>]. For example, the BIBFRAME initiative aims to ease the transition from MARC metadata records to web enabled metadata systems, and both CrossRef and DataCite DOIs support Content Negotiation allowing multiple representations including machine readable representations to be returned.</p> <p>We propose to use RDFa embedded in HTML together with established vocabularies to add fine-grained semantics to prose content, including metadata (e.g. authors, keywords), document structure (e.g. abstract, conclusion), components and concepts being described (e.g. methodological steps, hypotheses, specific instances of things). A browser-based authoring tool should both automatically generate RDFa where possible, and provide a user-friendly interface to allow the author to add semantics themselves. We argue that researchers should <em>not</em> be expected to write source code, including any form of HTML.</p> </div> </section> <section id="research-publishing" inlist="" rel="schema:hasPart" resource="#research-publishing"> <h3 property="schema:name">Research publishing</h3> <div> <p>The Linked Research initiative encourages researchers to work transparently, publish early and often and without asking for permission. The Web provides the perfect platform for this. Ideally authors should acquire their own domain name and Web hosting; we acknowledge that this is not always possible or practical, though many institutions provide basic Web hosting and a URL space for all of their staff and students. Hence, employing DOI, <a href="https://en.wikipedia.org/wiki/Persistent_uniform_resource_locator">PURL</a>, <a href="http://w3id.org/">w3id</a>, or alike are possible ways to have some level of permanence for the information.</p> <p>Publishing work online in static HTML allows wide accessibility for consumers and for added value services. Using CSS and JavaScript makes it possible to refine, adapt or even provide alternative views on a research document according to the consumer’s needs or viewing context.</p> <p>Distributing work with URLs allows sharing equally between academics and specialists, and interested citizens. Linking between articles enhances discoverability, and coupling this with social notifications (<cite><a href="http://www.w3.org/TR/activitystreams-core/">ActivityStreams 2.0</a></cite> is an appropriate emerging W3C standard which would enable interoperability with other social systems) allows authors to track citations, the reach of their work, and receive and display responses and feedback.</p> <p>It is important to include licensing information with published work in order to promote fair use and remixing for content creators. We do not presume to dictate the most appropriate licenses for academic work to be released under, however it is worth emphasising that establishing common practices around open licenses such as those from the Creative Commons family is important to encourage a culture of openness and reuse, which, as we previously discussed, is important for a healthy scientific progress.</p> <section id="call-for-contributions" inlist="" rel="schema:hasPart" resource="#call-for-contributions"> <h4 property="schema:name">Calls for Contributions</h4> <div datatype="rdf:HTML" property="schema:description"> <p>Calls for contributions to journals and conferences are usually published online, and an increasing number of venues are accepting HTML submissions e.g., <cite><a href="http://events.linkeddata.org/ldow2016/">LDOW</a></cite>, <cite><a href="http://iswc2016.semanticweb.org/pages/calls/html-submission.html">ISWC</a></cite>, <cite><a href="http://semstats.org/2015/call-for-papers">SemStats</a></cite>. A step further to encourage ownership and control over research work is to accept submission by URL, whereby the authors submit notifications of a ‘reply’ to a call.</p> <p>While most calls for contributions are available in plain and simple HTML, they are typically not semantically enriched. Making their semantics explicit and then publishing them in compliance with the Linked Data design principles would improve their interlinkability with other knowledge graphs such as research articles or social feedback. Composing the call with additional structured data, for instance with concepts from controlled taxonomies (e.g., SKOS, DBpedia), topical requirements, and a list of contributors for peer-reviewing, enables better mining of such data. It can be purposed towards discovery calls suitable for a paper draft (i.e. <em>venue recommendation</em>), relating one call with similar calls, as well as watching the evolution of topical trends in research communities [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-25">25</a>].</p> </div> </section> <section id="peer-reviews-and-interactions" inlist="" rel="schema:hasPart" resource="#peer-reviews-and-interactions"> <h4 property="schema:name">Peer-reviews and Interactions</h4> <div datatype="rdf:HTML" property="schema:description"> <p>In a Linked Research community, reviewers are able to see replies to a call they have, or have <em>been</em>, subscribed to, and in turn leave their reviews as replies to the submitted articles. Rather than centralistic submission and review management systems such as <cite><a href="http://www.easychair.org">EasyChair</a></cite>, we employ workflows for ‘sharing’ that people are nowadays used to from social media. As peer-reviews are valuable contributions to the academic ecosystem, we encourage reviewers to <em>publish</em> their reviews in a Web space that they control (or trust), for the benefit of the community, in just the same manner as research articles themselves are published. With the optional adoption of attributed peer-reviews, responses can be rigorous and objective, while retaining transparency and identity of the reviewers. These open reviews are also available for the community to discuss and build on.</p> </div> </section> <section id="proceedings" inlist="" rel="schema:hasPart" resource="#proceedings"> <h4 property="schema:name">Proceedings</h4> <div datatype="rdf:HTML" property="schema:description"> <p>Editors and committees who have issued calls for contributions are able to take into account reviews and discussion on work they have been notified about, and select the articles to aggregate and formally endorse them as part of their journal or event proceedings. The same Web-based tooling which allowed authoring of articles, calls and reviews and notifications of responses in the first place can be purposed to automatically assemble and re-publish the chosen work as a collection, which can in turn be shared and responded to.</p> </div> </section> </div> </section> <section id="persistence-and-preservation" inlist="" rel="schema:hasPart" resource="#persistence-and-preservation"> <h3 property="schema:name">Persistence and Preservation</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Ensuring the persistence of scientific results through time is of fundamental importance: readers should be able to access articles published in the past, authors should be able to point to articles and the statements within with confidence that they will be accessible in the future. As of today, archiving and preserving scientific documents are commonly considered the responsibilities of publishers. In the context of Linked Research, where decentralised authoring and publishing is promoted, responsibilities are to be re-evaluated: authors can publish their results online at a service of their choice, such as their own website. However, persisting academic publishing on long-term on the web has two main challenges which may be difficult for individuals to solve when hosting content themselves: 1) availability on the Internet (keeping the document/data server available, maintaining it, and defending it from attacks), and 2) presence on the Web; namely, maintaining a URL that points to the document/data and that does not change. Long-term obstacles to this include URL expiration, revocation (in case of someone taking legal action) and censorship [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-26">26</a>].</p> <p>We already see many efforts at centralised archives - <cite><a href="http://archive.org/">Internet Archive</a></cite>, <cite><a href="https://archive-it.org/">Archive-It</a></cite>, <cite><a href="http://arxiv.org/">arXiv</a></cite>, <cite><a href="https://www.clockss.org/">CLOCKSS</a></cite>, <cite><a href="http://zenodo.org/">Zenodo</a></cite> - however these are each a single point of failure for long-term persistence. In the case of self-archiving, the author is responsible for maintaining their service and domain name. This strategy clearly has non-trivial disadvantages: technical expertise is required, there are maintenance costs, and content may disappear if the author loses the ability to keep this up. In the case of third-party archival, although the responsibilities are delegated a service, this may cease to exist long term, or may act against the interest of the user.</p> <p>An architecture in which documents are replicated on multiple servers can work towards solving these problems. If the URL is not reachable, the reader should be able to get a copy the content from elsewhere. <q>Lots of Copies Keep Stuff Safe</q> is the idea behind <a href="http://www.lockss.org/">LOCKSS</a>, a project that aims to create a network of libraries and publishers that replicate scientific articles amongst the others [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-27">27</a>], based on this idea there is other work that uses existing distributed networks such as BitTorrent [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-28">28</a>].</p> <p>When content is distributed across a decentralised network, documents must have pointers that the network agrees upon. This can be simply done by naming documents via their hashes, as in the InterPlanetary File System (IPFS). This also allows proof that the file hasn't been altered by nodes in the network, since verification would mean re-hashing the file. Recent works show how we can use <cite><a href="http://trustyuri.net/">Trusty URIs</a></cite> to employ hashing techniques whilst remaining compatible on the Web [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-29">29</a>].</p> <p>Ultimately in a Linked Research ecosystem, the role of content creators is also to distribute the content, and a role of public institutions in supporting preservation is to provide reliable hosting, addressing and backup in a decentralised manner. We envision a two-way system. Organisations such as libraries and universities can actively create collections by selecting, sorting and storing published articles. Additionally, authors can submit work themselves to archives, for either consideration by curators or automatic inclusion for backup. Currently in order to do this scholars submit their work manually into different systems, which can result in inconsistent or infrequent updates. To improve on this, the same open Web protocols as described for calls and proceedings can be used to automatically notify chosen archives whenever a new piece of work or dataset is ready.</p> </div> </section> <section id="profiles-and-reputation" inlist="" rel="schema:hasPart" resource="#profiles-and-reputation"> <h3 property="schema:name">Profiles</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Just as authors can choose domains they trust to identify their work, they can also create URIs to identify themselves. By connecting this identifier to all of their publications, results and impact of the work they are involved with can be traced directly back to them. Researchers can build a profile which automatically includes their published work and their feedback on the work of others.</p> <p>Currently, many academics choose to create professional profiles on centralised systems such as <cite><a href="http://impactstory.com">ImpactStory</a></cite>, <cite><a href="https://scholar.google.com">Google Scholar</a></cite>, <cite><a href="https://researchgate.net">ResearchGate</a></cite>, <cite><a href="https://zenodo.org">Zenodo</a></cite> or <cite><a href="http://academia.edu">Academia.edu</a></cite>. Such systems are poorly integrated with each other, and users frequently must enter their details repeatedly or choose one system and miss out on potentially connecting with members of others. Similarly from within one system, users cannot see the activities of users in other systems, even though many of the types of social activities afforded by the systems (reading or recommending a paper for example) are the same.</p> </div> </section> </div> </section> <section id="user-stories" rel="schema:hasPart" resource="#user-stories"> <h2 property="schema:name">User Stories</h2> <div datatype="rdf:HTML" property="schema:description"> <p>We describe an <em>acid test</em> so that systems can be evaluated against the requirements of Linked Research previously outlined. The evaluation is intended to verify the openness, accessibility, decentralisation, interoperability of approaches in scholarly communication, and takes the form of a series of user stories which cover the full spectrum of scholarly communication and which must be feasible to carry out with the proposed system. This test does not mandate a specific technology, therefore the challenge can be met by different solutions. It is intended to test the design philosophies so that different approaches may be closer to passing the <em>independent invention</em> test.</p> <p>This acid test is extended from <cite><a href="http://csarven.ca/enabling-accessible-knowledge#acid-test" rel="prov:wasDerivedFrom">Enabling Accessible Knowledge Acid Test</a></cite> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-30">30</a>] to encompass more aspects of the academic workflow, beyond authoring and publishing research articles. The acid test constitutes <em>assumptions</em> about proposed solutions and <em>challenges</em> that proposed solutions must meet one or more of.</p> <dl id="user-stories-assumption"> <dt>Assumptions</dt> <dd> <ul> <li id="user-stories-assumption-open-standards" rel="schema:hasPart"><span property="schema:description" about="#user-stories-assumption-open-standards" typeof="doco:Sentence">All interactions conform with open standards, with 1) no dependency on proprietary APIs, protocols, or formats, and 2) no commercial dependency or priori relationship between the groups using the workflows and tools involved.</span></li> <li id="user-stories-assumption-publishing" rel="schema:hasPart"><span property="schema:description" about="#user-stories-assumption-publishing" typeof="doco:Sentence">Any mechanisms are available through at least two different interoperable tool stacks.</span></li> <li id="user-stories-assumption-free-and-open-access" rel="schema:hasPart"><span property="schema:description" about="#user-stories-assumption-free-and-open-access" typeof="doco:Sentence">Information and interactions are available for free and open access with suitable licensing and attribution for retrieval and reuse.</span></li> <li id="user-stories-assumption-human-and-machine-readable" rel="schema:hasPart"><span property="schema:description" about="#user-stories-assumption-human-and-machine-readable" typeof="doco:Sentence">Information is both human and machine-readable.</span></li> <li id="user-stories-assumption-prior-knowledge" rel="schema:hasPart"><span property="schema:description" about="#user-stories-assumption-prior-knowledge" typeof="doco:Sentence">All interactions are possible without prior out-of-band knowledge of the user’s environment or configuration.</span></li> </ul> <span rel="schema:hasPart"><span content="There is no spoon." property="schema:description" resource="#user-stories-assumption-spoon" typeof="doco:Sentence"></span></span> </dd> </dl> <dl id="user-stories-challenges"> <dt>Challenges</dt> <dd> <ol> <li id="user-stories-challenge-availability" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-availability" typeof="doco:Sentence">Alexander makes his article available on the Web with the research objects available at fine granularity, e.g., variables of a hypothesis.</span></li> <li id="user-stories-challenge-reference" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-reference" typeof="doco:Sentence">Beverly references and discusses Alexander’s research objects from her own research article, e.g., an argument against a methodological step.</span></li> <li id="user-stories-challenge-annotation" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-annotation" typeof="doco:Sentence">Carol annotates Beverly’s argument on Alexander’s work by suggesting that it was misinterpreted, and stores the note publicly at her own personal content store.</span></li> <li id="user-stories-challenge-review" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-review" typeof="doco:Sentence">Darmok and Eve write reviews for Beverly’s article and store them at their preferred locations respectively; Beverly is notified about the reviews.</span></li> <li id="user-stories-challenge-call-for-contributions" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-call-for-contributions" typeof="doco:Sentence">Frank publicly announces a call for contributions for an academic conference. He specifies the scope of the call and desired qualities of the submissions.</span></li> <li id="user-stories-challenge-reply-to-call" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-reply-to-call" typeof="doco:Sentence">Guinan notices Frank’s call for contributions to be suitable for her research article, and submits a link to her work. In her article, Guinan indicates that it was a reply to the call.</span></li> <li id="user-stories-challenge-peer-review" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-peer-review" typeof="doco:Sentence">Frank assigns Herman, Inigo, and Jean-Luc to peer-review Guinan’s work. Herman and Inigo both write their reviews so that only Frank and Guinan may read them; meanwhile Jean-Luc makes his review public.</span></li> <li id="user-stories-challenge-proceedings" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-proceedings" typeof="doco:Sentence">Keiko is assisting Frank, and compiles a list of articles which meet the requirements and standards of Frank’s call for contributions based on reviews and public feedback. She sends alerts to various institutions that the proceedings are ready to be archived.</span></li> <li id="user-stories-challenge-library" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-library" typeof="doco:Sentence">Liz manages scholarly archiving at her institution; she retrieves and catalogues the articles which were mentioned for library indexing.</span></li> <li id="user-stories-challenge-interaction" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-interaction" typeof="doco:Sentence">Marshall is a PhD student; he uses the interactive components in Beverly’s article by changing the parameters and rerunning an experiment and decides to expand on this for his own work.</span></li> <li id="user-stories-challenge-views" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-views" typeof="doco:Sentence">Nelson reads Alexander’s article from his handheld device, and prints a single page summary.</span></li> <li id="user-stories-challenge-archives" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-arhives" typeof="doco:Sentence">Ophelia notices the new index of articles in response to Frank’s call and selects the ones she is interested in for her personal collection of potential references.</span></li> <li id="user-stories-challenge-discovery" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-discovery" typeof="doco:Sentence">Paris sees the peer-reviews about Guinan’s work and proceeds to discover further information about the qualifications and experience of the reviewers.</span></li> <li id="user-stories-challenge-personal-annotations" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-personal-annotations" typeof="doco:Sentence">At Frank’s conference, Q listens to the presentations from the authors and makes personal notes about the work; he occasionally makes his observations visible to the authors or rest of the conference audience.</span></li> <li id="user-stories-challenge-forecast-fields" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-forecast-fields" typeof="doco:Sentence">Rajiya aggregates all of the scholarly communication available in the last 5 years, and builds a visualisation to analyze research gaps. She then forecasts emerging fields.</span></li> <li id="user-stories-challenge-funding-opportunities" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-funding-opportunities" typeof="doco:Sentence">Sahrahsahe builds a profile of her research lab, and runs a comparative analysis to check which funding opportunities that are applicable with good chances to obtain the grants.</span></li> <li id="user-stories-challenge-controversial-research" rel="schema:hasPart"><span property="schema:description" about="#user-stories-challenge-controversial-research" typeof="doco:Sentence">Tabitha is interested in identifying research articles that generate controversial social activity, so she runs a filter for long running discussions with varying social reactions in a community query service.</span></li> </ol> </dd> </dl> <p>From these challenges, we see how the requirements and concepts laid out previously fit into various stages of academic workflow. Solutions which meet one or more of these challenges, according to the assumptions, can be considered conformant with Linked Research principles.</p> </div> </section> <section id="realisation" inlist="" rel="schema:hasPart" resource="#realisation"> <h2 property="schema:name">Realisation</h2> <div datatype="rdf:HTML" property="schema:description"> <p>In this section we describe our own implementations, which aim at fulfilling some of the requirements stated previously. We pay particular attention to rich, semantic authoring, and decentralised publishing of both content, data and feedback. We describe the technologies we used to meet each requirement, and how we combined certain technologies and approaches in novel ways. We conclude with a brief discussion of requirements yet to be met and how we plan to go about tackling these.</p> <section id="authoring-and-publishing" inlist="" rel="schema:hasPart" resource="#authoring-and-publishing"> <h3 property="schema:name">Authoring and publishing</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="dokieli"><cite><a href="http://csarven.ca/dokieli">dokieli</a></cite> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-31">31</a>] is an open source, progressively enhanced client application for decentralised authoring, with specialisations for writing academic documents. This includes a rich text editor for writing and arranging prose content, as well as embedding data, runnable code, and media (see <cite><a href="http://csarven.ca/this-paper-is-a-demo">This ‘Paper’ is a Demo</a></cite> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-21">21</a>] for a demonstration) which generates an HTML+RDFa source automatically. The UI also allows users to add fine-grained semantics by hand, including assigning URIs to concepts at any level and relationships between them, without the need to edit source code. Concepts within a single document can be related to each other with the appropriate RDF properties, as well as creating specific relations with external resources.</p> <p>In addition, metadata that does not easily fit into prose (for example, Nanopublications) can be embedded as a single block using formats RDF Turtle, JSON-LD, or TriG.</p> <p>dokieli does not mandate the use of any particular RDF vocabularies, as the subject and content of an article determine how it is best described. By default, dokieli documents make use of <cite><a href="https://schema.org/">schema.org</a></cite> for common terms for Web documents, the <cite><a href="http://purl.org/spar">SPAR Ontologies</a></cite> for publishing and referencing [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-32">32</a>], <cite><a href="http://www.w3.org/ns/oa">Web Annotations</a></cite> for comments and peer-reviews, <cite><a href="http://www.w3.org/ns/activitystreams">ActivityStreams</a></cite> for social inbox notifications, the <cite><a href="http://www.w3.org/ns/ldp">Linked Data Platform</a></cite> and <cite><a href="https://github.com/solid/vocab">Solid</a></cite> vocabularies for personal storage and user preferences, and the <cite><a href="http://www.w3.org/ns/auth/acl">ACL</a></cite> vocabulary for access control.</p> <p id="storage">Articles may be stored on the user’s local filesystem or hosted on ordinary Web servers which can serve static HTML files, for example: university user pages, code repositories, personal or company web spaces, or any file hosting service.</p> <p id="solid">Additionally, dokieli is compliant with <cite><a href="https://github.com/solid/solid-spec">Solid</a></cite>, a set of protocols and conventions based on the <cite><a href="https://www.w3.org/TR/ldp/">Linked Data Platform</a></cite> recommendation. This incorporates authentication, access control and read and write access to a personal data store. Hosting a dokieli document on a Solid server allows the author to edit the document directly in-browser, and save back to a space they control, and grant permissions to collaborators to do so as well. There are a number of open source Solid server implementations already, and users may host their own or choose a provider. There also exist <a href="https://github.com/solid/solid-platform">Solid tools and libraries</a> to help developers to build their own Solid-compliant data store.</p> <p id="authentication-and-access-control">People identify themselves to a dokieli document through <cite><a href="https://www.w3.org/2005/Incubator/webid/spec/tls/">WebID-TLS</a></cite> authentication. This allows users to maintain a profile at a location of their choosing, and the dokieli instance to write to any Solid-compliant data space which the user is authorised to write to. This is how users can, for example, save changes to a document, or store interactions such as comments.</p> </div> </section> <section id="peer-review-and-interactions" inlist="" rel="schema:hasPart" resource="#peer-review-and-interactions"> <h3 property="schema:name">Peer review and interactions</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="interactions">We support the rights of authors to own their data, and store and publish it where they feel most comfortable. This includes the social interactions and feedback users make around existing publications. Rather than centralising these interactions around the subject document, we took the decision to default to decentralisation of all content by allowing users to authenticate with their personal data space, and choose the location for their interactions at the point of making them. This gives rise to the need for a mechanism to notify the original author that their document has received some interaction. We achieve this by allowing document authors to specify an <em>inbox</em> for either their article as a whole, or any subsection with its own URI using the Solid <code>inbox</code> predicate. Inboxes are containers in a data space which may be appended to by anyone, and do not need to be on the same server as the document itself; if one article has multiple inboxes they can be distributed across as many data spaces as is convenient for the author(s). When an annotation is made, dokieli follows the appropriate <code>inbox</code> link and writes a notification there (see <a href="http://csarven.ca/linked-research-scholarly-communication#figure-interactions-create">figure 3</a> for this process and <a href="http://csarven.ca/linked-research-scholarly-communication#solid-notification">listing 1</a> for notification contents). When the document is loaded, links are followed to all inboxes in order to retrieve interactions there have been notifications about, so that these can be displayed along with the document (<a href="http://csarven.ca/linked-research-scholarly-communication#figure-interactions-display">figure 4</a> and <a href="http://csarven.ca/linked-research-scholarly-communication#figure-dokieli-interactions">figure 5</a>).</p> <figure id="figure-interactions-create" rel="schema:hasPart" resource="#figure-interactions-create"> <object data="http://csarven.camedia/images/articles/interactions-create.svg" height="504" rel="schema:image" type="image/svg+xml" width="480"></object> <figcaption property="schema:name">What happens when a user creates an interaction on an article.</figcaption> </figure> <figure class="listing" id="solid-notification" rel="schema:hasPart" resource="#solid-notification"> <pre about="#solid-notification" property="schema:description" typeof="fabio:Script"> <code>@prefix xsd: &lt;http://www.w3.org/2001/XMLSchema#&gt; .</code> <code>@prefix schema: &lt;https://schema.org/&gt; .</code> <code>@prefix solid: &lt;http://www.w3.org/ns/solid/terms#&gt; .</code> <code>@prefix as: &lt;https://www.w3.org/ns/activitystreams#&gt; .</code> <code>@prefix oa: &lt;http://www.w3.org/ns/oa#&gt; .</code> <code>@prefix c: &lt;https://creativecommons.org/licenses/by/4.0/&gt; .</code> <code>&lt;&gt; a as:Announce ;</code> <code> as:<strong class="highlight-object">object</strong> &lt;http://example.net/foo/abc123&gt; ;</code> <code> as:<strong class="highlight-target">target</strong> &lt;http://example.org/article#conclusions&gt; ;</code> <code> as:updated "2016-01-24T00:00:00Z"^^xsd:dateTime ;</code> <code> as:actor &lt;http://csarven.ca/#i&gt; ;</code> <code> schema:license c: .</code> </pre> <figcaption property="schema:name">A Solid inbox notification.</figcaption> </figure> <figure id="figure-interactions-display" rel="schema:hasPart" resource="#figure-interactions-display"> <object data="http://csarven.camedia/images/articles/interactions-display.svg" height="393" rel="schema:image" type="image/svg+xml" width="480"></object> <figcaption property="schema:name">How interactions are displayed on an article.</figcaption> </figure> <figure id="figure-dokieli-interactions" rel="schema:hasPart" resource="#figure-dokieli-interactions"> <img height="350" rel="schema:image" src="http://csarven.camedia/images/articles/dokieli-interactions.png" width="480" /> <figcaption property="schema:name">Interactions on a document.</figcaption> </figure> <p>An author can also opt to allow anonymous interactions with their documents by pointing to a publicly writeable storage location in their own space, and store interactions on behalf of their audience. Conversely, an author who does not want to display interactions on their article can omit the inbox, but readers can still save notes on an article for their own use, using the same mechanism.</p> <p>A dokieli research article can contain a relationship e.g., <code class="highlight-reply_of">as:inReplyTo</code>, to the call for contributions. That is, every scholarly article can be written in context of the conferences’ or journals’ call for contributions This current article on Linked Research is a reply to <cite><a href="http://ht.acm.org/ht2016/calls">ACM Hypertext 2016 Calls for Contributions</a></cite>, and contains an RDF statement as follows:</p> <figure class="listing" id="linked-research-in-reply-to-acm-hypertext" rel="schema:hasPart" resource="#linked-research-in-reply-to-acm-hypertext"> <pre about="#linked-research-in-reply-to-acm-hypertext" property="schema:description" typeof="fabio:Script"> <code>@prefix sioc: &lt;http://rdfs.org/sioc/ns#&gt; .</code> <code>&lt;<a href="http://csarven.ca/linked-research-scholarly-communication">http://csarven.ca/linked-research-scholarly-communication</a>&gt;</code> <code> <strong class="highlight-reply_of">as:inReplyTo</strong> &lt;<a href="http://ht.acm.org/ht2016/calls">http://ht.acm.org/ht2016/calls</a>&gt; .</code> </pre> <figcaption property="schema:name">Current article in reply to ACM Hypertext 2016 Call for Contributions (shown using the RDF Turtle syntax).</figcaption> </figure> </div> </section> <section id="semstats-call-for-contributions" inlist="" rel="schema:hasPart" resource="#semstats-call-for-contributions"> <h3 property="schema:name">SemStats Call for Contributions</h3> <div datatype="rdf:HTML" property="schema:description"> <p><cite><a href="http://semstats.org/">SemStats</a></cite> is a workshop that explores and strengthens the relationship between the Semantic Web and statistical communities. We have published all material on the site for the years 2013, 2014, and 2015 in HTML+RDFa using dokieli’s tooling. It contains interlinks like:</p> <ul> <li>The <cite><a href="http://semstats.org/2013/">SemStats 2013</a></cite> workshop is a <code class="highlight-reply_of">as:inReplyTo</code> to <a href="http://iswc2013.semanticweb.org/content/call-workshops.html">ISWC 2013 Call for Workshops</a></li> <li>The SemStats 2013 workshop also <code class="highlight-hasPart">schema:hasPart</code> <cite><a href="http://semstats.org/2013/call-for-papers">SemStats 2013 Call for Papers</a></cite></li> <li>SemStats 2013 Call for Papers then contains statements like: description, topic of interest, motivation, keywords, event data, related links, organising committee and affiliations.</li> </ul> </div> </section> <section id="semstats-ceur-proceedings" inlist="" rel="schema:hasPart" resource="#semstats-ceur-proceedings"> <h3 property="schema:name">SemStats CEUR Proceedings</h3> <div datatype="rdf:HTML" property="schema:description"> <p>In response to the SemStats 2013–2015 calls for papers, several papers have been submitted to the workshop. Those that were accepted for publication became part of the proceedings. Still, if one such paper had previously been published at its own URI, the proceedings version points there. We have published the SemStats proceedings at CEUR-WS.org (see, e.g., <a href="http://ceur-ws.org/Vol-1549/">http://ceur-ws.org/Vol-1549/</a>) and at the same time introduced a modernised version of the CEUR-WS.org proceedings template based on dokieli’s HTML and CSS (but without JavaScript, which is not permitted by the CEUR-WS.org policy). Figure <a href="http://csarven.ca/linked-research-scholarly-communication#figure-article-acalls-proceedings">6</a> demonstrates the interlinks between the peer-reviewed research article; <cite><a href="http://csarven.ca/linked-statistical-data-analysis">Linked Statistical Data Analysis</a></cite>, SemStats 2013 call for contributions, ISWC 2013 call for workshops, and the proceedings of the SemStats workshop at CEUR-WS.org.</p> </div> </section> <div id="article-calls-proceedings" class="tabs"> <nav> <ul> <li class="selected"><a href="http://csarven.ca/linked-research-scholarly-communication#figure-article-calls-proceedings">Graph</a></li> <li><a href="http://csarven.ca/linked-research-scholarly-communication#script-article-calls-proceedings">Turtle</a></li> </ul> </nav> <figure class="selected" id="figure-article-calls-proceedings" rel="schema:hasPart" resource="#figure-article-calls-proceedings"> <object data="http://csarven.camedia/images/articles/calls-and-proceedings-graph.svg" height="253" rel="schema:image" type="image/svg+xml" width="480"></object> <figcaption property="schema:name">RDF statements interlinking a research article, call for contributions and workshops, and proceedings.</figcaption> </figure> <figure class="listing" id="script-article-calls-proceedings" rel="schema:hasPart" resource="#script-article-calls-proceedings"> <pre about="#script-article-calls-proceedings" property="schema:description" typeof="fabio:Script"> <code>@prefix sioc: &lt;http://rdfs.org/sioc/ns#&gt; .</code> <code>@prefix schema: &lt;https://schema.org/&gt; .</code> <code>@prefix bibo: &lt;http://purl.org/ontology/bibo/&gt; .</code> <code>&lt;<a href="http://semstats.org/2013/">http://semstats.org/2013/</a>&gt;</code> <code> as:inReplyTo &lt;<a href="http://iswc2013.semanticweb.org/content/call-workshops.html">http://iswc2013.semanticweb.org/content/call-workshops.html</a>&gt; ;</code> <code> <strong class="highlight-hasPart">schema:hasPart</strong> &lt;<a href="http://semstats.org/2013/call-for-papers">http://semstats.org/2013/call-for-papers</a>&gt; .</code> <code>&lt;<a href="http://csarven.ca/linked-statistical-data-analysis">http://csarven.ca/linked-statistical-data-analysis</a>&gt;</code> <code> <strong class="highlight-reply_of">as:inReplyTo</strong> &lt;<a href="http://semstats.org/2013/call-for-papers">http://semstats.org/2013/call-for-papers</a>&gt; ;</code> <code> bibo:citedBy &lt;<a href="http://ceur-ws.org/Vol-1549/">http://ceur-ws.org/Vol-1549/</a>&gt; .</code> <code>&lt;<a href="http://ceur-ws.org/Vol-1549/">http://ceur-ws.org/Vol-1549/</a>&gt;</code> <code> schema:hasPart &lt;<a href="http://ceur-ws.org/Vol-1549/#article-06">http://ceur-ws.org/Vol-1549/#article-06</a>&gt; .</code> <code>&lt;<a href="http://ceur-ws.org/Vol-1549/#article-06">http://ceur-ws.org/Vol-1549/#article-06</a>&gt;</code> <code> bibo:uri &lt;<a href="http://csarven.ca/linked-statistical-data-analysis">http://csarven.ca/linked-statistical-data-analysis</a>&gt; .</code> </pre> <figcaption property="schema:name">RDF statements interlinking a research article, call for contributions and workshops, and proceedings.</figcaption> </figure> </div> <script>DO.U.showAsTabs('article-calls-proceedings');</script> <section id="future-work" inlist="" rel="schema:hasPart" resource="#future-work"> <h3 property="schema:name">Ongoing and Future Work</h3> <div datatype="rdf:HTML" property="schema:description"> <p>There remains a number of features to add to our implementation to meet more of the requirements of the acid test.</p> <p><strong>Archiving and preservation</strong>: Organisations (or indeed individuals) who wish to make their resources available for archiving work can advertise this fact through linking to an inbox where <em>requests to archive</em> can be sent, optionally along with criteria (human- and machine-readable) which submitted material must meet. Requesting inclusion in an archive involves the same underlying mechanism as any kind of notification to an inbox (replying to a call, creating an annotation), though there are user interface optimisations we can make to streamline the process. Similarly for the managers of an archival collections, the technical mechanism for duplicating a document and creating a new URI exist in current ‘Save As’ functionality, however we can automate this for submissions to archives, whilst generating new semantic relations between the original documents and archival copies such as <code>sameAs</code> or <code>derivedFrom</code>.</p> <p><strong>Collections</strong>: Personal collections of work are similar to archives, proceedings and journals, except that one user is adding third-party documents to a collection over which they have control, so there is no request/accept process for something to be included. This is therefore similar to <em>bookmarking</em>, and it is likely that a <em>reference</em> to the original rather than a direct copy will be stored in the collection owner’s space. dokieli functionality for managing collections of all kinds will also facilitate these kinds of personal collections, including the option to send a notification to the original author to let them know their work has been bookmarked. A particular use for this is for when a collection owner is writing their own academic article, and is able to auto-populate references and citations from their collections.</p> <p><strong>Profiles</strong>: An extension to dokieli which allows authors to pre-fill their affiliations and contact details permits automatic population of this data in new articles. Additionally, dokieli can automatically update an academic profile at the author’s own domain whenever new publications are authored or feedback left on the work of others.</p> <p><strong>Notifications and feedback</strong>: We do not currently have good tooling for management of notifications and feedback on articles, particularly if feedback is able to be of different types (e.g. suggestions, questions, disagreements, notes) that maybe subsequently resolved by article authors. This may be in the form of an extension or separate, generalisable, application outside of the dokieli core.</p> <p><strong>Versioning</strong>: Much research is evolving, ongoing work, and we require a solution for better management and identification of snapshots of articles; in particular to associate feedback with a specific version of work which may be subsequently addressed, or to show which iteration of an article was accepted to a conference or journal.</p> </div> </section> </div> </section> <section id="related-implementations" inlist="" rel="schema:hasPart" resource="#related-implementations"> <h2 property="schema:name">Related Implementations</h2> <div datatype="rdf:HTML" property="schema:description"> <p>Taking the Linked Research requirements as a baseline and the acid test as a tool, we reviewed some of the existing related systems with regard to how well they satisfy the requirements. <a href="http://csarven.ca/linked-research-scholarly-communication#comparison-publishing-consuming-systems">Table 1</a> shows the results of profiling the systems against the requirements using the acid test. We do not expect any one tooling to meet all of these requirements, and it is even preferable to strive for interoperable tools which are specialised.</p> <table id="table-comparison-publishing-consuming-systems" class="comparison-columns"> <caption>Comparison of publishing and consuming systems</caption> <thead> <tr> <th>System/tooling</th> <th><abbr title="Decentralised authoring and publishing">DAaP</abbr></th> <th><abbr title="Access control and attribution">ACaA</abbr></th> <th><abbr title="Provenance and accountability">PaA</abbr></th> <th><abbr title="Persistence and preservation">PaP</abbr></th> <th><abbr title="Sharing and social interactions">SaSI</abbr></th> <th><abbr title="Commentary and feedback">CaF</abbr></th> <th><abbr title="Human and machine-readability">HaMR</abbr></th> <th><abbr title="Integration of semantics">IoS</abbr></th> <th><abbr title="Entity identifiers">EI</abbr></th> <th><abbr title="Data integration">DI</abbr></th> <th><abbr title="Integrated authoring and publication workflow">IAaPW</abbr></th> <th><abbr title="Feedback and interactions">FaI</abbr></th> <th><abbr title="Different views and media">DVaM</abbr></th> <th><abbr title="Adaptation to audiences">AtA</abbr></th> <th><abbr title="Interactive content">IC</abbr></th> <th><abbr title="Multimedia">M</abbr></th> <th><abbr title="Impact metrics">IM</abbr></th> </tr> </thead> <tfoot> <tr> <td colspan="18"> <p>* Open Science Framework (OSF) is <q>one centralised location</q> which integrates with Dropbox, GitHub, Amazon Web Services, Box, Google Drive, Figshare, the Dataverse project, Mendeley</p> <dl class="abbr"> <dt>ACaA</dt><dd>Access control and attribution</dd> <dt>AtA</dt><dd>Adaptation to audiences</dd> <dt>CaF</dt><dd>Commentary and feedback</dd> <dt>DAaP</dt><dd>Decentralised authoring and publishing</dd> <dt>DI</dt><dd>Data integration</dd> <dt>DVaM</dt><dd>Different views and media</dd> <dt>EI</dt><dd>Entity identifiers</dd> <dt>FaI</dt><dd>Feedback and interactions</dd> <dt>HaMR</dt><dd>Human and machine-readability</dd> <dt>IAaPW</dt><dd>Integrated authoring and publication workflow</dd> <dt>IC</dt><dd>Interactive content</dd> <dt>IM</dt><dd>Impact metrics</dd> <dt>IoS</dt><dd>Integration of semantics</dd> <dt>M</dt><dd>Multimedia</dd> <dt>PaA</dt><dd>Provenance and accountability</dd> <dt>PaP</dt><dd>Persistence and preservation</dd> <dt>SaSI</dt><dd>Sharing and social interactions</dd> </dl> </td> </tr> </tfoot> <tbody> <tr><th><a href="https://dokie.li/">dokieli</a> + <a href="https://github.com/solid">Solid</a></th> <td>✓</td><td>✓</td><td>✓</td><td></td><td>✓</td> <td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td> <td>✓</td><td>✓</td><td>✓</td><td></td><td>✓</td> <td>✓</td><td></td></tr> <tr><th><a href="http://myexperiment.org/">myExperiment</a></th> <td></td><td>✓</td><td>✓</td><td></td><td>✓</td> <td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td> <td>✓</td><td>✓</td><td></td><td></td><td></td> <td>✓</td><td></td></tr> <tr><th><a href="http://elifesciences.org/">eLife</a></th> <td></td><td>✓</td><td>✓</td><td></td><td>✓</td> <td>✓</td><td></td><td></td><td></td><td>✓</td> <td>✓</td><td>✓</td><td>✓</td><td></td><td>✓</td> <td>✓</td><td></td></tr> <tr><th><a href="https://osf.io/">OSF</a>^*</th> <td></td><td>✓</td><td>✓</td><td></td><td>✓</td> <td>✓</td><td></td><td></td><td></td><td>✓</td> <td>✓</td><td>✓</td><td></td><td></td><td>✓</td> <td>✓</td><td></td></tr> <tr><th><a href="https://drive.google.com/">Google Drive</a></th> <td></td><td>✓</td><td>✓</td><td></td><td>✓</td> <td>✓</td><td></td><td></td><td></td><td>✓</td> <td>✓</td><td>✓</td><td></td><td></td><td></td> <td>✓</td><td></td></tr> <tr><th><a href="http://rescience.github.io/">ReScience</a></th> <td></td><td>✓</td><td>✓</td><td></td><td>✓</td> <td>✓</td><td></td><td></td><td></td><td></td> <td>✓</td><td>✓</td><td></td><td></td><td>✓</td> <td>✓</td><td></td></tr> <tr><th><a href="https://www.authorea.com/">Authorea</a></th> <td></td><td>✓</td><td>✓</td><td></td><td>✓</td> <td>✓</td><td></td><td></td><td></td><td></td> <td>✓</td><td>✓</td><td></td><td></td><td></td> <td>✓</td><td></td></tr> <tr><th><a href="http://fiduswriter.org/">FidusWriter</a></th> <td>✓</td><td>✓</td><td>✓</td><td></td><td>✓</td> <td></td><td></td><td></td><td></td><td></td> <td>✓</td><td></td><td>✓</td><td></td><td></td> <td>✓</td><td></td></tr> <tr><th><a href="http://thinklab.com/">Thinklab</a></th> <td></td><td>✓</td><td>✓</td><td></td><td>✓</td> <td>✓</td><td></td><td></td><td></td><td></td> <td>✓</td><td>✓</td><td></td><td></td><td></td> <td></td><td></td></tr> </tbody> </table> </div> </section> <!-- <section id="situating-linked-research" inlist="" rel="schema:hasPart" resource="#situating-linked-research"> <h2 property="schema:name">Content to sort</h2> <div datatype="rdf:HTML" property="schema:description"> <p><mark>TODO: find these words a new home</mark></p> <p>Another form of scholarly output that is critical to the Linked Research vision is annotation. The recent announcement of the <a href="http://doi.org/10.1038/528153a">Annotating All Knowledge Coalition</a> is a major step towards a set of linked annotations that are openly available. The coalition is embracing <a href="https://www.w3.org/blog/2015/12/annotation-coalition-launched/">W3C open annotation standards</a> for interchanging standards.</p> <p>Other groups are focused on reforming the traditional structure and content of narrative papers into more technically accessible and reusable content. For example, <a href="http://rescience.github.io">The ReScience Journal</a> makes available the various portions of a paper on GitHub to be accessed and re-executed if possible. Likewise, the <a href="https://www.w3.org/community/scholarlyhtml/">W3C Scholarly HTML working group</a> is focused on the better support of scholarly documents on the web.</p> </div> </section> --> <section id="conclusions" inlist="" rel="schema:hasPart" resource="#conclusions"> <h2 about="#conclusions" property="schema:name" typeof="deo:Conclusion">Conclusions</h2> <div datatype="rdf:HTML" property="schema:description"> <p>In this article, we have described requirements for exploiting the possibilities of digitisation and the Web for scholarly communication. The vision of Linked Research comprises concepts which can be realised by meeting these requirements, and we propose technical solutions for doing so. We demonstrate the feasibility of these proposals with a prototype implementation that covers several of the Linked Research concepts, and compare this coverage with existing tooling. We used this prototype, dokieli, for drafting and publishing this article.</p> <p id="the-five-stars-of-online-journal-articles" rel="schema:hasPart" resource="#the-five-stars-of-online-journal-articles">Linked Research meets the criteria set forth in <cite><a href="http://www.dlib.org/dlib/january12/shotton/01shotton.html">The Five Stars of Online Journal Articles</a></cite> [<a class="ref" href="http://csarven.ca/linked-research-scholarly-communication#ref-33">33</a>] and we see this work as the first step on a larger research and development agenda. We envision an ecosystem of Linked Research compatible implementations and interfaces to existing systems (conference and journal management, editorial systems, open access repositories etc.). Ultimately, we hope that such developments will bring about a revolution in how scholarly knowledge is generated, published, shared and consumed.</p> </div> </section> <section id="acknowledgements" inlist="" rel="schema:hasPart" resource="#acknowledgements"> <h2 about="#acknowledgements" property="schema:name" typeof="deo:Acknowledgements">Acknowledgements</h2> <div property="schema:description" datatype="rdf:HTML"> <p>The motivation and work on Linked Research is inspired by <a href="https://en.wikipedia.org/wiki/Marshall_McLuhan">Marshall McLuhan</a>, <a href="https://en.wikipedia.org/wiki/Ted_Nelson">Theodor Holm Nelson</a>, <a href="https://en.wikipedia.org/wiki/James_Burke_%28science_historian%29">James Burke</a>, and <a href="https://en.wikipedia.org/wiki/Tim_Berners-Lee">Tim Berners-Lee</a>.</p> <p>Special thanks to many colleagues whom helped one way or another during the course of this work (not implying any endorsement); in no particular order: <a href="http://richard.cyganiak.de/">Richard Cyganiak</a>, <a href="http://id.myopenlink.net/dataspace/person/KingsleyUyiIdehen">Kingsley Idehen</a>, <a href="http://jodischneider.com/jodi.html">Jodi Schneider</a>, <a href="http://pgroth.com/">Paul Groth</a>, <a href="http://soiland-reyes.com/stian/work/">Stian Soiland-Reyes</a>, <a href="http://www.eurecom.fr/~troncy/">Raphaël Troncy</a>, <a href="http://aucegypt.edu/fac/anchaleepanigabutra-roberts">Anchalee Panigabutra-Roberts</a>, as well as colleagues at <span about="" id="funding-recipient" prefix="scoro: http://purl.org/spar/scoro/" rel="scoro:funding-recipient"><a about="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology" href="https://mit.edu/" property="schema:name" rel="schema:url" typeof="schema:Organization">MIT</a></span>/<a href="https://www.w3.org/">W3C</a>.</p> <p>This research was supported in part by <span about="" id="funder" prefix="scoro: http://purl.org/spar/scoro/" rel="scoro:funder"><a about="http://dbpedia.org/Qatar_Computing_Research_Institute" href="http://qcri.org.qa/" property="schema:name" rel="schema:url" typeof="schema:Organization">Qatar Computing Research Institute</a></span>, HBKU through the <a href="http://crosscloud.org/">Crosscloud</a> project.</p> </div> </section> <section id="references"> <h2>References</h2> <div> <ol> <li id="ref-1">Borgman, C.: Scholarship in the Digital Age: Information, Infrastructure, and the Internet, 2007, ISBN 9780262026192, <a href="https://mitpress.mit.edu/books/scholarship-digital-age" rel="schema:citation">https://mitpress.mit.edu/books/scholarship-digital-age</a></li> <li id="ref-2">Berners-Lee, T.: W3C 1998, Webizing existing systems, <a href="https://www.w3.org/DesignIssues/Webize.html" rel="schema:citation">https://www.w3.org/DesignIssues/Webize.html</a></li> <li id="ref-3">Procter, R., Williams, R., Steward, J., Poschen, M., Snee, H., Voss, A., Asgari-Targhi, M.: Adoption and use of Web 2.0 in scholarly communications. Philosophical Transactions of the Royal Society of London A: Mathematical, Physical and Engineering Sciences 2010(368):4039-4056, DOI: 10.1098/rsta.2010.0155, <a href="http://rsta.royalsocietypublishing.org/content/368/1926/4039" rel="schema:citation">http://rsta.royalsocietypublishing.org/content/368/1926/4039</a></li> <li id="ref-4">Licia, C., Cassella, M.: Scholarship 2.0: analyzing scholars’ use of Web 2.0 tools in research and teaching activity. Liber Quarterly 23.2 (2013): 110-133, <a href="https://www.liberquarterly.eu/articles/10.18352/lq.8108/" rel="schema:citation">https://www.liberquarterly.eu/articles/10.18352/lq.8108/</a></li> <li id="ref-5">Neylon, C., Wu, S: Open Science: tools, approaches, and implications. Pac Symp Biocomput. 2009:540-4, <a href="http://psb.stanford.edu/psb-online/proceedings/psb09/workshop-opensci.pdf" rel="schema:citation">http://psb.stanford.edu/psb-online/proceedings/psb09/workshop-opensci.pdf</a></li> <li id="ref-6">Piwowar, H. A., Day, R. S., Fridsma, D. B.: Sharing Detailed Research Data Is Associated with Increased Citation Rate, PLoS ONE, 2007, DOI: 10.1371/journal.pone.0000308, <a href="http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0000308" rel="schema:citation">http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0000308</a></li> <li id="ref-7">Suber, P., Brown, P. O., Cabell, D., Chakravarti, A., Cohen, B., Delamothe, T., Eisen, M., Grivell, L., Guédon, J-C., Hawley, R. S., Johnson, R. K., Kirschner, M. W., Lipman, D., Lutzker, A. P., Marincola, E., Roberts, R. J., Rubin, G. M., Schloegl, R., Siegel, V., So, A. D., Varmus, H. E., Velterop, J., Walport, M. J., Watson, L.: Bethesda Statement on Open Access Publishing, 2003, <a about="" href="https://dash.harvard.edu/bitstream/handle/1/4725199/suber_bethesda.htm" rel="schema:citation">https://dash.harvard.edu/bitstream/handle/1/4725199/suber_bethesda.htm</a></li> <li id="ref-8">Ensor, P.: The Functional Silo Syndrome, AME Target (1988):16, <a href="http://www.ame.org/sites/default/files/documents/88q1a3.pdf" rel="schema:citation">http://www.ame.org/sites/default/files/documents/88q1a3.pdf</a></li> <li id="ref-9">Berners-Lee, T.: Socially Aware Cloud Storage, W3C, 2009, <a href="https://www.w3.org/DesignIssues/CloudStorage.html">https://www.w3.org/DesignIssues/CloudStorage.html</a></li> <li id="ref-10">Bechhofer, S., Buchan, I., De Roure, D., Missier, P., Ainsworth, J., Bhagat, J., Couch, P., Cruickshank, D., Delderfield, M., Dunlop, I., Gamble, M., Michaelides, D., Owen, S., Newman, D., Sufi, S., Goble, C.: <a href="http://users.ox.ac.uk/~oerc0033/preprints/research-objects.pdf">Why linked data is not enough for scientists</a>. Future Gener. Comput. Syst. 29, 2 (2013), 599-611, <a about="" href="http://dx.doi.org/10.1016/j.future.2011.08.004" rel="schema:citation">http://dx.doi.org/10.1016/j.future.2011.08.004</a></li> <li id="ref-11">Klein M., Van de Sompel, H., Sanderson, R., Shankar, H., Balakireva, L., Zhou, K., Tobin, R.: Scholarly Context Not Found: One in Five Articles Suffers from Reference Rot, PLoS ONE, 2014, DOI: 10.1371/journal.pone.0115253, <a about="" rel="schema:citation" href="http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0115253">http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0115253</a></li> <li id="ref-12">Work, S., Haustein, S., Bowman, T. D., Larivière, V.: Social Media in Scholarly Communication, Canada Research Chair on the Transformations of Scholarly Communication, 2015, <a href="http://crctcs.openum.ca/files/sites/60/2015/12/SSHRC_SocialMediainScholarlyCommunication.pdf" rel="schema:citation">http://crctcs.openum.ca/files/sites/60/2015/12/SSHRC_SocialMediainScholarlyCommunication.pdf</a></li> <li id="ref-13">Kuhn, T. S.: The Structure of Scientific Revolutions, University of Chicago Press, 1962, ISBN 9780226458113</li> <li id="ref-14">Wagner, W., Steinzor, R.: Rescuing Science from Politics: Regulation and the Distortion of Scientific Research, Cambridge University Press, 2006 p. 224, ISBN 9780521855204</li> <li id="ref-15">Wicherts, J. M.: Peer Review Quality and Transparency of the Peer-Review Process in Open Access and Subscription Journals, 2016, DOI: 10.1371/journal.pone.0147913, <a href="http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0147913" rel="schema:citation">http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0147913</a></li> <li id="ref-16">Data Citation Synthesis Group: Joint Declaration of Data Citation Principles. Martone M. (ed.): FORCE11, <a href="https://www.force11.org/datacitation" rel="schema:citation">https://www.force11.org/datacitation</a></li> <li id="ref-17">Berners-Lee, T.: Universal Resource Identifiers -- Axioms of Web Architecture, W3C, 1996, <a about="" href="https://www.w3.org/DesignIssues/Axioms.html#Universality2" rel="schema:citation">https://www.w3.org/DesignIssues/Axioms.html#Universality2</a></li> <li id="ref-18">Jacobs, I., Walsh, N., W3C Technical Architecture Group: Architecture of the World Wide Web, Volume One, W3C, 2004, <a about="" href="https://www.w3.org/TR/webarch/#identification" rel="schema:citation">https://www.w3.org/TR/webarch/#identification</a></li> <li id="ref-19">Mons, B., Velterop, J.: Nano-Publication in the e-science era, Semantic Web Applications in Scientific Discourse, 2009, <a href="http://ceur-ws.org/Vol-523/Mons.pdf">http://ceur-ws.org/Vol-523/Mons.pdf</a></li> <li id="ref-20">de Waard, A., Buckingham Shum, S., Carusi, A., Park, J., Samwald, M. and Sándor, Á.: <a href="http://ceur-ws.org/Vol-523/deWaard.pdf">Hypotheses, Evidence and Relationships: The HypER Approach for Representing Scientific Knowledge Claims</a>, Semantic Web Applications in Scientific Discourse, 2009, <a about="" href="http://ceur-ws.org/Vol-523/" rel="schema:citation">http://ceur-ws.org/Vol-523/</a></li> <li id="ref-21">Capadisli, S., Auer, S., Riedl, R.: This ‘Paper’ is a Demo, ESWC Satellite Events (2015), <a href="http://csarven.ca/this-paper-is-a-demo" rel="schema:citation">http://csarven.ca/this-paper-is-a-demo</a></li> <li id="ref-22">Ahalt, S., Carsey, T., Couch, A., Hooper, R., Ibanez, L., Idaszak, R., Jones, M. B., Lin, J., Robinson, E.: NSF Workshop on <a href="http://www.nsf.gov/pubs/2014/nsf14059/nsf14059.jsp">Supporting Scientific Discovery Through Norms and Practices for Software and Data Citation and Attribution</a>. Technical Report. National Science Foundation, USA, 2015, <a href="http://dl.acm.org/citation.cfm?id=2795624" rel="schema:citation">http://dl.acm.org/citation.cfm?id=2795624</a></li> <li id="ref-23">Groth, P., Gurney, T.: <a href="http://journal.webscience.org/308/2/websci10_submission_48.pdf">Studying Scientific Discourse on the Web Using Bibliometrics: A Chemistry Blogging Case Study</a>, Proceedings of the WebSci10: Extending the Frontiers of Society On-Line, 2010, <a about="" href="http://journal.webscience.org/308" rel="schema:citation">http://journal.webscience.org/308</a></li> <li id="ref-24"><a href="http://www.oclc.org/research/publications/2015/oclcresearch-library-linked-data-in-the-cloud.html">Library Linked Data in the Cloud: OCLC’s Experiments with New Models of Resource Description</a>. Carol Jean Godby, Shenghui Wang, and Jeffrey K. Mixter Synthesis Lectures on the Semantic Web: Theory and Technology 2015 5:2, 1-154, <a href="http://www.worldcat.org/oclc/909811018" rel="schema:citation">http://www.worldcat.org/oclc/90981101</a></li> <li id="ref-25">Osborne, F., Scavo, G., Motta, E.: Identifying diachronic topic-based research communities by clustering shared research trajectories, Research Track, ESWC (2014), <a href="http://oro.open.ac.uk/39666/3/ESWC2014_CR" rel="schema:citation">http://oro.open.ac.uk/39666/3/ESWC2014_CR</a></li> <li id="ref-26">Berners-Lee, T.: Cool URIs don't change, W3C (1998), <a href="https://www.w3.org/Provider/Style/URI.html" rel="schema:citation">https://www.w3.org/Provider/Style/URI.html</a></li> <li id="ref-27">Rosenthal, D. S. H.: What Could Possibly Go Wrong? BIBLIOTHEK – Forschung und Praxis 2015; 39(2): 180–188, DOI 10.1515/bfp-2015-0022, <a href="http://www.lockss.org/locksswp/wp-content/uploads/2015/06/bfp-2015-0022-1.pdf" rel="schema:citation">http://www.lockss.org/locksswp/wp-content/uploads/2015/06/bfp-2015-0022-1.pdf</a></li> <li id="ref-28">Markman, C., Zavras, C.: BitTorrent and Libraries: Cooperative Data Publishing, Management and Discovery, Volume 20, Number 3/4, 2014, doi:10.1045/march2014-markman, <a href="http://www.dlib.org/dlib/march14/markman/03markman.html" rel="schema:citation">http://www.dlib.org/dlib/march14/markman/03markman.html</a></li> <li id="ref-29">Kuhn, T., Chichester, C., Krauthammer, M., Dumontier, M.: Publishing without Publishers: a Decentralized Approach to Dissemination, Retrieval, and Archiving of Data, ISWC 2015, <a href="http://iswc2015.semanticweb.org/sites/iswc2015.semanticweb.org/files/93660593.pdf" rel="schema:citation">http://iswc2015.semanticweb.org/sites/iswc2015.semanticweb.org/files/93660593.pdf</a></li> <li id="ref-30">Capadisli, S., Riedl, R., Auer, S.: Enabling Accessible Knowledge, CeDEM (2015), <a href="http://csarven.ca/enabling-accessible-knowledge" rel="schema:citation cito:citesAsSourceDocument">http://csarven.ca/enabling-accessible-knowledge</a></li> <li id="ref-31">Capadisli, S., Guy, A., Auer S., Berners-Lee, T.: dokieli: decentralised authoring, annotations and social notifications, 2016, <a href="http://csarven.ca/dokieli" rel="schema:citation">http://csarven.ca/dokieli</a></li> <li id="ref-32">Peroni, S: The Semantic Publishing and Referencing Ontologies. In Semantic Web Technologies and Legal Scholarly Publishing: 121-193. Cham, Switzerland: Springer. <a about="" href="http://dx.doi.org/10.1007/978-3-319-04777-5_5" rel="schema:citation">http://dx.doi.org/10.1007/978-3-319-04777-5_5</a></li> <li id="ref-33">Shotton, D.: The Five Stars of Online Journal Articles, D-Lib Magazine (2012), <a href="http://www.dlib.org/dlib/january12/shotton/01shotton.html" rel="schema:citation cito:citesAsSourceDocument">http://www.dlib.org/dlib/january12/shotton/01shotton.html</a></li> </ol> </div> </section> </div> http://csarven.ca/linked-research-scholarly-communication Sat, 19 Dec 2015 00:00:00 <h1 property="schema:name">dokieli: decentralised authoring, annotations and social notifications</h1> <p><mark>The information in this article while still accurate, the following article supersedes it: <cite><a href="http://csarven.ca/dokieli-rw w">Decentralised Authoring, Annotations and Notifications for a Read-Write Web with dokieli</a></cite>.</mark></p> <div id="authors"> <dl id="author-name"> <dt>Authors</dt> <dd id="author-1" inlist="" rel="bibo:authorList" resource="http://csarven.ca/#i"><span about="" rel="schema:creator schema:publisher schema:author"><a about="http://csarven.ca/#i" href="http://csarven.ca/" property="schema:name" rel="schema:url" typeof="schema:Person">Sarven Capadisli</a></span>^{<a about="http://csarven.ca/#i" href="http://csarven.ca/dokieli#author-org-1" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">1</a>}^{<a href="http://csarven.ca/dokieli#author-email-1">✊</a>}</dd> <dd id="author-2" inlist="" rel="bibo:authorList" resource="https://rhiaro.co.uk/#me"><span about="" rel="schema:author"><a about="https://rhiaro.co.uk/#me" href="https://rhiaro.co.uk/" property="schema:name" rel="schema:url" typeof="schema:Person">Amy Guy</a></span>^{<a about="https://rhiaro.co.uk/#me" href="http://csarven.ca/dokieli#author-org-2" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Edinburgh">2</a>}^{<a href="http://csarven.ca/dokieli#author-email-2">🐦</a>}</dd> <dd id="author-3" inlist="" rel="bibo:authorList" resource="http://eis.iai.uni-bonn.de/SoerenAuer"><span about="" rel="schema:author"><a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://eis.iai.uni-bonn.de/SoerenAuer.html" property="schema:name" rel="schema:url" typeof="schema:Person">Sören Auer</a></span>^{<a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://csarven.ca/dokieli#author-org-3" rel="schema:memberOf" resource="http://dbpedia.org/resource/University_of_Bonn">3</a>}^{<a href="http://csarven.ca/dokieli#author-email-3">⚛</a>}</dd> <dd id="author-4" inlist="" rel="bibo:authorList" resource="https://www.w3.org/People/Berners-Lee/card#i"><span about="" rel="schema:author"><a about="https://www.w3.org/People/Berners-Lee/card#i" href="https://www.w3.org/People/Berners-Lee/" property="schema:name" rel="schema:url" typeof="schema:Person">Tim Berners-Lee</a></span>^{<a about="https://www.w3.org/People/Berners-Lee/card#i" href="http://csarven.ca/dokieli#author-org-4" rel="schema:memberOf" resource="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology">4</a>}^{<a href="http://csarven.ca/dokieli#author-email-4">🕸</a>}</dd> </dl> <ul id="author-org"> <li id="author-org-1">¹Enterprise Information Systems Department, <a about="http://dbpedia.org/resource/University_of_Bonn" href="http://uni-bonn.de/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Bonn</a>, Bonn, Germany</li> <li id="author-org-2">²School of Informatics, <a about="http://dbpedia.org/resource/University_of_Edinburgh" href="http://www.ed.ac.uk/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Edinburgh</a>, Edinburgh, UK</li> <li id="author-org-3">³Enterprise Information Systems Department, <a about="http://dbpedia.org/resource/University_of_Bonn" href="http://uni-bonn.de/" property="schema:name" rel="schema:url" typeof="schema:Organization">University of Bonn</a>, Bonn, Germany</li> <li id="author-org-4">⁴Decentralized Information Group, CSAIL, <a about="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology" href="https://mit.edu/" property="schema:name" rel="schema:url" typeof="schema:Organization">MIT</a>, Cambridge, US</li> </ul> <ul id="author-email"> <li id="author-email-1">^✊<a about="http://csarven.ca/#i" href="http://csarven.camailto:info@csarven.ca" rel="schema:email">info@csarven.ca</a></li> <li id="author-email-2">^🐦<a about="https://rhiaro.co.uk/#me" href="http://csarven.camailto:amy@rhiaro.co.uk" rel="schema:email">amy@rhiaro.co.uk</a></li> <li id="author-email-3">^⚛<a about="http://eis.iai.uni-bonn.de/SoerenAuer" href="http://csarven.camailto:auer@cs.uni-bonn.de" rel="schema:email">auer@cs.uni-bonn.de</a></li> <li id="author-email-4">^🕸<a about="https://www.w3.org/People/Berners-Lee/card#i" href="http://csarven.camailto:timbl@w3.org" rel="schema:email">timbl@w3.org</a></li> </ul> </div> <dl id="document-identifier"> <dt>Identifier</dt> <dd><a href="http://csarven.ca/dokieli" rel="owl:sameAs">http://csarven.ca/dokieli</a></dd> </dl> <dl id="document-inbox"> <dt>Notifications Inbox</dt> <dd><a href="https://linkedresearch.org/inbox/csarven.ca/dokieli/" rel="ldp:inbox">inbox/</a></dd> </dl> <dl id="document-in-reply-to"> <dt>In Reply To</dt> <dd><a href="http://events.linkeddata.org/ldow2016/" rel="as:inReplyTo">LDOW2016 Call for Papers</a></dd> </dl> <dl id="document-published"> <dt>Published</dt> <dd><time content="2015-12-19T00:00:00Z" datatype="xsd:dateTime" datetime="2015-12-19T00:00:00Z" property="schema:datePublished">2015-12-19</time></dd> </dl> <dl id="document-modified"> <dt>Modified</dt> <dd><time content="2016-01-23T00:00:00Z" datatype="xsd:dateTime" datetime="2016-01-23T00:00:00Z" property="schema:dateModified">2016-01-23</time></dd> </dl> <dl id="document-license"> <dt>License</dt> <dd><a href="https://creativecommons.org/licenses/by/4.0/" rel="schema:license" title="Creative Commons Attribution 4.0 Unported">CC BY 4.0</a></dd> </dl> <div id="content"> <section id="abstract"> <h2>Abstract</h2> <div datatype="rdf:HTML" property="schema:abstract"> <p>In this article we present an architecture for progressively enhanced user-facing linked data applications and demonstrate this architecture through an open source example implementation: <em>dokieli</em>. dokieli is a general purpose client-side application for document authoring, publication and interaction. Capabilities of the tool are enabled according to the needs and technical resources of the user. The editor is built on open Web standards and the documents are compliant with Linked Data best practices, allowing: decentralised storage and data ownership; fine-grained semantic structure through HTML+RDFa; direct in-browser editing from an LDP-based personal data store; social interactions with documents (such as annotations and replies), and notifications thereof. This article itself is a dokieli instance, available to interact with at http://csarven.ca/dokieli.</p> </div> </section> <section id="keywords"> <h2>Keywords</h2> <div> <ul rel="schema:about"> <li><a href="https://en.wikipedia.org/wiki/Human-computer_interaction" resource="http://dbpedia.org/resource/Human-computer_interaction">Human-computer interaction</a></li> <li><a href="https://en.wikipedia.org/wiki/Knowledge_acquisition" resource="http://dbpedia.org/resource/Knowledge_acquisition">Knowledge acquisition</a></li> <li><a href="https://en.wikipedia.org/wiki/Linked_Data" resource="http://dbpedia.org/resource/Linked_Data">Linked Data</a></li> <li><a href="https://en.wikipedia.org/wiki/Semantic_publishing" resource="http://dbpedia.org/resource/Semantic_publishing">Semantic publishing</a></li> <li><a href="https://en.wikipedia.org/wiki/Social_web" resource="http://dbpedia.org/resource/Social_web">Social web</a></li> <li><a href="https://en.wikipedia.org/wiki/Web_science" resource="http://dbpedia.org/resource/Web_science">Web science</a></li> </ul> </div> </section> <section id="categories-and-subject-descriptors"> <h2>Categories and Subject Descriptors</h2> <div> <ul rel="schema:about"> <li><a href="http://www.acm.org/about/class/ccs98-html#H.1.2" resource="http://acm.rkbexplorer.com/ontologies/acm#H.1.2">H.1.2</a> [<strong>Information Systems</strong>]: Human information processing</li> <li><a href="http://www.acm.org/about/class/ccs98-html#H.4.m" resource="http://acm.rkbexplorer.com/ontologies/acm#H.4.m">H.4.m</a> [<strong>Information Systems Applications</strong>]: Linked Data</li> <li><a href="http://www.acm.org/about/class/ccs98-html#H.5.3" resource="http://acm.rkbexplorer.com/ontologies/acm#H.5.3">H.5.3</a> [<strong>Information Interfaces and Presentation</strong>]: Web-based interaction</li> <li><a href="http://www.acm.org/about/class/ccs98-html#I.7.4" resource="http://acm.rkbexplorer.com/ontologies/acm#I.7.4">I.7.4</a> [<strong>Document and Text Processing</strong>]: Electronic Publishing</li> </ul> </div> </section> <section id="introduction" inlist="" rel="schema:hasPart" resource="#introduction"> <h2 property="schema:name">Introduction</h2> <div datatype="rdf:HTML" property="schema:description" resource="#introduction" typeof="deo:Introduction"> <p id="totally-insane" rel="schema:hasPart" resource="#Ted-Nelson-Demonstrates-XanaduSpace"><q cite="https://www.youtube.com/watch?v=1yLNGUeHapA&amp;t=50s" datatype="rdf:HTML" resource="#Ted-Nelson-Demonstrates-XanaduSpace" property="schema:description" typeof="deo:Motivation">When I saw the computer, I said, ‘at last we can escape from the prison of paper’, and that was what my whole hypertext idea was about in 1960 and since. Contrarily, what did the other people do, they <strong>imitated paper</strong>, which to me seems totally insane</q> - <cite><a href="http://en.wikipedia.org/wiki/Ted_Nelson">Ted Nelson</a></cite> [<a class="ref" href="http://csarven.ca/dokieli#ref-1">1</a>].</p> <p>Our aim is to create and enhance opportunities for open knowledge exchange. Ideas and the conversations around them take the form of prose, which is widely published on the Web, and our hope is to iterate towards unleashing greater utility of this kind of content, whilst retaining its accessibility.</p> <p id="evolvability">A long-lasting system must be evolvable. It is difficult to predict which technologies will endure over time, however we take inspiration from the <cite><a about="" href="http://www.w3.org/DesignIssues/Evolution.html" rel="cito:agreesWith">Evolution of the Web</a></cite> [<a class="ref" href="http://csarven.ca/dokieli#ref-2">2</a>], and pursue features like simplicity, flexibility, decentralisation, interoperability, and tolerance.</p> <p>We have combined commonplace online publishing practices with contemporary Web standards to create a novel architecture for user-facing, progressively enhanced Linked Data applications. Progressive enhancement is a paradigm for Web application development that emerged circa 2003. A <a href="https://en.wikipedia.org/wiki/Progressive_enhancement">progressively enhanced</a> Web application focuses on the content, starting with semantic HTML markup, and gradually adding more advanced CSS and JavaScript features if the user’s browser permits. An experience may be immensely improved by these extra features, but they are not required in order to access the information on the page. At the time, this gave Web developers a mechanism to improve accessibility across devices and mitigate against constraints of outdated browsers. We are expanding on this concept from considering the users’ clients to also take into account users’ own servers or personal datastores if available.</p> <p>We believe this has the potential to both proliferate high quality machine-readable data, and enhance human-friendly knowledge sharing on the Web. Our baseline technology of HTML+RDFa fosters accessibility by default, and serves as a foundation on which we can build layers of functionality until we reach the interactive social experiences that people expect from the Web today. This architecture is decentralised, affording users greater control of their data, and optionally enhanced through use of the <cite><a href="https://github.com/solid/solid-spec">Solid</a></cite> platform (described further in <a href="http://csarven.ca/dokieli#data-storage">section 4.5</a>).</p> <p>We explore the feasibility of this architecture through an implementation, which serves as the focus of this article. dokieli is a client-side application for authoring, publishing and interaction with prose content. We discuss the problem space, existing standards and tools on which we have built, as well as specific implementation details of dokieli. Implementation is ongoing, and we conclude with lessons learnt so far and a discussion of the problems which remain to be solved.</p> </div> </section> <section id="problem-space" inlist="" rel="schema:hasPart" resource="#problem-space"> <h2 property="schema:name">Problem space</h2> <div about="#problem-space" datatype="rdf:HTML" property="schema:description" typeof="deo:ProblemStatement"> <p id="scenario" rel="schema:hasPart"><span about="#scenario" property="schema:description" typeof="deo:Scenario">Our scope covers three primary areas: authoring and publication, annotation and social notifications, and multimodal semantic content and interactivity. We take a brief look at use cases from some existing, overlapping, work in these areas.</span></p> <p>The W3C <a href="https://www.w3.org/Social/WG">Social Web Working Group</a> presents <a href="https://www.w3.org/wiki/Socialwg/Social_API/User_stories">user stories</a> for various common online social activities. Noting that all of these user stories are expected to work in a decentralised manner (with all participants using different technology stacks), we consider the use cases which involve creating and updating content which is intended to be shared with others; interacting with existing content; and content creators being notified when someone interacts with their content.</p> <p>The W3C <a href="https://www.w3.org/annotation/">Web Annotation Working Group</a> and <a href="https://www.w3.org/dpub/IG/wiki/Main_Page">Digital Publishing Interest Group</a> put forward a set of <a href="https://www.w3.org/annotation/wiki/Use_Cases">use cases</a> for annotation activities. One intuitive use case for annotation is <a href="https://www.w3.org/TR/dpub-annotation-uc/#commenting-on-a-span-of-text">commenting on a span of text</a> (a reviewer annotates a sentence by suggesting that it needs citation).</p> <p>The <cite><a href="http://csarven.ca/call-for-linked-research">Linked Research</a></cite> initiative [<a class="ref" href="http://csarven.ca/dokieli#ref-3">3</a>] takes a critical look at the current level of access to academic work, putting out a call for better presentation, discoverability and reuse of research objects. We keep in mind the proposed <a href="http://csarven.ca/enabling-accessible-knowledge#acid-test">acid test</a> [<a class="ref" href="http://csarven.ca/dokieli#ref-4">4</a>] to verify the openness, accessibility, and flexibility of approaches to scholarly communication. This is intended to improve opportunities for knowledge acquisition and education through: fine-grained identification of arguments and concepts; linking for concept reuse and building information networks; embedding of machine-readable semantics for fast aggregation and remixing of work; interactive and executable interfaces for improved learnability.</p> <p>These areas of interest cover anywhere from data-driven journalism, online news, scholarly articles and peer-reviews, to casual communication through blogging and social media, but the theme of widening participation through spreading of knowledge and ideas in accessible ways is central to our motivation.</p> <p>We summarise these areas with a list of requirements that implementations of our architecture should meet.</p> <dl id="requirements" rel="schema:hasPart" resource="#requirements"> <dt property="schema:name">Requirements</dt> <dd datatype="rdf:HTML" property="schema:description"> <ul> <li>Publication and sharing of knowledge and ideas is encouraged with <em>user friendly</em> content creation interfaces.</li> <li>Discussion and commentary is promoted through integration of tools for <em>social interaction</em> and <em>notification</em>.</li> <li>Data is stored in a <em>decentralised</em> way, in a location that the creator controls.</li> <li>Data is <em>loosely coupled</em> with the applications used to create and view it, and machine-readable, so that it is <em>reusable</em> by other applications.</li> <li>Applications and data formats are <em>progressively enhanced</em> such that content is minimally accessible to users with different capabilities and technical resources.</li> </ul> </dd> </dl> </div> </section> <section id="related-work" inlist="" rel="schema:hasPart" resource="#related-work"> <h2 property="schema:name">Related Work</h2> <div datatype="rdf:HTML" property="schema:description"> <p>There exists a variety of tooling for semantic content authoring, personal data storage and sharing, distribution of social notifications, and integration and linking of ideas and concepts. Here we discuss a non-exhaustive selection in an attempt to succinctly give an overview of the current landscape.</p> <p id="googledocs-medium-authorea"><a href="https://docs.google.com/">Google Docs</a>, <a href="https://medium.com/">Medium</a>, and <a href="https://www.authorea.com/">Authorea</a> are Web applications for collaborative creation and publication of content which require account creation and data storage with centralised services. They allow multiple participants to annotate and hold discussions around the primary content; users must access their centralised accounts to be notified of updates to conversations, and data from both the main content and related discussion is confined to the service which was used to create it.</p> <p id="hypothesis-genius"><a href="https://hypothes.is/">Hypothesis</a> and <a href="https://genius.com/">Genius</a> make it possible for users to leave annotations on different types of documents on the Web using a browser plugin or via a proxy. Annotations may be private or public, and can be threaded to form conversations around a piece of content. Despite allowing the attachment of annotations to resources hosted anywhere, they depend on centralised account creation and storage for the annotations themselves. Hypothesis is open source, with an API that uses the data model currently undergoing standardisation in the W3C Annotations Working Group, and may be self-hosted, but currently it is not possible to federate between different Hypothesis instances.</p> <p id="semantic-authoring-of-textual-content">There have been many tools for semantic authoring of textual content [<a class="ref" href="http://csarven.ca/dokieli#ref-5">5</a>]; here, we note four.</p> <p id="loomp-rdface">Loomp [<a class="ref" href="http://csarven.ca/dokieli#ref-6">6</a>] and <a href="http://ali1k.com/rdface">RDFaCE</a> [<a class="ref" href="http://csarven.ca/dokieli#ref-7">7</a>] are semantic content authoring tools which respectively follow a <em>top-down</em> and <em>bottom-up</em> approach with HTML+RDFa. Loomp allows annotating terms with concepts from Linked Data ontologies, and creating relationships between annotated phrases. Loomp can be self-hosted, and uses a server-side triplestore. RDFaCE is a Web-based RDFa content editor based on the TinyMCE rich text editor. It supports different views for semantic content authoring and uses existing Semantic Web APIs to facilitate annotating and editing of RDFa content. RDFaCE uses on-the-fly client-side triple storage.</p> <p id="wordpress-wordlift">WordPress is a free and open-source platform for article publication which can be self-hosted on a server controlled by the user. <a href="http://wordlift.it/">WordLift</a> [<a class="ref" href="http://csarven.ca/dokieli#ref-8">8</a>] is a WordPress plugin for semantic editing which uses an API to enhance articles with machine-readable JSON-LD data, improving the reusability of content published this way.</p> <p id="the-callimachus-project"><a href="http://www.callimachusproject.org/">The Callimachus Project</a> [<a class="ref" href="http://csarven.ca/dokieli#ref-9">9</a>] is a self-hosted server which provides a generic framework for setting up sites specifically to publish Linked Data. It employs a XHTML+RDFa template engine to generate Web pages by combining the template with SPARQL query results from an RDF database, facilitating human- and machine-friendly views of the content.</p> <p id="graphity"><a href="http://graphity.org/">Graphity</a> [<a class="ref" href="http://csarven.ca/dokieli#ref-10">10</a>] Processor can serve XHTML+RDFa documents by matching HTTP requests against a declarative sitemap. Query results are loaded from a SPARQL service and rendered as user interface by the Client. The Platform adds multi-tenant capabilities by providing user accounts and access control.</p> <p>The tools which provide good collaborative editing UIs appear to do so at the expense of data ownership and interoperability; those which promote creation and publication of data in open reusable formats are lacking facilities for linking discourse and conversation to concepts published. What follows is a proposed architecture for bridging this gap which has a low setup cost.</p> </div> </section> <section id="architecture" inlist="" rel="schema:hasPart" resource="#architecture"> <h2 property="schema:name">Architecture</h2> <div datatype="rdf:HTML" property="schema:description"> <p>Articles are written to share knowledge. The architecture we have chosen enables this knowledge to be as widely accessible as possible; the capabilities of dokieli are designed such that they are enabled progressively and individually, according to the user’s needs and technical resources at the time. The most minimal tooling required to read content produced with dokieli is a command-line interface or Line Mode Browser. Given a modern Web browser, Linked Data tooling, or an LDP-compatible server, documents and data can be consumed, created, connected and manipulated in more powerful and visually appealing ways.</p> <p>In this section we describe the existing standards and protocols which provide the building blocks for our architecture, and how these pieces fit together to make this approach possible.</p> <section id="data-format" inlist="" rel="schema:hasPart" resource="#data-format"> <h3 property="schema:name">Data format</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="native-html-rdfa">The native serialisation for dokieli documents is HTML+RDFa. HTML enables human-readable articles by default; RDFa, which is particularly well suited to the longform content dokieli is used to create, augments the documents with a machine-readable structure. We consider content of a document to be of foremost importance, and RDFa allows authors to add semantic structure to their ideas inline. Alternative syntaxes such as Turtle, JSON-LD, and TriG may be embedded into HTML as raw data islands, though this causes unnecessary separation, and potential duplication and desynchronisation of data. dokieli uses these to compliment the prose but does not rely on them.</p> <p id="the-rule-of-least-power">This approach also satisfies <cite><a about="" href="http://www.w3.org/2001/tag/doc/leastPower.html" rel="cito:agreesWith">The Rule of Least Power</a></cite>, proposed by the <a href="https://www.w3.org/2001/tag/">W3C Technical Architecture Group</a>: <q cite="http://www.w3.org/2001/tag/doc/leastPower.html">when publishing on the Web, you should usually choose the least powerful or most easily analyzed language variant that’s suitable for the purpose.</q> This allows easy reuse of the content in ways previously unimagined by its original creators [<a class="ref" href="http://csarven.ca/dokieli#ref-11">11</a>, <a class="ref" href="http://csarven.ca/dokieli#ref-12">12</a>].</p> </div> </section> <section id="identifiers" inlist="" rel="schema:hasPart" resource="#identifiers"> <h3 property="schema:name">Identifiers</h3> <div datatype="rdf:HTML" property="schema:description"> <p>As dokieli documents are published on the Web, they have their own URI. This can be used to refer unambiguously to the document for example in a list of publications by the author, or in indicating the subject of a reply. Further, any individual word, phrase, paragraph, or other subsection of a document can have its own unique identifier using a fragment URI. This enables responses to be targeted very specifically at parts of a document; when additional semantics are applied to relationships, we have the power to create links that say things like ‘I like this concept’, ‘this sentence should be clarified’, ‘this result disagrees with those conclusions’. Within dokieli documents, links can be created to external concepts in the Linked Open Data cloud, aggregating related topics and creating unambiguous references. The dokieli UI provides anchors for all fragments in the margins of a document.</p> </div> </section> <section id="vocabularies" inlist="" rel="schema:hasPart" resource="#vocabularies"> <h3 property="schema:name">Vocabularies</h3> <div datatype="rdf:HTML" property="schema:description"> <p>dokieli does not mandate the use of any particular RDF vocabularies as the content of an article dictates how it is best described. By default, dokieli documents make use of the following; these are replaced or more added at the discretion of the author.</p> <ul> <li>General-purpose: <a href="https://schema.org/">schema.org</a></li> <li>Publishing and referencing: <a href="http://purl.org/spar">SPAR Ontologies</a></li> <li>Annotations: <a href="http://www.w3.org/ns/oa">Web Annotations</a></li> <li>Social notifications: <a href="http://www.w3.org/ns/activitystreams">ActivityStreams</a> and <a href="http://purl.org/net/pingback/">Pingback</a></li> <li>Links to personal storage and user preferences: <a href="http://www.w3.org/ns/ldp">LDP</a> and <a href="https://github.com/solid/vocab">Solid</a></li> <li>Access control: <a href="https://www.w3.org/wiki/WebAccessControl">WebAccessControl</a>/<a href="http://www.w3.org/ns/auth/acl">ACL</a></li> </ul> </div> </section> <section id="distribution" inlist="" rel="schema:hasPart" resource="#distribution"> <h3 property="schema:name">Distribution</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="default-ui">dokieli application logic, written in JavaScript, is distributed along with every document, ensuring all documents can be edited and interacted with. We consider this a default UI of a document, rather than the required one however, as the data can still be extracted and used in other contexts by other RDF-aware applications.</p> <p id="fault-tolerant">The progressive nature of dokieli documents is fault-tolerant. If the application scripts or stylesheets are not available, the content is still accessible, allowing continuous utility, albeit in a read-only mode, rather than failing completely. A single document in HTML+RDFa is able to retain all of its core content and semantics without external dependencies.</p> <p id="self-replicating">dokieli is <em>self-replicating</em>, in that the reader of a dokieli document can spawn an instance — either a copy or a brand new empty document — into their own storage space at the click of a button. There is no installation or setup process required to publish content.</p> </div> </section> <section id="data-storage" inlist="" rel="schema:hasPart" resource="#data-storage"> <h3 property="schema:name">Data storage</h3> <div datatype="rdf:HTML" property="schema:description"> <p>The owner of a dokieli document has full control and a great deal of flexibility over where to store their article. There are no centralised silos or gatekeepers. However, the capabilities of the system in which a document is stored has an effect on the features which are enabled. At the simplest level, documents can be served from the local filesystem for individual use. To publish documents more widely, they can be hosted on an ordinary Web server, and disseminated with a URL.</p> <p id="solid">dokieli is compliant with <cite><a href="https://github.com/solid/solid-spec">Solid</a></cite>, a set of protocols and conventions based on the W3C <a href="http://www.w3.org/TR/ldp/">Linked Data Platform</a> (LDP) recommendation. This incorporates authentication, access control and read and write access to a personal datastore. Hosting a dokieli document on a Solid server allows the author to edit the document directly from a space they control, and grant permissions to collaborators to do so as well. There are a number of open source Solid server implementations already, and users may host their own or choose a provider. There also exist <a href="https://github.com/solid/solid-platform">Solid tools and libraries</a> to help developers to build their own Solid-compliant datastore.</p> <p>An article is the subject of feedback and social interactions such as annotations and reviews. A Solid server can additionally be employed to host these interactions, either in a space owned by the author of the article, or in a more decentralised manner, by allowing a commenter to save their message in their own space. In the latter case, the author is able to configure an <em>inbox</em> on their own Solid server through the dokieli UI, to which notifications of new third-party interactions are sent. These interactions are then displayed alongside the original document, even if the document itself is hosted on a non-Solid Web server, and the article serves as a centrepiece for conversation with as many participants as are inclined to join.</p> </div> </section> <section id="modes-of-operation" inlist="" rel="schema:hasPart" resource="#modes-of-operation"> <h3 property="schema:name">Modes of operation</h3> <div datatype="rdf:HTML" property="schema:description"> <p>The core capabilities of dokieli are enabled on a per-document basis, according to the technical resources available for that document. Different combinations of available resources give rise to different <em>modes</em> in which dokieli can operate.</p> <section id="publishing" inlist="" rel="schema:hasPart" resource="#publishing"> <h4 property="schema:name">Publishing</h4> <div datatype="rdf:HTML" property="schema:description"> <p><strong>Read only</strong>: A dokieli instance may be hosted on anything that can serve HTML, including the local filesystem. Content is available without CSS and JavaScript (<a href="http://csarven.ca/dokieli#figure-mode-read-only">figure 1</a>). With CSS but without JavaScript, different views are available for consuming media types and devices.</p> <figure id="figure-mode-read-only" rel="schema:hasPart" resource="#figure-mode-read-only"> <img rel="schema:image" src="http://csarven.camedia/images/articles/mode-read-only.svg" /> <figcaption property="schema:name">Read only.</figcaption> </figure> <p><strong>Temporary edit</strong>: Hosted on anything that can serve HTML, including the local filesystem. With JavaScript enabled, content may be edited through a web browser and exported to save changes (<a href="http://csarven.ca/dokieli#figure-mode-edit-temporary">figure 2</a>).</p> <figure id="figure-mode-edit-temporary" rel="schema:hasPart" resource="#figure-mode-edit-temporary"> <img rel="schema:image" src="http://csarven.camedia/images/articles/mode-edit-temporary.svg" /> <figcaption property="schema:name">Temporary edit with export to save.</figcaption> </figure> <p><strong>Local persistent edit</strong>: Hosted on anything that can serve HTML, including the local filesystem. Content may be edited through an in-browser JavaScript editor and in-browser Web Storage enabled to persist changes for a longer period (<a href="http://csarven.ca/dokieli#figure-mode-edit-local">figure 3</a>).</p> <figure id="figure-mode-edit-local" rel="schema:hasPart" resource="#figure-mode-edit-local"> <img rel="schema:image" src="http://csarven.camedia/images/articles/mode-edit-local.svg" /> <figcaption property="schema:name">Persistent edit using Web Storage.</figcaption> </figure> <p><strong>Persistent edit</strong>: Hosted on a Solid server, edited through a web browser, with changes saved directly to the server (<a href="http://csarven.ca/dokieli#figure-mode-edit-solid">figure 4</a>).</p> <figure id="figure-mode-edit-solid" rel="schema:hasPart" resource="#figure-mode-edit-solid"> <img rel="schema:image" src="http://csarven.camedia/images/articles/mode-edit-solid.svg" /> <figcaption property="schema:name">Persistent edit on a Solid server, with optional authentication.</figcaption> </figure> <p><strong>Data only</strong>: Hosted on anything that can serve HTML, content and metadata can be extracted using an RDFa parser and processed, remixed or re-displayed (<a href="http://csarven.ca/dokieli#figure-mode-data-only">figure 5</a>).</p> <figure id="figure-mode-data-only" rel="schema:hasPart" resource="#figure-mode-data-only"> <img rel="schema:image" src="http://csarven.camedia/images/articles/mode-data-only.svg" /> <figcaption property="schema:name">Data only</figcaption> </figure> </div> </section> <section id="interacting" inlist="" rel="schema:hasPart" resource="#interacting"> <h4 property="schema:name">Interacting</h4> <div datatype="rdf:HTML" property="schema:description"> <p><strong>Centralised interactions:</strong> A dokieli instance is hosted on a Solid server, with a pointer to a space to store interactions (such as replies, annotations, likes) made by third-parties through the in-browser JavaScript editor (<a href="http://csarven.ca/dokieli#figure-mode-interaction-centralised">figure 6</a>).</p> <figure id="figure-mode-interaction-centralised" rel="schema:hasPart" resource="#figure-mode-interaction-centralised"> <img rel="schema:image" src="http://csarven.camedia/images/articles/mode-interaction-centralised.svg" /> <figcaption property="schema:name">Centralised interactions</figcaption> </figure> <p><strong>Decentralised interactions</strong>: Hosted on a Solid server, with an inbox to receive notifications so third-parties can store their interactions in their own dataspace (<a href="http://csarven.ca/dokieli#figure-mode-interaction-decentralised">figure 7</a>).</p> <figure id="figure-mode-interaction-decentralised" rel="schema:hasPart" resource="#figure-mode-interaction-decentralised"> <img rel="schema:image" src="http://csarven.camedia/images/articles/mode-interaction-decentralised.svg" /> <figcaption property="schema:name">Decentralised interactions</figcaption> </figure> <p><strong>Decoupled interactions</strong>: Hosted on anything that can serve HTML, with link to a notifications inbox on a Solid server, and third-parties can store their interactions in their own dataspace (<a href="http://csarven.ca/dokieli#figure-mode-interaction-decoupled">figure 8</a>).</p> <figure id="figure-mode-interaction-decoupled" rel="schema:hasPart" resource="#figure-mode-interaction-decoupled"> <img rel="schema:image" src="http://csarven.camedia/images/articles/mode-interaction-decoupled.svg" /> <figcaption property="schema:name">Decoupled interactions</figcaption> </figure> </div> </section> </div> </section> </div> </section> <section id="implementation" inlist="" rel="schema:hasPart" resource="#implementation"> <h2 property="schema:name">Implementation</h2> <div about="#implementation" datatype="rdf:HTML" property="schema:description" typeof="deo:Results"> <p><a href="https://github.com/linkeddata/dokieli">dokieli</a> is open source and available to try at <code><a href="https://dokie.li/">https://dokie.li/</a></code> (or at any instance on the Web). In this section we describe specific features which meet the uses cases outlined previously.</p> <section id="semantics" inlist="" rel="schema:hasPart" resource="#features"> <h3 property="schema:name">Semantics and linking</h3> <div datatype="rdf:HTML" property="schema:description"> <p>The data format of dokieli documents is designed to encourage machine-readable description of ideas and knowledge, which becomes particularly powerful when these individual ideas can be linked to each other with semantically meaningful relationships. A document author can assign a URI to concepts at any level, permitting reference to the document as a whole, a single phrase, or anything in between. Concepts within a single document can be related to each other with the appropriate RDF properties, as well as creating specific relations with external resources. dokieli takes a bottom-up approach to semantic content authoring; <a href="http://csarven.ca/dokieli#figure-dokieli-rdfa">figure 9</a> shows our user interface for this, whereby the author selects some text, chooses the subject, predicate and object of a statement, and the application inserts the data as RDFa, and if necessary generates a new URI fragment for the subject or object.</p> <p>In addition, metadata that does not easily fit into prose (for example, <a href="http://nanopub.org/">Nanopublications</a>) can be embedded as a single block of Turtle, JSON-LD, or TriG (<a href="http://csarven.ca/dokieli#figure-dokieli-nanopublication">figure 10</a>).</p> <p><a href="http://csarven.ca/dokieli#figure-dokieli-article-fragment">Figure 11</a> shows a sample of internal and external concepts and relationships from a dokieli document.</p> <figure id="figure-dokieli-rdfa" rel="schema:hasPart" resource="#figure-dokieli-rdfa"> <img rel="schema:image" src="http://csarven.camedia/images/articles/dokieli-rdfa.png" /> <figcaption property="schema:name">RDFa embedding.</figcaption> </figure> <figure id="figure-dokieli-nanopublication" rel="schema:hasPart" resource="#figure-dokieli-nanopublication"> <img rel="schema:image" src="http://csarven.camedia/images/articles/dokieli-nanopublication.png" /> <figcaption property="schema:name">Embedding a Nanopublication.</figcaption> </figure> <figure id="figure-dokieli-article-fragment" rel="schema:hasPart" resource="#figure-dokieli-article-fragment"> <img rel="schema:image" src="http://csarven.camedia/images/articles/dokieli-article-fragment.svg" /> <figcaption property="schema:name">A visualisation of a sample of RDF from a dokieli article.</figcaption> </figure> <!--<p><mark>Maybe an example of embedding datacube into a table of results would be good here too</mark></p>--> </div> </section> <section id="rich-editing" inlist="" rel="schema:hasPart" resource="#rich-editing"> <h3 property="schema:name">Rich editing</h3> <div datatype="rdf:HTML" property="schema:description"> <p id="editor">The current implementation of dokieli makes use of the open source <a href="https://github.com/yabwe/medium-editor">Medium Editor</a> for the features one would expect from a WYSIWYG editor (<a href="http://csarven.ca/dokieli#figure-dokieli-edit-menu">figure 12</a>). We have extended this with buttons for RDFa embedding, annotations and other interactions. The edit menu itself is loosely coupled with the rest of the application logic, so the choice of edit menu can be changed in future if better libraries become available.</p> <p id="auto-numbering">Tables of contents, tables, and figures are automatically calculated from the document contents and displayed as in <a href="http://csarven.ca/dokieli#figure-dokieli-toc">figure 13</a>. The user can also drag and drop here to conveniently re-order sections of the document. Similarly links within a document are automatically compiled into an academic reference list if required by the author.</p> <p id="stylesheets">dokieli comes with a number of stylesheets built in, and an author with CSS knowledge can create a new one of their own, or reuse existing styles from elsewhere. It is trivial for the user (whether author or reader of a document) to switch between available views to their preferred one, either through user-agent’s built-in feature or through dokieli’s menu (<a href="http://csarven.ca/dokieli#figure-dokieli-views">figure 14</a>).</p> <script>//<![CDATA[ var actionViews = '<span id="action-views" class="do">These buttons can also trigger the views in this article: <\/span>'; var context = document.getElementById('stylesheets'); context.insertAdjacentHTML('afterend', actionViews); var aV = document.getElementById('action-views'); DO.U.showViews(aV); var h2 = aV.querySelector('h2'); h2.parentNode.removeChild(h2); //]]></script> <style>/*<![CDATA[*/ @media screen { #action-views.do { margin-bottom:1em; } #action-views.do:after { content:'.'; } #action-views.do * { display:inline !important; } #action-views.do #document-views { margin-top:0; } #action-views.do #document-views:before { content:''; } #action-views.do li { margin-right:0; } #action-views.do li:before { content:', '; } #action-views.do li:first-child:before { content:''; } } /*]]>*/</style> <figure id="figure-dokieli-edit-menu" rel="schema:hasPart" resource="#figure-dokieli-rdfa"> <img rel="schema:image" src="http://csarven.camedia/images/articles/dokieli-edit-menu.png" /> <figcaption property="schema:name">The edit menu.</figcaption> </figure> <figure id="figure-dokieli-toc" rel="schema:hasPart" resource="#figure-dokieli-toc"> <img rel="schema:image" src="http://csarven.camedia/images/articles/dokieli-toc.png" /> <figcaption property="schema:name">Table of contents.</figcaption> </figure> <figure id="figure-dokieli-views" rel="schema:hasPart" resource="#figure-dokieli-views"> <img rel="schema:image" src="http://csarven.camedia/images/articles/dokieli-views.png" /> <figcaption property="schema:name">Options for different views. These buttons activate a stylesheet switcher.</figcaption> </figure> </div> </section> <section id="authentication-and-access-control" inlist="" rel="schema:hasPart" resource="#authentication-and-access-control"> <h3 property="schema:name">Authentication and access control</h3> <div datatype="rdf:HTML" property="schema:description"> <p>People can identify themselves to a dokieli document through <a href="https://www.w3.org/2005/Incubator/webid/spec/tls/">WebID-TLS</a>. Users with a browser certificate installed and a matching FOAF profile containing the certificate public key are authenticated against their own Solid server if found, with a fallback to a known Solid authentication endpoint. This allows the dokieli instance to write to any Solid-compliant dataspace which the user is authorised to write to. This is how users can, for example, save changes to a document, or store interactions such as comments. While dokieli does not currently offer a UI for granting access to collaborators on a document, authors can use other <a href="https://github.com/solid/solid-apps">Solid applications</a> (e.g., <a href="https://github.com/linkeddata/warp">warp</a>) to manage permissions of data on their server, and thus allow other specific individuals (or the general public) to edit their articles.</p> <p>dokieli also displays an authenticated user’s name and display picture if available in their profile. In future, we plan to take into account any preferences in a user’s profile, as well as other documents they have previously published, to enhance and personalise the UI.</p> </div> </section> <section id="storage" inlist="" rel="schema:hasPart" resource="#storage"> <h3 property="schema:name">Storage</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Articles may be stored on user’s local filesystem or hosted from ordinary Web servers which can serve static HTML files, for example: university user pages, code repositories, personal or company webspace, or any file hosting.</p> <p>Articles can be edited in a Web browser, and then exported (<a href="http://csarven.ca/dokieli#figure-dokieli-do">figure 15</a>) to save changes. dokieli also makes use of <a href="https://www.w3.org/TR/webstorage/">Web Storage</a> in browsers with this capability, which can be enabled or disabled by the user.</p> <p>A document stored on a Solid server is readable as a normal HTML page, and additionally editable directly on the server for authorised users (<a href="http://csarven.ca/dokieli#figure-dokieli-do">figure 15</a>). The <em>new</em> and <em>save as</em> buttons (<a href="http://csarven.ca/dokieli#figure-dokieli-do">figure 15</a>) prompt the user to choose a storage location before generating a blank new document or a copy of the current document respectively. If a user is already authenticated and their profile indicates where to find their a personal dataspace, dokieli presents a dataspace browser, through which the user can click to choose where to save (<a href="http://csarven.ca/dokieli#figure-dokieli-browser">figure 16</a>). Non-authenticated users may simply type the URL of a storage location they believe they can access, browse the directories therein, and save if the location is publicly writeable. According to the Solid protocol, dokieli uses an <code>HTTP POST</code> or <code>PUT</code> to replicate the HTML+RDFa that constitutes an instance, into the chosen dataspace. The user has the option to copy media and scripts to their own space as well, link to them from a <abbr title="Content Delivery Network">CDN</abbr> or link to them from the document they are starting from.</p> <figure id="figure-dokieli-do" rel="schema:hasPart" resource="#figure-dokieli-do"> <img rel="schema:image" src="http://csarven.camedia/images/articles/dokieli-do.png" /> <figcaption property="schema:name">The ‘Do’ menu, containing Edit, New, Save, Save As, Export and Print.</figcaption> </figure> <figure id="figure-dokieli-browser" rel="schema:hasPart" resource="#figure-dokieli-browser"> <img rel="schema:image" src="http://csarven.camedia/images/articles/dokieli-browser.png" /> <figcaption property="schema:name">The resource browser for Save As, showing the contents of a public space on a Solid server, and various options for saving of embedded resources.</figcaption> </figure> </div> </section> <section id="interactions" inlist="" rel="schema:hasPart" resource="#interactions"> <h3 property="schema:name">Interactions</h3> <div datatype="rdf:HTML" property="schema:description"> <p>We support the rights of authors to own their data, and store and publish it where they feel most comfortable. This includes the social interactions users make around existing publications. Rather than centralising these interactions around the subject document, we took the decision to default to decentralisation of all content by allowing users to authenticate with their personal dataspace, and choose the location for their interactions at the point of making them. This gives rise to the need for a mechanism to notify the original author that their document has received some interaction. We do this by allowing document authors to specify an <em>inbox</em> for either their article as a whole, or any subsection with its own URI using the <code>ldp:inbox</code> predicate. Inboxes are containers in a dataspace which may be appended to by anyone, and do not need to be on the same server as the document itself; if one article has multiple inboxes they can be distributed across as many dataspaces as is convenient for the author(s). When an annotation is made, dokieli follows the appropriate <code>inbox</code> link and writes a notification there (see <a href="http://csarven.ca/dokieli#figure-interactions-create">figure 17</a> for this process and <a href="http://csarven.ca/dokieli#solid-notification">listing 1</a> for notification contents). When the document is loaded, links are followed to all inboxes in order to retrieve interactions there have been notifications about, so that these can be displayed along with the document (<a href="http://csarven.ca/dokieli#figure-interactions-display">figure 18</a> and <a href="http://csarven.ca/dokieli#figure-dokieli-interactions">figure 19</a>).</p> <p id="dokieli-notifications">Although providing enriched (meta)data is voluntary, provenance level data like the date on which the request was submitted, who by, and its license, can be purposed towards the verification process as well as for displaying. An example inbox notification is shown in Listing [<a href="http://csarven.ca/dokieli#solid-notification">1</a>], in which <strong class="highlight-object">object</strong> is the URL of an annotation, and the <strong class="highlight-target">target</strong> (the conclusions section of an article).</p> <figure id="figure-interactions-create" rel="schema:hasPart" resource="#figure-interactions-create"> <object data="http://csarven.camedia/images/articles/interactions-create.svg" height="504" rel="schema:image" width="480"></object> <figcaption property="schema:name">What happens when a user creates an interaction on an article.</figcaption> </figure> <figure id="figure-interactions-display" rel="schema:hasPart" resource="#figure-interactions-display"> <object data="http://csarven.camedia/images/articles/interactions-display.svg" height="393" rel="schema:image" type="image/svg+xml" width="480"></object> <figcaption property="schema:name">How interactions are displayed on an article.</figcaption> </figure> <figure id="figure-dokieli-interactions" rel="schema:hasPart" resource="#figure-dokieli-interactions"> <img rel="schema:image" src="http://csarven.camedia/images/articles/dokieli-interactions.png" /> <figcaption property="schema:name">Interactions on a document.</figcaption> </figure> <figure class="listing" id="solid-notification" rel="schema:hasPart" resource="#solid-notification"> <pre about="#solid-notification" property="schema:description" typeof="fabio:Script"> <code>@prefix xsd: &lt;http://www.w3.org/2001/XMLSchema#&gt; .</code> <code>@prefix schema: &lt;https://schema.org/&gt; .</code> <code>@prefix as: &lt;https://www.w3.org/ns/activitystreams#&gt; .</code> <code>@prefix c: &lt;https://creativecommons.org/licenses/by/4.0/&gt; .</code> <code>&lt;&gt; a as:Announce ;</code> <code> as:<strong class="highlight-object">object</strong> &lt;http://example.net/foo/abc123&gt; ;</code> <code> as:<strong class="highlight-target">target</strong> &lt;http://example.org/article#conclusions&gt; ;</code> <code> as:updated "2016-01-24T00:00:00Z"^^xsd:dateTime ;</code> <code> as:actor &lt;http://csarven.ca/#i&gt; ;</code> <code> schema:license c: .</code> </pre> <figcaption property="schema:name">An inbox notification.</figcaption> </figure> <p>dokieli itself does not offer a mechanism for authors to manage their notifications or choose which interactions appear, as other applications which are specialised for these tasks are under development as part of the Solid application ecosystem.</p> <p>An author can also opt to allow anonymous interactions with their documents by pointing to a publicly writeable storage location in their own space, and store interactions on behalf of their audience.</p> </div> </section> </div> </section> <section id="social-and-technical-impact" inlist="" rel="schema:hasPart" resource="#social-and-technical-impact"> <h2 property="schema:name">Social and Technical Impact</h2> <div about="#social-and-technical-impact" datatype="rdf:HTML" property="schema:description" typeof="deo:Discussion"> <p>We identify data generation, ownership and reuse to be key areas of potential impact. Whilst dokieli is still very much a work in progress and the real impact is uncertain at this stage, we use these as a guide to inform our future direction.</p> <section id="data-generation" inlist="" rel="schema:hasPart" resource="#data-generation"> <h3 property="schema:name">Data generation</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Semantic structure in prose content is somewhat difficult to capture, and as a result the Linked Open Data cloud is lacking in data about knowledge and ideas expressed in this form. It is especially alarming that this is even the case for scholarly communication in Web science. Through automatic insertion of RDFa into articles and social interactions, and integration of a semantic annotation UI into a generic authoring application, we hope that a side effect of dokieli use will be an influx of previously uncommon but highly valuable Linked Open Data into the Web. Mining, reusing and remixing this data has the potential to give rise to new threads of conversation, connections between and perspectives on ideas and experiences. We are focussing on scholarly communication as a forum for encouraging knowledge sharing with dokieli through the <cite>Linked Research</cite> initiative, as an area in which augmenting content with machine-readable semantics can really improve knowledge transfer to benefit researchers.</p> </div> </section> <section id="data-ownership" inlist="" rel="schema:hasPart" resource="#data-ownership"> <h3 property="schema:name">Data ownership and reuse</h3> <div datatype="rdf:HTML" property="schema:description"> <p>Having more control over one’s personal data brings a number of potential, though as yet not necessarily properly tested or fully understood, advantages. We advocate at least for having the option to choose which organisations or individuals hold and have access to personal data, and thus argue that our progressive approach to participation at least serves as a starting point to lower the barrier to entry for data ownership.</p> <p>We believe a particular strength of the Linked Data approach is that data produced with dokieli is reusable by other applications, and easily integrated with data from other sources. Our work is towards encouraging an ecosystem of applications which are decoupled from user data, discouraging vendor lock-in as services must compete for user attention by providing value rather than hoarding information.</p> </div> </section> </div> </section> <section id="conclusions" inlist="" rel="schema:hasPart" resource="#conclusions"> <h2 property="schema:name">Conclusions</h2> <div about="#conclusions" datatype="rdf:HTML" property="schema:description" typeof="deo:Conclusion"> <p id="contribution" rel="schema:hasPart">In this article we discussed dokieli, an implementation of a proposed architecture for realising a decentralised and accessible participatory knowledge space. <span about="#contribution" property="schema:description" typeof="deo:Contribution">By building on existing standards and tooling we contribute towards their ongoing improvement and help to advance the state-of-the-art in user-friendly Linked Data applications, and decentralised social Web technologies. We have shown that native Web technologies coupled with Linked Data enhancements provide a sound grounding for human- and machine-friendly content publishing, and that cutting edge work on personal datastores can be employed on top in a progressive manner. We reiterate that enabling this kind of complex functionality on an as-needed basis serves as a gateway for users and lowers the barrier to entry more effectively than an all-or-nothing approach.</span></p> <p id="envision">We envision that a further implications of our work is expansion of the missing parts of the LOD cloud on scholarly communication, social interactions, and detailed discourse around ideas and experiences.</p> <p id="challenges">Meeting the combination of needs we outlined here comes with many challenges. This is not a new problem, and there are ongoing efforts and initiatives advancing these along various fronts. Having an architecture and tooling in place does not necessarily translate to adoption of technologies or even principles. We have not addressed social, economic, ethical or legal issues around data ownership, decentralised identity or Web applications decoupled from user data. Nonetheless, our efforts iterate towards better understanding of what is needed to improve tooling and user interfaces, so that we may move this area forward alongside related initiatives, and gradually lower the barrier to entry for participation in a decentralised, social, semantic Web.</p> <p>There is still work to be done. Development is in the open and we welcome you to <a href="https://gitter.im/linkeddata/dokieli">join the discussion</a>. Our next steps, small and large, are listed as <a href="https://github.com/linkeddata/dokieli/issues">issues</a> on our repository, but we conclude by describing some of the more prominent remaining problems to be addressed.</p> <dl id="next-steps" inlist="" rel="schema:hasPart" resource="#next-steps"> <dt property="schema:name">Next steps</dt> <dd about="#next-steps" property="schema:description" typeof="deo:FutureWork"> <p id="sharing">Realtime collaboration on documents is an important capability that dokieli does not yet offer, but we aim to implement. The UI will allow authors to invite their collaborators to edit, as well as request feedback and peer-reviewers (<a href="https://github.com/linkeddata/dokieli/issues/120">issue 120</a>).</p> <p id="pinging">We must concretise a mechanism for adding articles to collections or archives when they are published, for example updating a listing of blog posts, adding new publications to university repositories or sending new works to libraries automatically (<a href="https://github.com/linkeddata/dokieli/issues/38">issue 38</a>).</p> <p id="provenance">Where applicable, scientific processes should be captured in a way that is machine-readable, encompassing workflow and provenance level data. This type of information plays an important role in reproducibility of work, and fostering trust and confidence in results (issues <a href="https://github.com/linkeddata/dokieli/issues/41">41</a> and <a href="https://github.com/linkeddata/dokieli/issues/119">119</a>).</p> <p id="data-shapes">In order to improve the utility of social notifications sent and received by dokieli documents, we are considering the W3C <a href="https://www.w3.org/TR/shacl/">Shapes Constraint Language</a> (SHACL) vocabulary to describe the constraints notifications in particular circumstances. This will allow authors to use third-party applications to verify incoming notifications according to their own requirements (<a href="https://github.com/linkeddata/dokieli/issues/105">issue 105</a>).</p> </dd> </dl> <p about="" id="epilogue" rel="schema:hasPart"><span about="#epilogue" property="schema:description" typeof="deo:Epilogue">There is a growing list of dokieli <a href="https://github.com/linkeddata/dokieli/wiki#examples-in-the-wild">articles in the wild</a>, that is, researchers taking the initiative to control their work through self-publication. We invite you to try dokieli yourself right now! Leave a comment on this paper at http://csarven.ca/dokieli, or spawn a new or a copy that you can edit yourself. <em>Make it so!</em></span></p> </div> </section> <section id="acknowledgements" inlist="" rel="schema:hasPart" resource="#acknowledgements"> <h2 property="schema:name">Acknowledgements</h2> <div about="#acknowledgements" datatype="rdf:HTML" property="schema:description" typeof="deo:Acknowledgements"> <p>Special thanks to our colleagues at <span about="" id="funding-recipient" prefix="scoro: http://purl.org/spar/scoro/" rel="scoro:funding-recipient"><a about="http://dbpedia.org/resource/Massachusetts_Institute_of_Technology" href="https://mit.edu/" property="schema:name" rel="schema:url" typeof="schema:Organization">MIT</a></span>/<a href="https://www.w3.org/">W3C</a>; <a href="https://deiu.me/profile">Andrei Sambra</a>, <a href="https://www.w3.org/People/Sandro/">Sandro Hawke</a>, <a href="http://nicola.io/">Nicola Greco</a>, <a href="http://www.computingjoy.com/">Dmitri Zagidulin</a>, as well as <a href="http://bblfish.net/">Henry Story</a> and <a href="http://melvincarvalho.com/#me">Melvin Carvalho</a>. We are also thankful to collaborate with colleagues at <a href="http://qcri.org.qa/">QCRI</a>. This research was supported in part by <span about="" id="funder" prefix="scoro: http://purl.org/spar/scoro/" rel="scoro:funder"><a about="http://dbpedia.org/Qatar_Computing_Research_Institute" href="http://qcri.org.qa/" property="schema:name" rel="schema:url" typeof="schema:Organization">Qatar Computing Research Institute</a></span>, HBKU through the <a href="http://crosscloud.org/">Crosscloud</a> project. Last but not least, the contributors to the dokieli code, issues, and discussion.</p> </div> </section> <section id="references"> <h2>References</h2> <div> <ol> <li id="ref-1">Nelson, T.: Ted Nelson Demonstrates XanaduSpace, (2013) <a href="https://www.youtube.com/watch?v=1yLNGUeHapA&amp;t=50s" rel="schema:citation cito:includesQuotationFrom cito:citesAsSourceDocument">https://www.youtube.com/watch?v=1yLNGUeHapA&amp;t=50s</a></li> <li id="ref-2">Evolution of the Web, <a href="http://www.w3.org/DesignIssues/Evolution.html" rel="schema:citation cito:citesAsRecommendedReading cito:citesAsSourceDocument">http://www.w3.org/DesignIssues/Evolution.html</a></li> <li id="ref-3">Capadisli, S.: Call for Linked Research, Developers Workshop, ISWC (2014), <a about="" href="http://csarven.ca/call-for-linked-research" rel="schema:citation cito:citesAsSourceDocument">http://csarven.ca/call-for-linked-research</a></li> <li id="ref-4">Capadisli, S., Riedl, R., Auer, S.: Enabling Accessible Knowledge, CeDEM (2015), <a about="" href="http://csarven.ca/enabling-accessible-knowledge" rel="schema:citation cito:citesAsSourceDocument">http://csarven.ca/enabling-accessible-knowledge</a></li> <li id="ref-5">Khalili, A., Auer, S.: User interfaces for semantic authoring of textual content: A systematic literature review, Volume 22, ages 1–18 (2013), <a about="#related-work" href="http://www.sciencedirect.com/science/article/pii/S1570826813000498" rel="schema:citation cito:citesAsRelated">http://www.sciencedirect.com/science/article/pii/S1570826813000498</a></li> <li id="ref-6">Luczak-Rösch, M., Heese, R.: Linked Data Authoring for Non-Experts, LDOW, WWW (2009), <a about="#related-work" href="http://events.linkeddata.org/ldow2009/papers/ldow2009_paper4.pdf" rel="schema:citation cito:citesAsRelated">http://events.linkeddata.org/ldow2009/papers/ldow2009_paper4.pdf</a></li> <li id="ref-7">Khalili, A., Auer, S., Hladky, D.: The RDFa Content Editor — From WYSIWYG to WYSIWYM, COMPSAC 2012:531-540 (2012), <a about="#related-work" href="http://svn.aksw.org/papers/2012/COMPSAC2012_RDFaCE/public.pdf" rel="schema:citation cito:citesAsRelated">http://svn.aksw.org/papers/2012/COMPSAC2012_RDFaCE/public.pdf</a></li> <li id="ref-8">Volpini, A., Riccitelli, D.: WordLift: Meaningful Navigation Systems and Content Recommendation for News Sites running WordPress, Developers Workshop, ESWC (2015), <a about="" href="http://ceur-ws.org/Vol-1361/paper4.pdf" rel="schema:citation cito:citesAsSourceDocument">http://ceur-ws.org/Vol-1361/paper4.pdf</a></li> <li id="ref-9">Battle, S., Wood, D., Leigh, J., Ruth, L.: The Callimachus Project: RDFa as a Web Template Language, Consuming Linked Data, ISWC (2012), <a about="#related-work" href="http://ceur-ws.org/Vol-905/BattleEtAl_COLD2012.pdf" rel="schema:citation cito:citesAsSourceDocument">http://ceur-ws.org/Vol-905/BattleEtAl_COLD2012.pdf</a></li> <li id="ref-10">Jusevičius, M.: Graphity: generic processor for declarative Linked Data applications, SWAT4LS (2014), <a about="#related-work" href="http://ceur-ws.org/Vol-1320/paper_30.pdf" rel="schema:citation cito:citesAsSourceDocument">http://ceur-ws.org/Vol-1320/paper_30.pdf</a></li> <li id="ref-11">Principles of Design, <a href="http://www.w3.org/DesignIssues/Principles.html#PLP" rel="schema:citation cito:citesAsSourceDocument cito:citesAsRecommendedReading">http://www.w3.org/DesignIssues/Principles.html#PLP</a></li> <li id="ref-12">Berners-Lee, T., Mendelsohn, N.: The Rule of Least Power, <a href="http://www.w3.org/2001/tag/doc/leastPower.html" rel="schema:citation cito:citesAsSourceDocument cito:citesAsRecommendedReading">http://www.w3.org/2001/tag/doc/leastPower.html</a></li> </ol> </div> </section> </div> http://csarven.ca/dokieli Mon, 27 Jul 2015 00:00:00 <h1 property="schema:name">Webmention</h1> <div datatype="rdf:HTML property="schema:description"> <p><mark>This experimental work is kept here for historical reasons. If you want to build independently built applications that can send, receive, or consume data that is decoupled from the user-interface, with the notion of reusable notifications, as well as interoperable with the rest of the W3C stack, I recommend using the W3C Recommendation <cite><a href="https://www.w3.org/TR/ldn/">Linked Data Notifications</a></cite>.</mark></p> <p>This is my site’s webmention endpoint. Send <code>POST</code> requests to this URL (<code>http://csarven.ca/webmention</code>) with <strong><code>source</code></strong>, <strong><code>property</code></strong> (optional) and <strong><code>target</code></strong> (optional) parameters, or use the form below, to let me know that you’ve linked to a URL on my site. This endpoint can handle claims using RDF and microformats 2 data patterns found at the source.</p> <F>webmentionForm()</F> <p>As of <time datetime="2015-07-27" property="schema:dateModified" content="2015-07-27T00:00:00Z" datatype="xsd:dateTime">2015-07-27</time>, this webmention endpoint offers a way to be more flexibile and precise about the claims than the current webmention design. The approach taken at this endpoint is intended to be a superset on how to deal with mentions i.e., making the receiver aware of a hyperlink with a relation which may be of interest.</p> <p id="source-parameter">Webmention works essentially in two steps: 1) a claim is made 2) the said claim is verified, and possibly displayed. Thus, the source URL is the most essential component, regardless of whether the information for the <code>property</code> or <code>target</code> is provided. At the end of the day, the receiver makes all of the decisions on if and how to deal with the claim - in which, there is no formal specification that is globally accepted nor forced. Naturally this is a good thing. The information that is provided in the <code>POST</code> is just that, a claim. It may or may not be of interest to the receiver, and the receiver makes no promise to do anything with it. Making decisions e.g., optimization, trust, driven from the claim would be premature. Hence, decision making around optimization and trust, for instance, are best left outside of the original claim. The ability to receive only the source URL is the simplest design.</p> <p>We are now free to build rest of the blocks by optionally accepting the <code>property</code> and <code>target</code> parameters:</p> <p id="property-parameter">The <code>property</code> parameter indicates the type of relation between the source and the target (which is found at the source URL). Its value may be a <em>term</em> e.g., <code>u-in-reply-to</code>, a <em>IRI</em> e.g., <code>http://rdfs.org/sioc/ns#reply_of</code>, or a <em>prefixed name</em> e.g., <code>as:inReplyTo</code>. The <code>property</code> information allows us to make precise claims, i.e., mentions, and consequently 1) it gives an opportunity for the receiver to decide whether to even make a single <code>GET</code> on the source URL, 2) better narrowing down or filtering of the claim.</p> <p id="target-parameter">In a similar way to the <code>property</code> information, having the <code>target</code> allows us to further narrow down on the claim i.e., we can check if we want to deal with a claim made to that particular target URL, regardless of the <code>property</code> information being present or not.</p> <p>Table of possible <code>POST</code>s with interpretations:</p> <table id="webmention-posts"> <caption>Webmention <code>POST</code>s using <code>source</code>, <code>property</code>, and <code>target</code></caption> <thead> <tr><th><code>source</code></th><th><code>property</code></th><th><code>target</code></th><th>Possible process</th></tr> </thead> <tbody> <tr><td></td><td></td><td></td><td>Show error</td></tr> <tr><td></td><td>✔</td><td></td><td>Show error</td></tr> <tr><td></td><td></td><td>✔</td><td>Show error</td></tr> <tr><td></td><td>✔</td><td>✔</td><td>Show error</td></tr> <tr><td>✔</td><td></td><td></td><td>Verify interest with that <code>source</code></td></tr> <tr><td>✔</td><td>✔</td><td></td><td>Verify interest with that <code>source</code> and <code>property</code></td></tr> <tr><td>✔</td><td></td><td>✔</td><td>Verify interest with that <code>source</code> and <code>target</code></td></tr> <tr><td>✔</td><td>✔</td><td>✔</td><td>Verify <code>source</code>, <code>property</code>, <code>target</code></td></tr> </tbody> <tfoot> <tr><td colspan="4">✔ indicates that the parameter is submitted.</td></tr> </tfoot> </table> <p id="what-to-practice">What might be a good practice here? In my opinion, the sender should aim to be precise about the claim by providing all three components: source, property, and target, to the receiver. What do you think?</p> </div> http://csarven.ca/webmention