...
Therefore this would support indexing of arbitrary RDF metadata datastreams in the resource index - for instance supporting metadata schemes that are not "flat".
Wiki Markup
- using foaf to describe a person who is a dc:creator of a resource
- identifying the taxonomy used to populate dc:subject
...
\[DEV:1\] http://dublincore.org/documents/dc-rdf/#app-a
Questions and issues
- 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/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?
...
- arbitrary RDF datastreams
- arbitrary XML datastreams to be "lifted" to triples
- disseminations serving RDF
...
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\[DEV:1\]).
- System content model disseminators for generating RDF for
- Object and datastream properties triples (from the object's serialisation/FOXML)
- Relationships between objects, datastreams and disseminations (from the object's serialisation/FOXML)
- XML datastreams (DC)
- User content models specifying
- Additional arbitrary RDF datastreams to index
- RDF disseminations to index
- Conversion patterns for other XML datastreams and disseminations
...
The resource index is currently updated by code in DOManager. An alternative to this could be to reimplement the update mechanism using a management decorator pattern (declared in fedora.fcfg).unmigrated-wiki-markup
\[DEV:1\] GRDDL is a mechanism for Gleaning Resource Descriptions from Dialects of Languages. It is a technique for obtaining RDF data from XML documents and in particular XHTML pages: GRDDL Primer [http://www.w3.org/TR/grddl-primer/|http://www.w3.org/TR/grddl-primer/]
Questions and Issues
- How to define the above using system and user content models
- How to specify the mapping between XML and RDF
...
- POST a set of triples to create new ones
- DELETE a set of triples to be deletedunmigrated-wiki-markup
- PUT a set of modifications to perform, eg using (a subset of) SPARQL Update \ [DEV:1\]
Additionally, or alternatively, "writeable methods" could be provided as a generic mechanism to implement this, eg PUT a SPARQL Update to /objects/{pid}/methods/{sDefPid}/relationships?datastream=RELS-EXT
All of the relationship API methods should operate directly on Fedora objects to remove dependency on the resource index - relationship GET methods should query the object directly rather than issuing RI queries.unmigrated-wiki-markup
\[DEV:1\] SPARQL Update - A language for updating RDF graphs: [http://www.w3.org/Submission/SPARQL-Update/|http://www.w3.org/Submission/SPARQL-Update/]
Questions and issues
- 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
...