UKOLN - Projects - IEMSR - Review of IEMSR Presentation Service/Supplementary Functional Requirements

1. Introduction

This document is a response to comments made by CETIS and Becta staff following an initial informal review of the current prototype version of the IEMSR Web presentation service. It either makes suggestions for how they might be addressed or highlights where further work is required.

Note: This document makes a distinction between the human-oriented IEMSR Web presentation service ("the metadata portal") and the machine-oriented IEMSR database service(s) (the "registry server"). In principle, another party could develop a separate presentation service to provide functions based on information provided by the IEMSR registry server.

Figure 1: IEMSR registry server & IEMSR metadata portal

Figure 1: IEMSR registry server & IEMSR metadata portal

Although the issues by the reviewers are primarily related to the functionality and usability of the IEMSR Web presentation service, in some cases they have broader implications for the scope of the services provided by the IEMSR registry server.

2. IEMSR and Service Description

The requirement is to support queries such as:

(for a known DCAP or LOMAP) which Services deploy this DCAP or LOMAP? (And provide more information about those Services)
(for a known Service) which DCAPs or LOMAPs, and which Binding Schemas for those DCAPs/LOMAPs, are deployed by this Service? (And provide more information about those DCAPs/LOMAPs/Binding Schemas)

Such queries may be made by human users or by client applications.

(Note: some careful consideration is required on what it means to say that a Service deploys or uses a DCAP/LOMAP. It may be the case that a Z39.50 target or SRW/SRU server exposes multiple record formats (corresponding to the Binding Schemas of multiple DCAPs or LOMAPs), but it supports searches on only some restricted subset of attributes such as those corresponding to the properties of the Dublin Core Metadata Element Set. If it is recorded that a service deploys a DCAP/LOMAP, does that refer to the record formats exposed by the service or to the capacity of the service to support searches?)

The Agencies described in the data currently exposed by IEMSR are the publishers/owners of DCAPs and LOMAPs, not the administrators of services which deploy those DCAPs and LOMAPs. Information about services (and/or the relations between Services and DCAPs/LOMAPs or between Services and Binding Schemas) is not currently provided by the IEMSR registry server (i.e. there is no Service entity in the IEMSR data model), and, currently, the IEMSR Web presentation service relies exclusively on data from the IEMSR registry server.

In the context of the JISC Information Environment, information about services is (or will be) made available, at least primarily, through the IESR (Information Environment Service Registry) (and/or other service registries) [2].

The service data currently provided by IESR currently does not include information about DCAPs or LOMAPs deployed by services (and, to date, little attention has been given to e.g. the assignment of persistent identifiers to DCAPs and LOMAPs). In at least some cases it may be possible to obtain from IESR (or from the service itself) information about Binding Schemas used (e.g. from OAI-PMH ListMetadataFormats responses).

Also, the machine interfaces to IESR are still under development and the range of the services for which IESR provides descriptions is currently limited to those administered by a relatively small subset of service providers. It is not clear whether IESR will provide access to information on services that are not targetted at the HE/FE community (e.g. Curriculum Online).

Some possible approaches to addressing the problem are:

to leave human users to interact separately with the IEMSR Web presentation service and the IESR Web presentation service (and client applications to interact separately with the corresponding machine-oriented query services) and for those human users/client applications to join up the information from the two sources (see Figure 2)

Figure 2: Integration by client
to extend the IEMSR registry server to store/manage information about Services (and the relations between Services and DCAPs, LOMAPs, Binding Schemas etc) and to expose that information both to the IEMSR Web presentation service and to other client applications (see Figure 3)

Figure 3: IEMSR server provides Service data
to explore whether/how the IEMSR registry server might interact with the IESR registry server to obtain the information required and expose that integrated information both to the IEMSR Web presentation service and to other client applications (see Figure 4)

Figure 4: IEMSR server provides IEMSR/IESR integration service
to explore whether/how a separate service might interact with the IEMSR registry server and with the IESR registry server to obtain the information required and expose that integrated information both to the IEMSR Web presentation service and to other client applications (see Figure 5)

Figure 5: Integration service for IEMSR/IESR

