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 = http://example.org/bar.xml and ReM-1 = http://example.org/foo.xml. 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 "http://www.openarchives.org/ore/terms/isAggregatedBy", 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:

• Where an ORE Resource Map is serialised using RDF/XML, this profile of RDF/XML MUST be used; or
• Where an ORE Resource Map is serialised using RDF/XML, any of the conventions supported by the RDF/XML specification MAY be used; this profile is provided primarily as a guideline for Resource Map providers who are not familar with the RDF/XML format.

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.