ORE Specification and User Guide - Open Issues

3 April 2008


This document was part of an alpha release and has been superseded.

This version:
Latest version:
Previous version:
Editors (OAI Executive)
Carl Lagoze, Cornell University Information Science
Herbert Van de Sompel, Los Alamos National Laboratory
Editors (ORE Technical Committee)
Pete Johnston, Eduserv Foundation
Michael Nelson, Old Dominion University
Robert Sanderson, University of Liverpool
Simeon Warner, Cornell University Information Science


Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources.  This document lists open issues in the OAI-ORE specification and user guide documents that make up the OAI-ORE standards.

1. Issues to be considered

The following topics are agenda items for ORE Technical Committee discussions before the beta release.

1.1 Aggregation without enumeration

There is considerable interest in extending the ORE Data Model to handle the notion of aggregation without explicitly enumerating all of the Aggregated Resources. This would likely involve a URI templating mechanism.

1.2 Choice regarding external vocabularies

Should the ORE select or promote certain vocabularies as preferred or not?

2. Open Issues noted in specific documents

The following issues are noted in the current OAI-ORE specification and user guide documents and have yet to be resolved. Each section refers to a specific document and a particular issue may appear in more than one document.

2.1 ORE User Guide - Primer

2.1.1 N3 or not

A number of examples in this document are shown in N3. As this is now the primer then it would be better to recast all snippets as pictures with tables of triples where necessary (in the manner of the Data Model but with these simpler cases).

2.1.2 Update picture to use similarTo

The figure must be updated to use the ore:similarTo predicate instead of owl:analogousTo.

2.1.3 Need Serialization Primer

Need to write serialization section of primer.

2.1.4 Need HTT Implementation Primer

Need to write HTTP implementation section of primer.

2.1.5 Need Discovery Primer

Need to write discovery section of primer.

2.2 ORE User Guide - Resource Map Implementation in Atom

2.2.1 ProxyURI

Whether /feed/entry/id (URI-P) should be resolvable or non-resolvable remains an open issue.

2.3 ORE User Guide - HTTP Implementation and Multiple Serializations

2.3.1 Use Information and Non-information Resource Terminology

Is is correct and/or helpful to use the information resource and non-information resource terminology when describing implementation strategies? Does the type of A-1 change depending on implementation choice?

2.3.2 hash rem or hash aggregation

The #rem approach to identify the Resource Map leads to clean references to the Aggregation without creating a second URI (once fragment identifier is removed) that must resolve. Another option would be to suggest that in this case A-1 and ReM-1 should be completely different URIs (neither with a fragment identifier). Say A-1 = and ReM-1 = ReM-1 must return the Resource Map as described and A-1 should also return a Resource Map (though not necessarily exactly the same one) or some other format with enough information to lead a client to ReM-1. Yet another option would be use a fragment identifier for the Aggregation instead of for the Resource Map. This approach leads to ugly URIs for the Aggregation (which we expect to be linked to) but does provides cleaner migration path from the hash-approach to a Cool URI approach (can assert foo owl:sameAs foo.xml#aggregation when new foo URI for Aggregation is created).

2.4 ORE User Guide - Resource Map Discovery

2.4.1 Indirect Knowledge Examples

The examples in sections 3.1 and 4.1 below show URI-R for the value of link/@href and "resourcemap" for the value of link/@rel. It would be more in line with the data model (but perhaps less intuitive) to instead have URI-A and "", respectively.

2.4.2 Indirect Knowledge

Indirect knowledge was conceived as a method for Aggregated Resources to be "ORE aware" but without the maintenance of keeping track of Aggregation(s). Instead, the goal is for the various Aggregated Resources to keep track of just a single Aggregated Resource (most likely a "splash page"), which then in turn keeps track of the associated Aggregation(s). However, it can lead to false assertions if one is not careful. Consider ReM-1 which describes Aggregation A-1, which aggregates {AR-1, AR-2, AR-3}. AR-1 is the splash page and links to ReM-1. AR-2 and AR-3 indirectly link to ReM-1 via AR-1. Now consider ReM-2 which describes Aggregation A-2, which aggregates {AR-1, AR-2}. If AR-1 is updated to link to ReM-2, then AR-2's indirect assertion is true (AR-2 is aggregated by AR-1 and AR-2), but AR-3's indirect assertion is not true (AR-3 is aggregated only by AR-1, not AR-2). The community must decide if the potential utility of indirect knowledge is worth more than the potential confusion caused by incorrect assertions.

2.4.3 Links in HTML pages

HTML does not provide appropriate attributes in the A and IMG elements to link to a Resource Map as well as the target resource. This section suggests either the addition of extra attributes to the A and IMG elements (which would make otherwise valid HTML documents invalid), or re-purposing an existing attribute.

2.5 ORE Specification - Representing Resource Maps Using RDF Syntaxes

2.5.1 Choice of RDF XML Profile

Should this specification say:

2.5.2 Additional Relationships in RDF XML

Need description of how to include Additional Relationships in the Resource Map.

2.5.3 RDFa Examples

Need fuller description of RDFa, examples?

2.5.4 RDFa Example URIs

Add some examples of URIs in RDFa.

2.5.5 Additional Relationships in RDFa

Need description of how to include Additional Relationships in the Resource Map in RDFa.

A. Acknowledgements

This document is the work of the Open Archives Initiative. Funding for Open Archives Initiative Object Reuse and Exchange is provided by the Andrew W. Mellon Foundation, Microsoft, and the National Science Foundation.  Additional support is provided by the Coalition for Networked Information.

This document is based on meetings of the OAI-ORE Technical Committee (ORE-TC), with participation from the OAI-ORE Liaison Group (ORE-LG).  Members of the ORE-TC are: Chris Bizer (Freie Universität Berlin), Les Carr (University of Southampton), Tim DiLauro (Johns Hopkins University), Leigh Dodds (Ingenta), David Fulker (UCAR), Tony Hammond (Nature Publishing Group), Pete Johnston (Eduserv Foundation), Richard Jones (Imperial College), Peter Murray (OhioLINK), Michael Nelson (Old Dominion University), Ray Plante (NCSA and National Virtual Observatory), Rob Sanderson (University of Liverpool), Simeon Warner (Cornell University), and Jeff Young (OCLC).  Members of ORE-LG are: Leonardo Candela (DRIVER), Tim Cole (DLF Aquifer and UIUC Library), Julie Allinson (JISC), Jane Hunter (DEST), Savas Parastatidis  (Microsoft), Sandy Payette (Fedora Commons), Thomas Place (DARE and University of Tilburg), Andy Powell (DCMI), and Robert Tansley (Google, Inc. and DSpace)

We also acknowledge comments from the OAI-ORE Advisory Committee (ORE-AC).

B. Change Log

Date Editor Description
2008-04-03 simeon public alpha 0.3 release
2008-03-02 simeon public alpha 0.2 release
2007-12-10 simeon public alpha 0.1 release

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Use of this page is tracked to collect anonymous traffic data. See OAI privacy policy.