SHAME - Standardized Hyper Adaptible Metadata Editor

Terminology used in SHAME

Term Description
RDF RDF stands for Resource Description Framework, see specification documents or more specifically the RDF primer on W3C for an introduction.
Metadata Metadata is data about data. In SHAME we only consider metadata expressed in RDF. We are not limited to any specific syntax as long as we can parse it into the Jena2 API. Since SHAME works by executing a query, the metadata may reside locally or be accessed over a distributed network, e.g. the Edutella p2p network. However, if the metadata is accessed over the network it is not possible to edit it. In the API, metadata is accessed via the QueryTarget interface.
SHAME SHAME stands for Standardized Hyper Adaptable Metadata Editor. Today this acronym is unfortunately a bit misleading since SHAME can be used for presentation and querying as well. We are considering other usages as well, e.g. validation.
SHAME form A SHAME form is the form you actually see on the screen. Except what is presented / edited / queried (i.e. the value model) it is defined by an annotation profile (i.e. a graph pattern and a form template) and a form-creator.
Annotation Profile A annotation profile is a configuration that can be used to generate a SHAME form. A annotation profile consists of a graph pattern and a form template. See also formlet.
Formlet A formlet is a small modular annotation profile that are designed to be aggregated in different ways depending on context. Best practices for using SHAME is to write many small formlets that are responsible for editing small parts of RDF graphs, e.g. a single statement, and then allow them to be combined easily. The formlets are often configured and managed in sets. When loading a set of formlets from a file you make use of the FormletStore to first request a FormletConfigurationSets to be loaded which contains FormletConfigurations which is realized as a formlet when needed (this is to avoid loading and parsing of loads of files before they are needed). See the Using formlets example.

There is two kinds of formlets configurations:

  1. The atomic formlet configuration specifies a query and form explicitly via pointing to the files they are defined in.
  2. The compound formlet configuration specifies a base and a list of extension formlets which are used to build a new formlet
Value model A value model contains the data that the SHAME form will eventually display according to the annotation profile. There is currently no support for other value models than RDF graphs using the Jena API, however we firmly belive that other kinds of value models, as long as they represent RDF, would be possible, e.g. XML, relational database, or OWL. However, if the value model contains data in a form from which there is no simple translation to RDF, the graph pattern would have to be replaced with for e.g. SQL queries or XQueries.
FormletSet A set of formlets that are suitable to administer together. Typically all formlets that work with Qualified Dublin Core could belong together.
Graph Pattern The graph pattern expresses what constitutes a match, i.e. how metadata is encoded or should be encoded in RDF.
We express the graph pattern using QEL (Edutella Query Language) which is a datalog based language, see the MetaData editor example for a typical graph pattern in QEL. In the API the graph pattern and its execution is represented through the QueryModel, QueryEngine, and QueryTarget interfaces.
Note that when we use the graph pattern for editing and presentation we have another semantics for the QEL-query than the original specified in the Edutella project. The original semantics is used when we use it for querying though. TODO, describe this alternative semantics.
Variable Binding Set A set of Variables Bindings is the result of applying a graph pattern to a value model, i.e. in the case we have RDF in the value model the variable bindings constitutes individual resources and literals occuring in RDF-statements bound to the variables in the graph pattern. When editing, the write operations are made through the variable binding set. In the API the variable binding set is represented by the VariableBindingSet, VariableBinding and Value interfaces.
Form Template The form template expresses extra restrictions such as multiplicity, vocabularies, etc. and provides information of the final apperance such as labels and groupings. The form is expressed in RDF and in the API it is accessed by the FormModel Interface. See the MetaData editor example.
Form model The form model is the result of the form template being bound to a specific variable binding set. E.g. a form template might describe that the form should consist of two entries, first a title and then an author. However, in this case the data consists of two titles and three authors which of course is captured in the variable binding set. As a consequence the form model will have five entries which are created from the two form template entries.
In the API the form model is represented by the same FormModel interface as the form template.
Form Creator A form creator specifies two things:
  • the embedding, currently swing or java server pages
  • the usage, i.e for presentation, editing, querying etc.

In the API the form creator is represented via the Form, FormContainer and Workflow interfaces. Admittedly, exactly how these interfaces should work is still matter of discussion, especially the Workflow which might dissaper or be reworked in the future.