The first approach places the responsibility on the human user or client application to use two services and merge the results.

While the second approach means that the IEMSR Web presentation service interacts only with the IEMSR registry server, it would require information about services to be permanently stored within the IEMSR database, with the challenge of keeping the information in synch with the information provided by the IESR and/or the administrators of services submitting information about their services to both the IEMSR and the IESR. The administrator of a service is not necessarily the same agent as the publisher of a DCAP, LOMAP or Binding Schema; the publisher of a DCAP, LOMAP or Binding Schema will probably not even be aware of all the services in which their schema has been deployed. The data creation tools which the IEMSR project is developing are designed for DCAP/LOMAP publishers, rather than the administrators of services , so some additional work would be required to capture the data, either by extending the current data creation tool or by providing some other input interface.

The third approach reduces potential redundancy between IEMSR and IESR but requires collaboration between the projects on the requirements for integration e.g. deciding which relationships are to be represented, use of identifiers for DCAPs, LOMAPs and Binding Schemas, and questions of the coverage of the data available through the IESR (see above)

The fourth option is a variant of the third but illustrates that the integration may be performed by a service provided by a third party. But as in option 3, integration would rely on e.g. the common use of identifiers.

Proposal: In the medium to longer term, a solution based on integrating data from IEMSR and IESR could be considered (option 3 or 4); in the short term, the IEMSR registry server/database might be extended to cover the required information about services (option 2). We need to clarify what is feasible within the lifetime of the current project, and what should be highlighted as a requirement for future work.

3. Concepts and their Labels

3.1 DCAPs, LOMAPs, Information Models and Binding Schemas

3.1.1 Concepts

It was emphasised that it is necessary to distinguish between "information models" for application profiles (descriptive schema or conceptual schema) and "schema bindings" that describe how instances are structured using specific data formats.

The IEMSR data model does make exactly this distinction: the IEMSR entity type/class LOM Application Profile (or DC Application Profile) is (I think) what is referred to here as an "information model (for an application profile)", and the IEMSR entity type/class Binding Schema is what is referred to as a schema binding [3, 4].

So the distinction required is already being made in the model, and a single LOM Application Profile may be associated with multiple Binding Schemas.

The property "Is Expressed By" is used to represent the relationship between a LOM Application Profile and a Binding Schema.

(See section 3.1.2 for discussion of labelling.)

Also, it was recommended that all LOMAPs/information models must have an associated Binding Schema (and that the registry server should periodically check the availability of the Binding Schema).

Question: Is this requirement feasible for all cases? Will there be LOMAPs registered/published before their Binding Schema is provided? Will there be LOMAPs which themselves are never associated with a Binding Schema because the expectation is that they serve as a "base LOMAP" for the designers of other LOMAPs to build on?

3.1.2 Current Data

The conceptual distinction described in section 3.1.1 may not be clear from exploring the IEMSR Web presentation service at this point in time. The current data does include (minimal) descriptions of Binding Schemas for the "OAI DC" and "RDN DC" DCAPs as distinct resources from those DCAPs themselves. However, it appears that the IEMSR Web presentation service is not rendering this description as expected on the View DCAP Detail page. See e.g. the OAI-DC DCAP

i.e. it renders the identifier of the Binding Schema as a hyperlink to an "external resource" rather than to a link to a page describing the Binding Schema. There are typos in the data but there may also be a minor error in the application. (But see also section 4.1.2 on merging some of the display pages).

Proposal: Fix data, check whether application rendering Binding Schema description

The IEMSR data model does support the description of the publisher of the Binding Schema, but the current data does not include any examples of that relationship.

Proposal: Add examples to data

3.1.3 Labels

Currently, IEMSR uses the following labels:

"LOM Application Profile" for the class of "specifications of how the information model described by the IEEE LOM standard is adopted to the requirements of a particular metadata application"
"Binding Schema" for the class of "documents containing a machine-readable description of how to structure a metadata record conforming to a DC Application Profile or a LOM Application Profile."
"Is Expressed By" for the property which represents the relationship between a LOMAP/DCAP and a Binding Schema

(See section 3.2 for discussion of "Schema Document" and "Is Defined By")

