Versions Compared

Old Version 7

changes.mady.by.user Stephen Bayliss

Saved on

compared with

New Version 8

changes.mady.by.user Stephen Bayliss

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Note: The scope of this document goes some way beyond the London Committers' meeting agenda item - Interfaces. Comments welcomed on which are the most relevant issues to cover in the meeting.

This is an attempt to capture this thread

Fedora in the context of the Semantic web and Linked Data

...

  • The definitive source of all information should be in Fedora objects
    • No direct manipulation of the triple store - the triple store is a cache/index
  • The info:fedora URI scheme should be retained
    • supports re-use of objects across different repositories
  • As far as possible Fedora should "work" without using a resource index.

Proposals

1 Deprecate the "LITE" APIs.

  • Implement by using HTTP status code 301: moved permanently in the next release
  • Remove in subsequent release

2 Define canonical dereferenceable URIs for Fedora resources

  • Using the new REST API URIs

3 Restructure the resource index as named graphs

A named graph is a set of triples named by a URI.

...

  • The graph hierarchy to use - how granular? Start with something simple?
  • Mapping between resource identifiers and graph names
  • Separation of "core" relationships from "user-defined" relationships into different overall views? If the intention of the resource index is to store relationships between objects, we may not want to pollute that with other relationships, eg from arbitrary RDF datastreams
    • Relationships about the object and its datastreams - in <#ri>
    • Relationships from RELS-EXT, RELS-INT, DC - in <#ri>
    • Relationships from arbitrary RDF datastreams/disseminators - in <#riUser>
    • <#riFull> as a union of <#ri> and <#riUser>
  • Performance. Need to evaluate query performance over a network of named graphs vs storing all relationships in one single graph
  • Triple store support: Mulgara supports named graphs and views, what about other triple stores? MPTStore?
  • Impact on Mulgara's free-text index, do we create a parallel structure of free text graphs? Does Mulgara even support this?

4 Declarative specification of triples to create in the resource index

Triples are currently created for

...

  • How to define the above using system and user content models
  • How to specify the mapping between XML and RDF

5 Extend the REST API to incorporate relationships

The REST API does not currently implement methods for disseminating and managing relationships.

API methods should be implemented for querying and managing relationships.

...

  • REST endpoints to use - explicit relationships URIs vs content negotiation vs URL query string
  • Relationships update specification (SPARQL Update, or ...)
  • Supporting "generic" updates, eg repository-wide relationships methods and methods operating on an object as a whole
    • Subject and predicate can be used to determine what to update for object properties, datastream properties, Dublin Core
    • RELS-EXT, RELS-INT and arbitrary datastreams present a challenge. A triple with a Fedora object as a subject could be stored in RELS-EXT or in an arbitrary RDF datastream. Do we restrict fedora-model and fedora-system predicates to RELS-EXT and RELS-INT?
  • Supporting updates to XML datastreams that get converted to RDF
    • eg updating DC through relationship API methods

6 Support for dereferencable http URI resource identifiers in relationships

Fedora resources are currently identified using the info:fedora namespace. If resource identifiers are exposed as dereferencable http URIs using the REST API URIs, it would be useful to support these identifiers in relationships. Ie the ability to query and manipulate relationships using both the info:fedora namespace for Fedora resources and the http REST URIs.

...