...
To be Semantic Web and Linked Data friendly involves
- publishing dereferencable dereferenceable http URIs for resources
- publishing of relationships between resources using these identifiers
The new REST API is a move forward in supporting these requirements as we now have dereferencable dereferenceable http URIs for Fedora resources.
...
- Identifiers
- Fedora resources have identifiers such as namespace:pid and namespace:pid/datastream, and their info:fedora/ URI forms (and similarly for disseminations)
- These identifiers are effectively scoped to a repository installation
- The new REST API provides globally dereferencable dereferenceable http URIs for resources, but these are not "defined" as (canonical) identifiers for resources.
- The existing "LITE" APIs also provide resolvable URI resource identifiers
- Fedora resources have identifiers such as namespace:pid and namespace:pid/datastream, and their info:fedora/ URI forms (and similarly for disseminations)
- Relationships
- The resource index is a single "graph" containing relationships for all objects
- Relationships must have either a Fedora object or datastream as the subject
- Limits metadata expression to "flat" schemes such as DC
- No support for "arbitrary" RDF datastreams in the resource index (eg for implementing additional RDF metadata schemes)
- Resource identifiers used in relationships are of the info:fedora/ form
- Difficult to "interpret" relationships outside of the scope of the repository
- The "specification" of what relationships exist for an object is defined in imperative code
...
- 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 disseminations - 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?
...
- object properties
- datastream properties
- reserved datastreams that contain RDF (RELS-*)
- reserved datastreams are translated to RDF (DC)
- relationships between objects and their datastreams and disseminatorsdisseminations
- relationships between objects and their content models
...
- arbitrary RDF datastreams
- arbitrary XML datastreams to be "lifted" to triples
- disseminators disseminations serving RDF
| Wiki Markup |
|---|
To support a flexible and extensible approach, we could define the generation of triples using content models (system and user) and a declarative approach for specifying triples (XSLT, GRDDL\[1\]). |
- System content model disseminators 65inators for generating RDF for
- Object and datastream properties triples (from the object's serialisation/FOXML)
- Relationships between objects, datastreams and disseminators disseminations (from the object's serialisation/FOXML)
- XML datastreams (DC)
- User content models specifying
- Additional arbitrary RDF datastreams to index
- RDF disseminators disseminations to index
- Conversion patterns for other XML datastreams and disseminatorsdisseminations
Updating of the resource index could then take place by querying the disseminations and datastreams specified by the system and user content models when an object is created, updated or deleted.
...
Additionally, or alternatively, "writeable disseminatorsmethods" could be provided as a generic mechanism to implement this, eg PUT a SPARQL Update to /objects/{pid}/methods/{sDefPid}/relationships?datastream=RELS-EXT
...
- 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
...
dereferenceable http URI resource identifiers in relationships
Fedora resources are currently identified using the info:fedora namespace. If resource identifiers are exposed as dereferencable dereferenceable 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.
...