It is important to note that there are distinct labels for the classes (resource types) and the properties (relationships between resources).

The suggestion is that the property would be better labelled as "Schema Binding", rather than "Is Expressed By", to provide an indication of the type of the object and to differentiate it more clearly from the rdfs:isDefinedBy property (see section 3.2).

Proposal: Change the label of the iemsr:isExpressedBy property from "Is Expressed By" to "Schema Binding"

I'm not sure whether the suggestion is also to change the labels of the classes:

iemsr:LOMApplicationProdile: "LOM Application Profile" to "Information Model"
iemsr:BindingSchema "Binding Schema" to "Schema Binding"

The label "LOM Application Profile" has been used in several documents. It would be quite a significant change to alter this to "Information Model". The label "Binding Schema" could be changed to "Schema Binding", but it seems slightly non-intuitive if the instances of the class are recognised as "Schemas"?

Question: Should we change the label of the Binding Schema class to "Schema Binding"?

3.2 "Schemas": Schema Documents and Binding Schemas

3.2.1 Concepts

The IEMSR data model includes entity types called Schema Document and Binding Schema, represented by corresponding RDFS classes.

The class of Schema Documents (iemsr:SchemaDocument) is the class of RDF data sources used as input to the IEMSR server, including the descriptions of DCAPs and LOMAPs created using the IEMSR authoring tool but also including other RDF data published on the Web. The label "RDF schema" was not used because although the class of Schema Documents includes resources that are typically referred to as "RDF schemas" (see Note 1), it also includes data sources which are not "RDF schemas", as that term is generally used (e.g. a description of a DCAP or a LOMAPs created using the IEMSR authoring tool is not what is generally recognised as an "RDF schema").

A Schema Document is a distinct entity from a DCAP or LOMAP (though, as has been noted by reviewers, these are also sometimes referred to as types of schema).

Schema Documents were included as entities in the IEMSR data model so that:

it is clear that there is a separation between the IEMSR registry server and the data to which it provides access. The data is created and maintained independently of the IEMSR registry server and is available for use by other applications independently of the IEMSR registry server
the IEMSR registry server can expose data in the same aggregations in which it is provided to the server e.g. if a user of the data creation tool creates descriptions of various resources and saves those descriptions as a single document, other users can access that same document containing that same set of resource descriptions
by capturing metadata about Schema Documents, the IEMSR can provide some basic provenance information for the other resource descriptions e.g. users can establish that the description of a DCAP was provided in a data source created by an agency other than the publisher/owner of the DCAP.

The property rdfs:isDefinedBy is part of the RDF Vocabulary Description Language (RDF Schema) and in IEMSR data it is used to describe the relationship between a resource of any type and the Schema Document in which it is described. N.B. The object of an rdfs:isDefinedBy predicate (in the context of IEMSR, at least) is a reference to a Schema Document, not a LOMAP or a DCAP.

The class of Binding Schemas is the class of "structural schemas" that constrain the content of XML documents (W3C XML Schemas, etc).

3.2.2 Labels

Question: If the labels "Schema Document" and "Binding Schema" are a source of confusion, should we change the label/name of the iemsr:SchemaDocument class to something like "RDF Data Source"? (Or even, at a push, "RDF schema" (and accept that that usage may be "stretching" the term rather))?

If we make this change, then where possible the titles used in the data should reflect this. However, where the IEMSR server (re)uses RDF data already published elsewhere, it is impossible to enforce this.

The label "Metadata Schema Registry" is itself perhaps slightly misleading: the resources being "registered" are not only "Schema Documents" or "Binding Schemas" but all the other types of resource listed. It was not the intention to suggest that the IEMSR was a registry only or primarily of "structural schemas"/Binding Schemas.

3.3 Metadata Application Profiles: DCAPs and LOMAPs

3.3.1 DCAPs v LOMAPs

Comments suggested that the separation of metadata application profiles into distinct sets of DCAPs and LOMAPs was a barrier to discovery and made navigation more complex.

This touches on the underlying problem that faces the IEMSR: that of dealing with two different conceptual frameworks within the context of a single application. The distinction between a DCAP and a LOMAP is necessary because they are different types of entity: a DCAP specifies the properties used in a DC metadata description set; a LOMAP specifies how the LOM tree structure is constrained/adapted.

