...
This is an attempt to capture this thread
Presentation given at the London 2010 Committer's meeting is here
Fedora in the context of the Semantic web and Linked Data
...
Therefore this would support indexing of arbitrary RDF metadata datastreams in the resource index - for instance supporting metadata schemes that are not "flat".
There are some Dublin Core examples [DEV:1] where Fedora would currently be unable to index the RDF in the resource index, including
- 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\]). Wiki Markup
- System content model 65inators 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
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.
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).
[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 \[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/] Wiki Markup
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 deleted
PUT a set of modifications to perform, eg using (a subset of) SPARQL Update \ [DEV:1\]Wiki Markup
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
...