SHAME - Standardized Hyper Adaptible Metadata Editor

SHAME Introduction


Expressing metadata with RDF is quickly growing in popularity. There are several ways to represent RDF, e.g. in XML (which is the most frequently used) or more home brewn variants like N3 or N-Tripple. There are many parsers and APIs to handle RDF on the programming level that are efficient and to the point. However, tools for aiding developers to provide editing, presentation and searching interfaces to the end user is scarce. Doing this in a generic way, i.e. without limiting the tools to a specific metadata schema is even more hard to find.


In general, SHAME aims to be a general purpose form-based graphical user interface where each entry reflects a single resource or literal in an RDF graph. A SHAME form should be configurable to be useful for a specific class of RDF-graphs. E.g. all RDF-graphs that describes resources according to qualified Dublin Core.

To be more specific lets consider the editing case, where the requirements on SHAME can be stated somewhat more concrete: First, SHAME should manage basic RDF, i.e:

  1. language controlled and datatyped literals.
  2. anonymous and non anonymous resources.
  3. arbitrary deep metadata constructs (not just direct properties).
  4. Bag, Seq and Alt constructs and their internal ordering.

Second, SHAME should allow editing to be restricted according to:

  1. specific multiplicity requirements.
  2. schemas or fixed lists of vocabularies.
  3. disallow editing on some places.

Third, the apperance of a SHAME form should:

  1. have labels that are configurable and language controlled.
  2. allow metadata to be grouped (groups within groups as well).

Fourth, a SHAME form should not destroy any information it is not configured to work with.


We have choosen to rely on an existing generic RDF API (Jena2) to access in-memory representation of RDF-graphs directly. For precise manipulation of specific parts of the RDF-graph (the value model) the generic RDF API alone is not suitable. Instead we rely on graph patterns that, when executed, produces a variable binding set from which the RDF-graph can be manipulated. The variable binding set is then combined with a form template which provides restrictions, order and general apperance resulting in a form model. Finally, the form model is used to render a actual SHAME form in a web browser or in a stand alone application via a form creator that also decides on the interaction pattern (the controller part).

This can described as a three-step chain:

StepInput Configuration Result
1)value model + graph pattern --> variable binding set
2)variable binding set + form template --> form model
3)form model + form creator --> SHAME form
Attach:SHAME-Annotation-Profile-usage.png Δ Δ
Illustration of Step 1 and 2 Illustration of Step 3

The combination of the graph patter and the form template is called a annotation profile or formlet depending on its size and modularity. The annotation profile is responsible for which metadata that is edited/presented/queried and which restrictions that are enforced. The choice of form creator, is only responsible for the actual rendering and interaction with the user. Hence, only a few different form creators for different types of embeddings and major tasks (such as editing, presenting or searching) will be enough. The number of different formlets on the other hand will be huge since they represents different usages and choices of metadata schemas. For ease of use we provide some premade formlets:

    * For widely known needs (e.g. Dublin Core and LOM) big compound formlets.
    * For more specific needs small atomic formlets implemented for a wide set of commonly known RDF schemas.

Hence, new SHAME forms can readily be constructed from these prefabricated formlets, or if you feel that formlets are missing there is a tool, the Formulator, to help you create new formlets from scratch. We also provide some small proof of concept applications that shows various usages of SHAME.