To facilitate discovery, it would be possible to introduce a Metadata Application Profile super-class to enable browsing/searching of the combined set of descriptions of DCAPs and LOMAPs (or have the application group them together). However, the browse/search list should indicate that the set of resource descriptions presented are descriptions of two different types of resource, either by partitioning the list or by displaying an indication of the type (DCAP or LOMAP).

See section 4.1 on navigation

Re browsing by project, if "project" refers to the publisher of the AP then this function is available now. i.e. the detail display page for an Agency includes the list of DCAPs and LOMAPs that they administer/publish. If "project" refers to the (administrator of the) Service that deploys an AP, see section 2.

3.3 Describing DCAPs and LOMAPs

It should be emphasised that the data currently exposed by the IEMSR is a very small sample and, in at least some cases, the textual descriptions of DCAPs and LOMAPs have been composed by IEMSR project members, rather than by the owners/publishers of the resources. It is quite probable that those agencies would provide fuller descriptions including more information of relevance to the user community, and searching of that extended text would improve retrieval.

However, it may also be useful to consider to extending the metadata collected about DCAPs/LOMAPs if there are additional attributes that would improve retrieval.

Question: Are there other attributes of a DCAP or LOMAP that it would be useful to record to facilitate discovery? Function/purpose? Audience? (I think we'd need controlled vocabularies for these to be useful.)

4. Presentation/Navigation of IEMSR Web presentation service

4.1 Overall Structure/Navigation

The IEMSR data model represents all the component parts of a LOMAP and DCAP as individual resources. This level of granularity is useful/necessary for applications using the data. However, the comment that the presentation gives the impression of being "inside-out" probably refers to the fact that currently the IEMSR Web presentation service adopts the same "fine-grained" approach, i.e. it presents hyperlinked lists of all (or nearly all) those individual resources and displays the descriptions of those resources one per page to the human reader. While this reflects the relationships between resources, it does tend to obscure the fact that in many cases these resources are component parts of composite/aggregate resources. It also requires the user to navigate a large number of hyperlinks which can lead to a sense of "getting lost".

Some suggestions for changes:

the impression of being faced with a very large number of menu options would be mitigated by establishing separate entry points for the navigation of the DC/DCAP data and the LOM/LOMAP data. See section 4.1.1.
some resource descriptions that are presently displayed as separate pages may be better displayed as part of a page describing a related resource. See section 4.1.2.
where a resource description is displayed as a separate detail display page, then the detail display page should clearly indicate important "contextual" relationships (e.g. whether resource is part of some composite resource) - but the requirements for such highlighting probably vary across different resource types. See section 4.1.3.
hyperlinks should be provided to external resources, and it should be made clear where a hyperlink is to an external resource rather than to a resource description page generated by the IEMSR presentation service See section 4.1.4.
treat Schema Document descriptions as special case?

4.1.1 Partition Presentation of DC/DCAP and LOM/LOMAP Resource Descriptions

Part of the difficulty for the user is caused by the fact that the main menu page presents both DC/DCAP data and LOM/LOMAP data, which was not anticipated when the labels for the classes were selected. Some of the items available on the menu at present are provided only for debugging purposes and will be removed, but even so the combined set of options may be a source of confusion.

One approach would be to partition the presentation so that separate entry points/menu pages are provided for the DC/DCAP classes and for the LOM/LOMAP classes. i.e. The DC/DCAP entry point would list:

Agencies [probably too difficult to try to restrict to Agencies which are publishers of DC/DCAP-related resources?]
Metadata Vocabularies
Properties
Classes
DCAPs
? Binding Schemas (only Binding Schemas which are related to DCAPs) (? not sure a browse is required)

(and corresponding search options).

(I think we probably need to add Browse/Search on Encoding Schemes (i.e. those Classes that are referenced as objects of iemsr:encodingScheme predicates.)

And the LOM/LOMAP entry point/menu page would list:

Agencies [probably too difficult to try to restrict to Agencies which are publishers of LOMAP-related resources?]
LOM Application Profiles
LOM Data Elements
Vocabularies
- LOM Vocabularies
- Non-LOM Vocabularies
? Binding Schemas (only Binding Schemas related to LOMAPs) (? not sure a browse is required)

(and corresponding search options).

This does have the consequence that a user needs to establish first which of these entry points to use. There is also an issue of some resources being instances of classes "on both sides" (e.g. Vocabularies are also Classes) and the presentation of hyperlinks that take the user "from one side to the other" but with some care that should be avoidable.

On the other hand this approach does move in the opposite direction from the request above to improve discovery across both DCAPs and LOMAPs. So it is probably desirable to retain a "cross-model" menu/entry-point too, listing

Agencies
Application profiles
- DCAPs
- LOMAPs
? Binding Schemas (? not sure a browse is required)
? Schema Documents (? not sure a browse is required)

Proposal: Provide three separate menus/entry points, (Could this be done as a tabbed view of a single page?)

4.1.2 Reduce number of detail display pages/hyperlinks

The IEMSR Web presentation service currently presents each resource description as a separate HTML page. In some cases, this slightly obscures the fact that resources are component parts of composite/aggregate resources. It requires the user to navigate a large number of hyperlinks, which can convey an impression of being "lost".

For some resource types it may be better to display the resource description as part of a page describing a related resource - particularly where the amount of information provided is relatively small - , so that the user can obtain the information without having to navigate away from a page and then return to it. It was already intended to provide some "View xxx for Print" pages where multiple resource descriptions were combined, but it may be worth taking this approach for the default "View xxx Detail" page.

The risk of this approach is that it may result in some pages becoming very large, particularly in cases where the amount of information provided in literal values varies considerably. e.g. while some of the LOM Data Element Usage descriptions in the UK LOM Core LOMAP are short, others are several hundred words long. So in practice, it is probably applicable only to a small proportion of the descriptions

Proposal: Suggest we experiment as follows.

View Agency Detail

Display Text Document Detail as nested table/list rather than title and hyperlink to separate description page

View Metadata Vocabulary Detail

Display Text Document Detail as nested table/list rather than as title and hyperlink to separate description page

Display Schema Document Detail as nested table/list rather than as title and hyperlink to separate description page

? Display Property Detail as nested table/list and also provide hyperlink to separate description page

? Display Class Detail as nested table/list and also provide hyperlink to separate description page

View Class Detail

Display Text Document Detail as nested table/list rather than as title and hyperlink to separate description page

Display Schema Document Detail as nested table/list rather than as title and hyperlink to separate description page

View Property Detail

Display Text Document Detail as nested table/list rather than as title and hyperlink to separate description page

Display Schema Document Detail as nested table/list rather than as title and hyperlink to separate description page

View DCAP Detail

Display Text Document Detail as nested table/list rather than as title and hyperlink to separate description page

Display Schema Document Detail as nested table/list rather than as title and hyperlink to separate description page

View Property Usage Detail

Display Text Document Detail as nested table/list rather than as title and hyperlink to separate description page

Display Schema Document Detail as nested table/list rather than as title and hyperlink to separate description page

Display Class Document Detail for Subject Type as nested table/list and also provide hyperlink to separate description page

Display Class Document Detail for Encoding Scheme (including Instances) as nested table/list and also provide hyperlink to separate description page

View LOMAP Detail

Display Text Document Detail as nested table/list rather than as title and hyperlink to separate description page

Display Schema Document Detail as nested table/list rather than as title and hyperlink to separate description page

View LOM Data Element Usage Detail

Display Text Document Detail as nested table/list rather than as title and hyperlink to separate description page

Display Schema Document Detail as nested table/list rather than as title and hyperlink to separate description page

Display Vocabulary Detail (including Vocabulary Values) as nested table/list and also provide hyperlink to separate description page

View Vocabulary Detail

Display Schema Document Detail as nested table/list rather than as title and hyperlink to separate description page

Display VDEX Document Detail as nested table/list rather than as title and hyperlink to separate description page

View Non-LOM Vocabulary Detail

Display Text Document Detail as nested table/list rather than as title and hyperlink to separate description page

Display Schema Document Detail as nested table/list rather than as title and hyperlink to separate description page

4.1.3 Ensure that detail display pages provide appropriate navigation/context

Some resources that are described on separate "View xxx Detail" pages are related to other resources in ways which are particularly significant for their interpretation.

This is particularly true for e.g.

Properties and Classes, and the Metadata Vocabularies of which they are part
Property Usages and the DCAPs of which they are part
LOM Data Element Usages and the LOMAPs of which they are part

However the information in these resource descriptions (particularly in the case of Property Usages and LOM Data Element Usages) sometimes includes quite large literal values, so that embedding them in the page describing that related resource (as proposed in section 4.1.2 would result in some very large pages.

It is commonly the case that the user wishes to navigate between e.g. the description of a LOMAP and several of its constituent LOM Data Element Usages. The presentation of the descriptions should make that process as easy as possible. So, rather than (or as well as) displaying the relationship between e.g. the LOM Data Element Usage and the LOMAP as part of the main tabulated data, it may be helpful to have some sort of navigation block at the head and/or the foot of the page. e.g.

on view Class/Property detail page, hyperlink to view Metadata Vocabulary detail page
on view Property Usage detail page, hyperlink to view DCAP detail page
on view LOM Data Element detail page, hyperlinks to view LOM Data Element detail pages for each LOM Data Element in path up to root
on view LOM Data Element detail page, hyperlinks to view LOM Data Element Usage detail pages for each LOM Data Element in path up to root, and hyperlink to view LOMAP detail page

(Any other suggestions please?

Proposal: Ensure that detail display pages enable appropriate navigation to descriptions of related resources

Information about relationships with other resources also provides the contextual information that is also required to enable the reader to disambiguate the current resource from another resource with a similar label. The view detail pages for resources should provide information to indicate context in ways that are familiar to the human reader.

e.g. on the "view LOMAP detail" page, the list of LOM Data Element Usages is a "flat" list. While there are no isChildOf relations between LOM Data Element Usages, they are "usages of" things which are hierarchically related (LOM Data Elements) and this should be reflected in the presentation e.g. by using indentation on the number/label strings in the "Uses" column.

e.g. on the "view LOM Data Element detail" and "view LOM Data Element Usage detail" pages, the IEMSR presentation service should generate a full "hierarchical name" (e.g. "1.4 General.Description"). (There are several elements labelled "Description" and it really needs a clearer indication of the context to avoid ambiguity).

(See also section 4.3.4 on QNames.)

Proposal: Ensure that detail display pages provide contextual information where appropriate

On a related note, it was pointed out that some pages include self-referential hyperlinks. No page should contain a hyperlink which targets that same page. This is a bug, and occurs on the view detail pages for:

Classes (the table of instances includes a hyperlink to the description of the Class)
Vocabularies (the table of "values" includes a hyperlink to the description of the Vocabulary)
LOM Vocabularies (the table of "values" includes a hyperlink to the description of the LOM Vocabulary)
Non-LOM Vocabularies (the table of "values" includes a hyperlink to the description of the Non-LOM Vocabulary)

Proposal: Remove these hyperlinks.

4.1.4 Hyperlinks to external resources

All the pages presented by the IEMSR Web presentation service are descriptions of resources (and/or lists of names/titles of resources hyperlinked to descriptions of resources). Some of those resources are "abstract" resources (properties, LOM Data Elements, DCAPs, LOMAPs etc), so the resource itself can never be presented, only a description or representation. Other resources are documents published on the Web (human-readable texts, XML Schemas, RDF/XML documents etc).

In the second case, the IEMSR Web presentation service currently displays a page describing the resource, which should include a hyperlink to the external resource, but they have not been provided. This applies to:

Schema Documents
Text Documents
Binding Schemas
VDEX Documents

(This now applies also to the "inline" presentation of these resource descriptions proposed in section 4.1.4)

Proposal: Hyperlinks should be provided to all external resources described. Where the target of a hyperlink is an external resource, rather than a description page generated by the IEMSR Web presentation service, it should be labelled to indicate that. All hyperlinks which are not labelled are links to description pages generated by the IEMSR Web presentation service.

4.1.5 Schema Document descriptions

Question: Since the description of a Schema Document is in part "administrative metadata" for the current resource description, should we treat the presentation of descriptions of Schema Documents as a special case? e.g. display in a block in the same position on each page?

4.2 Multiple Interfaces for Different Audiences

It was suggested that it would be helpful to have a choice of views for distinguish researchers/info scientists on the one hand and developers and technicians on the other, and maybe a "beginners"/"back-to-basics" view for non-technical users.

In principle, it would be possible for the IEMSR Web presentation service to provide different views for different user groups, if the requirements can be established (and providing the necessary data is available. See e.g. section 2.

Proposal: Establish requirements for separate "researcher/information scientist" and "developer/technician views"

However, it is important to bear in mind that it is not the aim of the IEMSR project to develop a complex presentational service. The IEMSR Web presentation service is targetted primarily at users who are relatively "expert" and are already familiar with the concepts - designers of metadata application profiles, developers of applications that generate or consume metadata, researchers investigating the use of metadata vocabularies. It is not aimed at novice users, and it is not intended that it should provide an introduction to metadata concepts. Also, the creators of instance metadata are unlikely to be users of the IEMSR Web presentation service; they may well be users of information that is provided via the IEMSR server but that information will be presented to users by other applications.

Having said that, it would be a good idea to have some sort of "help" page(s) with a description of the concepts and maybe a "site map" outlining the structure/navigation of the Web site.

Proposal: Develop help/site map pages

It was also suggested that IEMSR should provide pointers to external resources of general relevance to the topic, rather than just documents specific to individual APs etc. It would be possible to create a list of documents of general interest to be maintained as a static "links" page. e.g. the IMS Meta-data Best Practice Guide. (BS8419 appears to be available only as a hardcopy document from the BSI?). Documents related to specific DCAPs or LOMAPs would be described as Text Documents in IEMSR data.

Proposal: Assemble list of static links.

4.3 Various Display Issues

4.3.1 Detail Page Headings (Resource type, URI)

The combination of resource type label and URI reference was regarded as inappropriate as the main page heading.

It does seem important that each page includes some fairly prominent indication of the type of the (primary) resource described on that page, not least to assist the human reader in navigating between resource descriptions.

Proposal: Use human-readable label/title as heading with resource type label as subtitle???

At present, many (but not all) of the URIrefs displayed are of use only for the IEMSR application, i.e. other applications do not cite URIs for LOMAPs, DCAPs, Property Usages, LOM Data Element Usages etc. However the purpose of assigning URIrefs to these resources is so that they can be cited by other applications to reference those resources unambiguously. In some cases, it seems unlikely that they will be cited elsewhere (Property Usages, LOM Data Element Usages etc), but in other cases, they certainly will. For example, if the IEMSR Web presentation service and/or other client applications are to make use of data provided by both the IEMSR server and the IESR server as suggested in section 2, then the ability to merge data from those two sources effectively will depend on the consistent use of URIrefs to identify, e.g., Services, DCAPs and LOMAPs. The use of plain literal strings as identifiers ("The UK LOM Core, version 0.9" or "The JORUM OAI repository") will not be sufficient, and it is important that human users can discover URIrefs via the IEMSR presentation service.

(We should also be careful to ensure that any IEMSR-created URIrefs which are exposed are likely to be persistent).

Proposal: Display URIrefs but as first item in main table/list rather than as part of heading?

4.3.2 Language Tags

Proposal: Expand language tags for presentation

4.3.3 Datatypes

Where a date predicate is used, the class of the object resource is displayed as "Datatype: [URIref]". It should be displayed as the label of the class, as is done for other classes.

Proposal: Fix display of date classes.

4.3.4 Display QNames for Properties/Classes

The IEMSR presentation service should generate QName representations of the URIrefs for Properties and Classes (using the data provided in the Metadata Vocabulary description), since many human readers are more familiar with the QName form e.g. "dc:identifier" than with the URIref or the label, "Resource Identifier". Also labels are likely to be reused, and the presence of the QName helps the user disambiguate resources with similar labels. (e.g. the property list already includes "subject", "Subject and keywords", and "Subject Type".

Proposal: Display QNames for Properties and Classes.

(See also section 4.3.5 on sorting/grouping.)

4.3.5 Browse options

The IEMSR Functional Requirements document [1] specified various sorting/grouping options for browsing (e.g. present Property/Class lists sorted by QName, grouped by Term Status) to supplement the simple sort by label/title. These options have not yet been implemented.

Proposal: Implement options for sorting, grouping.

4.3.6 Property/Class: Label v Name

The literal value of the rdfs:label property is displayed with the label "Name"; it should be labelled "Label". (DCMI uses "Label" for the human-readable label, and "Name" for the "local part" of the QName form. e.g. the "Name" of dc:identifier is "identifier" and the "Label" is "Resource Identifier".

The same applies on the various browse lists for these resource types.

Proposal: Fix labelling.

4.3.7 View Class Detail

On the "view Class detail" page, the list of instances of the class is headed "Vocabulary Values". It should be headed "Instances", as not all Classes are "Vocabularies".

Proposal: Fix heading.

Also the View Class Detail page should list

DCAPs where this Class is the Subject Type in a Property Usage
Property Usages where this Class is the Encoding Scheme in a Property Usage

Proposal: Generate lists as specified in IEMSR FR.

5. Data issues

5.1 Data reuse

The IEMSR server should reuse existing RDF/RDFS data published by the owners of metadata vocabularies e.g. DCMI etc. At the moment, the input for DCMI vocabularies is from copies of the DCMI data, which is unsatisfactory as there are minor errors (e.g. "RFC1766") and DCMI regularly updates the data.

The IEMSR server requires data additional to that provided by DCMI, but the IEMSR-specific files should provide only those additional triples: they should not duplicate the data already provided by DCMI.

We require tools to support this process (see IEMSR FR section 2.5.1); in the short term, the additional data will have to be created manually, but this is not sustainable for every RDF vocabulary to be registered.

Proposal: Fix data. Develop longer-term solution.

5.2 iemsr:Vocabulary Class and "Vocabulary" LOM Datatype

At the moment we are providing a class iemsr:Vocabulary (of which all LOM Vocabularies and Non-LOM Vocabularies are instances, and also a LOM Datatype called "Vocabulary" (an instance of the class iemsr:LOMDatatype).

But these are the same resource: the class of Vocabularies is the Vocabulary LOM Datatype. So there is no need for two distinct resources: the class of Vocabularies should be typed to be an instance of the class iemsr:LOMDatatype.

Proposal: Fix data.

Notes

Note 1: In the context of the RDF specifications, the term "schema" or "RDF schema" is used in two ways:

as "RDF Schema", to refer to the RDF vocabulary defined by the RDF Vocabulary Description Language (RDF Schema) specification [5]. e.g.

the terms of the Dublin Core Metadata Element Set are described using RDF Schema

i.e. the terms are described using statements that make use of the RDF Vocabulary Description Language
(more informally) as "an RDF schema", to refer to a set of RDF statements (typically published as a single RDF/XML document) that describe the terms that make up an RDF vocabulary

the terms of the Dublin Core Metadata Element Set are described in an RDF schema published by DCMI

i.e. the terms are described in a document published by DCMI (which contains a set of statements that make use of the RDF Vocabulary Description Language (and maybe other RDF vocabularies as well))

References

[ 1] Functional Requirements for the IE Metadata Schema Registry
http://www.ukoln.ac.uk/projects/iemsr/wp2/funcreq/

[ 2] JISC Information Environment Service Registry: Pilot Project
http://www.iesr.ac.uk/

[ 3] Model for a Dublin Core Application Profile
http://www.ukoln.ac.uk/projects/iemsr/wp2/dcap/

[ 4] Model for a LOM Application Profile
http://www.ukoln.ac.uk/projects/iemsr/wp2/lomap/

[ 5] Dan Brickley. RDF Vocabulary Description Language 1.0 (RDF Schema), W3C Recommendation. February 2004.
http://www.w3.org/TR/rdf-schema/

JISC IE Metadata Schema Registry

Review of IEMSR Presentation Service/Supplementary Functional Requirements