Skip to content

Use Cases & Requirements: Linking Guidance

Andrew Berezovskyi edited this page Nov 1, 2018 · 1 revision

Status: gathering input (please provide)

Background

Clarify terminology: link, relationship, triple, direction of link

Purpose

Understand what considerations should be given for linking guidance.

Organization of this document follows the guidance set out in OSLC Core-TC Editor's Handbook.

User Stories

As a user, I should be able to make a link from one resource to another in a manner consistent with existing linked data principles, so that I'm not surprised by complicated linking apis/designs.

As a user, I should be able to discover which resources are linked to a particular resource, so that I can understand better the role this resource plays in the lifecycle.

As a vocabulary designer, I should be able to use a single predicate to represent both "incoming" and "outgoing" relationships, so that I can avoid a profusion of predicates which are owl:inverseOf each other.

As a vocabulary designer, I should be able to support linking resources which cannot be modified, so that I can establish a relationship between baselined resources.

As a vocabulary designer, I should be able to support 1-to-many links, so that I can accurately model the semantics of linking in my domain.

As a vocabulary designer, I should be able to have properties on links, so that I can accurately model the semantics of linking in my domain.

As a user, I should be able to constrain what resources can be linked, so that my corporate information architecture can be implemented.

As a vocabulary designer/user (both?), I should be able to describe whether or not a lifecycle relationship is to be considered during impact analysis, so that I can get accurate impact reports.

As a user, I should be able to link between a binary executable and the binary shared libraries on which it depends, so that I can reason about my library dependencies.

Use Cases

TODO: determine what is needed here and fill it in

Requirements

Principle of single information source. Referential integrity, simplicity

Lifecycle relationships SHOULD be modelled as rdf:Property. Links (triples) are directly asserted. Reification of lifecycle relationships SHOULD be avoided.

Binary/non-linked-data representations

Link discovery

Link Issues and Proposals

This section is intended to catalog some of the issues we've seen with "OSLC Links" in typical 2.0 deployments and look at alternatives and trade-offs of those alternatives.

Scenario 2.0 Link Mgmt API Link Resource
Query simple RDF simple RDF need to navigate thread LR, plus deal with simple RDF stmts
Discovery of Link provenance (where do you go to modify a link) find resource, edit resource findLinkOwner(url) like 2.0, maybe a single link service
Add link PUT/PATCH PUT/PATCH POST + PUT/PATCH
  • 2.0 - each OSLC resource "holds" plain ole RDF statements that represent a relationship between itself and another resource

  • Link Mgmt API - links are held "where ever" and there is an index (like one created and updated via TRS feeds) that assists an API to locate the resources that own the relationship and then using PUT/PATCH to update the resource. There may also be a mechanism when resources are updated with a relationship, it would notify the link-to resource and any other registered interested parties. img: a means is also needed to allow a client to learn where it can ask the question "which resources have links that point at such-and-such a resource".

  • Link Resource - a separate HTTP addressable resource, typically there would be a service that manages these link resources for tool. *img: rather than thinking of a link resource, can we not instead consider the provenance statements <s,p,o> as representing disctinct authorities which make assertions about links from s? My first reading of "findLinkOwner(url)" in the table above is jarring

    • perhaps I don't understand the motivation for such a service? I would expect that the provenance of the link is the thing that would be needed in order to delete a link by removing the resource which makes the statement <s,p,o>. Link creation would be the dual - find a suitable place to make such an assertion (eg an LDPC) and POST it.*

3.0 Proposed Content

Minimum bar:

Extended content:

  • Link Mgmt API, doing more for "back linking" and "link to notifications"

References/Prior art