[Ore-acceleration] RE: An article has been posted to OAI-ORE
Herbert Van de Sompel
herbertv at lanl.gov
Wed Aug 29 12:50:17 EDT 2007
the blog is currently temperamental, so I share the below via email, and
will post to the blog later.
Michael and I chatted about Carl's 3 architecture options, and we have a
fourth proposal, largely based on Option 3, and the logic underlying it.
The proposal mainly addresses terminology; there are some proposed word
and order changes in our version of the architectural summary, but no
changes are made re the core concepts underlying this all. This version
also proposes revised abbreviations such as Rem instead of ReM, etc.
trying to normalize things.
a. We first consider that there are the following:
1. Aggregated resource / Resource Map
2. Component resource / Component Fragment
We suggest that if we rationalize (1), we can as well rationalize (2)
and end up with:
If there is a need, in a certain spec, to make this more explicit, we
can always do:
Resource Map (serialization)
Resource Map (resource)
Component resource (serialization)
Component resource (resource)
This approach also maps nicely with Atom:
Resource Map ~ Atom feed
Component resource ~ Atom entry
and with the fact that Atom uses "Atom feed" (and "Atom entry") to both
mean the concept and the document, and makes the difference explicit
when it needs to be. which is very rarely; I expect that to be the case
for ORE too.
b. We like the Target resource thing; we would like to rename the
Component resource thing. 2 motivations:
- URI-C as the URI for a COMP is dangerously loaded, as we have used (in
ppts, docs etc URI-C to mean s/t entirely different)
- kind of a boring term; can't do anything with in a popular
explanation. popular explanations are important.
So, we want a term that allows us to use the abbreviation Ore for the
thing. Meaning it would have to start with O because then we can go "O
Resource" => Ore. Why is this good (popular message):
=> Resource Maps are bags of OREs
=> OREs are the tokens/currency for interoperability
=> maps tell you where the OREs are
Terms we came up with: Observing resource, Ornamenting resource (can
even do Orenamenting resource), Overlay resource, Opting resource, Other
resource, Outer resource.
We also came up with Origin resource but thought that would be confusing
Anyhow, here is another take on Carl's architectural list (also attached
as an rtf document):
1. A Resource map (Rem) is a resource that identifies and
describes an aggregation of resources
2. URI-Rem is:
a. The identity for linking, citing, making assertions about the
aggregation of resources as a whole.
b. The URI from which a Rem (serialization) is obtained
c. MUST exist and MUST be protocol-based
3. The Resource map (serialization)
a. MUST include a Manifest (Man)
b. MAY include types and relationships
4. A resource that is aggregated by the Rem is called a Target
a. A Tre MUST be included in the Man of a Rem
5. URI-Tre is:
a. The identity of a Tre, unchanged from its “original identity”
b. MUST exist and MUST be protocol-based
c. Is what is included in the manifest and in all assertions in
the Rem (typing, relationships)
i. Understanding is that all these are contextualized assertions
about Tres, in the context of the Rem
d. The identity for linking, citing, making assertions about the
Tre as a standalone object.
6. An "O" resource (resource) is a resource that identifies and
describes a surrogate for a Tre; the "O" resource (Ore) is a surrogate
for the Tre in the sense that it is a "stand-in" for the Tre in the
context of the aggregation of resources that is identified and described
by the Rem.
7. An "O" resource (serialization) is a description of a "O"
a. The description includes the original URI-Tre with a “ball of URI-R
context” around it. Probably s/t like:
i. The id URI-Tre
ii. The id URI-Rem
iii. Possible metadata
8. URI-Ore is:
a. The identity of the "O" resource.
b. A surrogate URI for a corresponding URI-Tre
i. SHOULD be the linking, citing, making assertions about the Tre
as a contextualized resource
c. MUST be protocol-based
i. MUST provide access to the "O" resource (serialization)
d. SHOULD be explicitly defined and resolved by the author of the Rem
i. In which case clients MUST use it for citation of
e. MAY, if not explicitly defined ,be inferred by the client via
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
tel. +1 505 667 1267
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2614 bytes
Desc: not available
Url : http://www.openarchives.org/pipermail/ore-acceleration/attachments/20070829/9f7346da/option4.bin
More information about the Ore-acceleration