XML Metadata Editing

This area is devoted to collecting information about software development that people have done that directly addresses the process of creating and updating XML-encoded metadata, especially where some functionality for putting into and retrieving from repositories or XML databases is included.

The focus here should be on approaches and tools that are used locally, and may or may not be ready to share, that are designed to provide a high level of end-user functionality for schema that produce relatively flat XML. Schema of interest include, but are not limited to, Dublin core, MODS, VRACore, FGDC, UKETD_DC etc.

  • No labels

4 Comments

  1. Somewhat related: on a recent committer call, we discussed how to extend the REST-API to support the SOAP API-M relationships methods (addRelationship, purgeRelationship). These are methods that modify the inline XML RELS-EXT datastream. Rather than just add new verbs, I proposed we use writeable disseminators to accomplish this. This has the benefit of using the built-in Fedora disseminator architecture (one we extend it to support writeable disseminators) and is an approach that can be extended to handle the general case of updating inline XML datastreams.

    For reasons of time, it doesn't appear as if we are going to be able to implement this for 3.3. However, this would form a solid basis for tools that are updating XML metadata. Repositories could actually share sdefs/sdeps and services for various metadata schemas in a shared framework.

    1. It is really important not to have this idea aimed on only operating on in-line XML datastreams. It is a really good move for datstreams in general, but there are strong downsides to using in-line XML datastreams for any significant metadata that is aimed at end-users. The writeable disseminator idea should take care of that, if I understand correctly, but I just wanted to raise the red flag since Eddie mentioned in-line XML datastreams. I have found that people seem to assume that their metadata should go in them automatically. We have been telling people for a while not to have objects that have FOXML that go over about 20 k in size, if you are exposing the repository to end users.

      1. You're right to point out that this shouldn't be limited to inline XML datastreams. That just happened to apply to the specific case of RELS-EXT datastreams we were discussing.

  2. Brown University Library has built a nice XForms MODS editor. I had no trouble attaching a lightly modified version of it as a behavior to some test objects with MODS datastreams. I used the REST API to get edited content back into the repo. We (UVa) are working on an XForms editor for EAD, which could be used in a similar way. This approach of carrying metadata editors with the objects as behaviors is a little diffferent, but I think it bears investigation.