Title

Dynamic metadata : Fedora as a Semantic Object Store

Primary ActorDeveloper / Repository Manager
ScopeTechnical
Levelpretty high
Story

Researchers or curators generate supplementary metadata while working on a resource. This evolving metadata represents their intellectual endeavour and is part of the economic justification for maintaining the resource. Example: EMLO, Early Modern Letters Online <http://emlo.bodleian.ox.ac.uk/>. Fedora needs to allow this behaviour which, gives meaning, context and value to objects as well as allowing them to participate fully in the Semantic Web/LOD world.

FOXML (or indeed any other approach such as METS) wraps metadata, introducing a bottleneck for resources with evolving metadata. All metadata have to be processed for update a resource which is at odds with the need to preserve some static metadata elements - unnecessary data handling introduces additional risk of corruption. A file system folder aggregates the metadata data streams that make up an object yet provides discrete access to different elements.

Serialisation only makes sense when the object is written to offline storage such as tape where the presumption of update no longer exists.

 

12 Comments

  1. This seems very much related to the "Objects can be associated with a descriptive metadata service" use case. Should they be combined, possibly with "Updating metadata fields of multiple objects"?  I think serialization, in particular for purposes of preservation/recoverability and communication, must be specified, but serialized forms shouldn't be the only form of transaction.

  2. How does the assertion "FOXML (or indeed any other approach such as METS) wraps metadata..." square with the fact that most description in Fedora repositories in fact takes place in datastreams, which are not serialized into FOXML unless the repository designers/operators force them to be (which choice is explicitly disrecommended)?

    1. I would like to consider whether all description could take place in datastreams, ideally using RDF.

       

      1. The only description that doesn't take place in datastreams now is that in the "object properties". Do you mean to suggest to move them into RDF? (Which sounds like a fine idea to me.)

        1. That would do it. I like as few dependencies and special cases as possible in my designs.

          In our system we define a virtual "manifest.rdf" in the manner of a linux configuration directory. It simply aggregates all the RDF files underneath it when requested. There is a "system.rdf" that contains automatically generated information (similar in some ways to RELS-INT) but any other rdf files underneath are "user" defined. Thus developers can segregate different types of metadata as they see fit for the application but there is one way to get it all - that only serialises for delivery. A more FEDORA-like implementation might have a RIGHTS and possible and RELS-EXT there.  

          1. This particular point (object properties in RDF) seems to me to be a candidate for an improvement to the 3-series, if anyone has time for it. Would you mind jotting a JIRA ticket down just so we don't lose track of the idea?

             

            1. Moving the object properties into a datastream (while a great idea) requires a change to the FOXML schema.  I'm still not sure that we can support them in the 3.x line.

              1. I had thought the suggestion was that the properties should be visible in the RDF. If instead the idea is to move them to the RDF and remove them from FOXML, then you're probably right. We could always make them optional in the FOXML, but that would still mean publishing a new schema, which is a drag and a half.

                1. I feel like there's some slippage here in the use of RDF versus Resource Index.

                  1. I meant RDF as in RDF-stored-with-the-resource, not RDF-in-the-RI.

  3. Unknown User (escowles@ucsd.edu)

    I think this use case is satisfied by the RESTful HTTP API - Objects functionality, which allows uploading RDF in bulk, or performing SPARQL Updates without having to package metadata in FOXML or a similar wrapper.

  4. Neil Jefferies, we should revisit the discussion of this use case based on current Fedora 4 functionality.