[Ore-acceleration] RE: An article has been posted to OAI-ORE

[Herbert Van de Sompel]

hi all,

the blog is currently temperamental, so I share the below via email, and 
will post to the blog later.

cheers

herbert

==

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:

Resource Map
Component resource

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 
re Target/Origin.

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 
resource (Tre)

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" 
resource (resource).

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 
contextualized resource.

e.      MAY, if not  explicitly defined ,be inferred by the client via 
protocol-defined mechanisms.



-- 
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
tel. +1 505 667 1267
-------------- next part --------------
A non-text attachment was scrubbed...
Name: option4.rtf
Type: text/rtf
Size: 2614 bytes
Desc: not available
Url : http://www.openarchives.org/pipermail/ore-acceleration/attachments/20070829/9f7346da/option4.bin