ORE and POWDER Comparison Table

[tonyh]

Hi:

(Am just posting this here for those who may not have seen the
CrossTech blog earlier.)

This comparison table for ORE and POWDER (together with sitemaps as a
ground reference) might be of some interest:

A Comparison of Description Mechanisms for URI Collections [1]

I blogged about this here [2] on CrossTech and posted a couple follow-
ups [3,4].

Be interested in any feedback - either privately, to the Groups list
or on the blog.

Cheers,

Tony


[1] http://tinyurl.com/5bcsuy
<http://nurture.nature.com/tony/blogs/crosstech/ore-pwdr.html>

[2] http://tinyurl.com/5p3frc
<http://www.crossref.org/CrossTech/2008/12/
describing_resource_sets_ore_v_1.html>

[3] http://tinyurl.com/6o5677
<http://www.crossref.org/CrossTech/2008/12/
resource_maps_encoded_in_powde.html>

[4] http://tinyurl.com/5ppbwl
<http://www.crossref.org/CrossTech/2008/12/
orepowder_remarks_on_ratings.html>

[Robert Sanderson]

Hi Tony,

Very nice table. I think it spells out the basic comparison very clearly.

I do (of course) think that some of the descriptions of ORE are unnecessarily harsh or restrictive, though.

Audience:  I don't think that ORE's audience is any less general than POWDER.  We made the hard choice to NOT talk about compound digital objects at all in the specification, but to leave it open to any sort of collection of URI-identified resources.

Learning Curve:  POWDER has an abstract data model (eg in their formal methodology), and ORE has a non RDF based binding (Atom).  Once you've built POWDER-S, you have the same situation as ORE with the number of possible RDF serialisations.  I'm not sure why ORE counts as high, but POWDER as medium/high?

Serializations:  As above.

Cons:  No exclusions applies to the protocol-based identifiers for aggregations?  This was a hard choice, and one made for practical reasons ... If you find the URI for an aggregation (eg someone has cited it)  and it's NOT protocol based, then you can't dereference it and get a description of what that thing is.  Yes, the DOI route of a resolver is one method, but goes very much against the distributed web principles of non-centralization... we don't want to (and don't have the money, expertise or commitment) to run such a resolver indefinitely.  We also think it would have been a large barrier to entry, as it means buying into the resolver system rather than just getting on and doing it.

Secondly, I find it a very large con for POWDER that you can't refer to the set of resources independently of the description documents.  Once you've done the POWDER-S transformation you have many documents all describing the same set of resources.  ORE has a URI that identifies that abstract set (the aggregation's URI) in addition to the ones that identify the serializations (the resource maps' URIs).


Is this a fair comment, or too biased?

Rob

[tonyh]

Hi Rob:

Many thanks for the comments here (and also on the blog).

Let me attempt to defend some of calls in the table:

1. Audience. Agree with this. What I was just trying to do was to
indicate the primary audience (and origin) to give a flavour of the
initiative. I think the table should retain the primary audience (and
hence arising from OAI rather than W3C, or other), but also indicate
that it has wider application.

2. Learning Curve. ORE defines primarily an abstract model and puts
out user guides for illustrative serializations. Of course, POWDER
also has an abstract model but it defines explicitly two canonical
bindings (XML and PDF/OWL), with the intention being that user's would
largely generate the XML version and a POWDER processor would bump
that up to RDF/OWL. So a fixed binding is used in POWDER, either RDF/
OWL directly or as implied by the XML. (Note that a data provider does
not need to generate or understand the RDF/OWL - they would usually
put out a simple XML description and leave it at that.)

The bindings in ORE are not canonical nor equivalents, but are
alternates. If anything, the RDF/XML presents a clear standalone
description, whereas RDFa is a carrier format which piggy backs ORE on
top of XHTML. (The Atom format is somewhere in between - I rather feel
it was press-ganged into service.) Both Atom and RDFa have extra cruft
which does make it difficult to see the woods for the trees.

So, an unencumbered description of ORE is best delivered in RDF/XML
but folks gripe about it so much because of namespaces, and the
various abbreviated syntaxes it allows. A simple bespoke XML might
have made ORE clearer - like, erm, a POWDER enconding. (By the way,
would be great to get some feedback on my attempts in that
direction.)

3.Serializations. (See above.)

4. Cons (ORE) - "exclusions". I think you might have got hold of the
wrong idea here. What I meant was just that POWDER through its funky
pattern-based rules can stipulate which resources are "in" the
collection and which are "out" (cf. the include/exclude tags). I think
ORE which is essentially applied RDF and thus occupies itself with
open world semantics cannot (or does not) support this directly. (Or
maybe I'm being an ass here? Do rdf:Collection's fit in right here to
close off the set? Still doesn't allow one to say what's not in the
set.)

5. Cons (POWDER) - "naming". Er yes, I could see that as a "con" for
POWDER, although it is somewhat beyond its remit. In a sense the
POWDER approach is similar to using a blank node for the resource
bundle (or aggregation), whereas ORE uses a named node for the
aggregation. Naming is an expensive operation, something which should
be undertaken for collections of importance which may have a
durability, and something which should not be attempted for nonce
groupings.

I'll update the table with points #1 and #5. Need to think more about
#2/#3 and whether I am really being too harsh.

Cheers,

Tony

> On Sat, Dec 6, 2008 at 4:20 PM, tonyh <tony.hamm...@gmail.com> wrote:
>
> > Hi:
>
> > (Am just posting this here for those who may not have seen the
> > CrossTech blog earlier.)
>
> > This comparison table for ORE and POWDER (together with sitemaps as a
> > ground reference) might be of some interest:
>
> >    A Comparison of Description Mechanisms for URI Collections [1]
>
> > I blogged about this here [2] on CrossTech and posted a couple follow-
> > ups [3,4].
>
> > Be interested in any feedback - either privately, to the Groups list
> > or on the blog.
>
> > Cheers,
>
> > Tony
>
> > [1]http://tinyurl.com/5bcsuy
> > <http://nurture.nature.com/tony/blogs/crosstech/ore-pwdr.html>
>
> > [2]http://tinyurl.com/5p3frc
> > <http://www.crossref.org/CrossTech/2008/12/

> > describing_resource_sets_ore_v_1.html<http://www.crossref.org/CrossTech/2008/12/describing_resource_sets_or...>

>
> > [3]http://tinyurl.com/6o5677
> > <http://www.crossref.org/CrossTech/2008/12/

> > resource_maps_encoded_in_powde.html<http://www.crossref.org/CrossTech/2008/12/resource_maps_encoded_in_po...>

>
> > [4]http://tinyurl.com/5ppbwl
> > <http://www.crossref.org/CrossTech/2008/12/

> > orepowder_remarks_on_ratings.html<http://www.crossref.org/CrossTech/2008/12/orepowder_remarks_on_rating...>

[Herbert van de Sompel]

Tony

Thanks for this thorough work. In addition to Rob's comments, which I largely agree with, I have the following:

1. Although ORE and POWDER play in a similar problem space, I think they come at the "resource set" problem from quite a different angle. To me, this suggests they are not really trying to solve the same problem. POWDER focuses on capabilities to assert (via ``Description Resources'') that a group of resources share certain properties (e.g. access rights), rather than asserting arbitrary properties about resources that, for
some reason, are grouped into an aggregation. That is, in POWDER the notion of shared properties defines an aggregation, whereas in OAI-ORE an aggregation can be created for any reason deemed important by its creator.

2. Naming: This is a core distinction between ORE and POWDER, and I think it is directly related to (1) above. Since ORE is about reuse, and since one can't do a lot with this regard in the Web without naming the "to be reused" (cf. also Rob's comments with this regard), ORE does indeed start with naming an aggregation of resources by means of URI-A. To put it differently: the URI that is minted for an aggregation of resources is the defining factor in ORE. In POWDER, the defining factor are the properties shared by a set of resources; there is no real need to introduce a name for that set of resources. In the same way that you suggest one can't hold it against POWDER that it doesn't introduce a URI for a set of resources (beyond its remit), one can't hold it against ORE that it does (at the core of its remit).

3. Regarding the choice for protocol-based URIs (read HTTP) for URI-A: as Rob indicates, this was not an easy choice, but it is a pragmatic one directly inspired by the directions taken by the Linked Data people. Because of the pragmatic choices these people made, a Data Web is finally emerging, after many years of sterile semantic web activities. Note that in the non-protocol-based DOI world that you know very well, an HTTP URI (http://dx.doi.org/...) is also introduced to ... err ... make things really work.

4. Staying with DOIs:
(a) None-protocol-based URIs can be conveyed: note that ORE introduces the ore:similarTo relationship to allow relating the Aggregation (identified by HTTP URI-A) to resources that are "similar" (including "similar" resources identified by non-protocol-based URI). This can be used e.g. in the DOI case.
(b) Agreed that minting and maintaining URIs is an expensive proposition. Fortunately, in the DOI case you already have the omnipresent http://dx.doi.org/... that can be used as the HTTP URI for an Aggregation. Have a look at the ORE HTTP Guide, especially <http://www.openarchives.org/ore/1.0/http#MultiSplash> for details.
 
5. Learn curve, serializations: In my opinion, your justifications with this regard are too subtle to justify the differences in evaluations. In ORE, we have tried to build on existing technologies where possible, and so we have chosen to build on existing serialization formats (RDF/XML, RDFa, Atom) instead of introducing Yet Another Homemade Format. IMO, that lowers the learning curve. In the non-RDF realm, I see the use of Atom as a pro, given its growing adoption, and the possibilities this choice offers for ORE applications that leverage the Atom Publishing Protocol. Given the "reuse" remit of ORE this is rather important.

6. Regarding your POWDER-based serialization of ORE: Yes, the XML looks right, understanding you are trying to express ORE in POWDER.  But your serialization also illustrates quite clearly that ORE and POWDER are different beasts. Let's presume ORE does not exist, and that one follows the POWDER "spirit": in this case one would not put the URI-A of the Aggregation in <descriptorset> (for the simple reason that it does not exist, and POWDER itself does not introduce it) but rather the URIs of the Aggregated Resources would go in there. And then, one would take it from there, expressing the shared properties of those Aggregated Resources. And, back in ORE world now, the only shared property we are sure these resources have is that they belong to a same Aggregation. Which kind of would turn the POWDER serialization approach upside down.

Cheers

Herbert

--
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/

[tonyh]

Hi Herbert:

Masterful response.

Ad #1, #2. Yes, I agree. I think this key distinction (naming) is
borne out in the name ORE which describes its business as being about
"Objects" (which generally have an id property) and
"Reuse"/"Exchange" (which implies there is a "handle" to reference the
object.).

So, that's all on track then. :)

But what POWDER brings to the party is its powerful facility for
constructing aggregations. This is a *big* thing. And to be fair,
something (grouping resources) that was on the ORE radar early on but
was judged premature for inclusion in the published spec. POWDER is
not a replacement for ORE as you rightly point out. Nor is ORE a
replacement for POWDER. But that ease of constructing resource groups
is fascinating.

POWDER has pros and cons wrt describing resource groups. Both an
advantage and a disadvantage is its restriction to simple property
values - no compound types allowed. This is simple for implementers at
the expense of any fuller expressivity. The other thing that POWDER
recognizes explicitly is the use of freestanding "tags" as descriptors
as compared to controlled vocabs (RDF schemas). Of course, they can be
rendered in RDF/XML but not as simply (i.e. desisions will have to be
made as to how to represent them).

I mentioned Collections in my reply to Rob. I think that could be
interesting. (Will post separately.)

Ad #3. I still don't buy this. That's a choice ORE made which allows
URI-A -> URI-R. The Linked Data folks are concerned primarily with URI-
R. This

"A URI-A MUST be a protocol-based URI. However, an Aggregation is a
conceptual construct, and thus it does not have a Representation."

is IMHO a bit silly. I really don't like the HTTP shenannigans to get
a URI-R from a URI-A. That's anyway my opinion. (Sure I'll be hung out
on the heretic hook.)

And, while in practice dx.doi.org is the central resolver for DOI
resolution, it really needn't be. (That partly comes about from
worries about a practical logistics, worry about link dilution, etc.)
In another architecture dx1.doi.org, dx2.doi.com, dx3.doi.net could
all present a uniform resolution layer since there is an HTTP/HDL
interface undelrying the DOI resolution. Doesn't matter what handle
gateway one uses, but a resolution request would be forwarded
transparently.

Ad #4a) Yes, but I still don't like the restriction on aggregation
naming (which is the USP for ORE) and, of course, this introduces more
clutter and need for maintenance.

Ad #4b) Yes, but we'll need to think about that. We have made a
consistent effort over the years to distinguish http://dx.doi.org/...
from doi:... and then ORE steps in and says what it says. We'll see
about this. It creates more problems than it solves I believe
(restrictions on URI-A for discovery of URI-R).

Ad #5. I'll beg to differ. I do take your point about reusability
seriously. I don't think Atom was a great example to use. A first cut
might have looked at a profile of RDF/XML which would have none of the
application semantics that Atom has. Still, it's great that Atom is
there and can be mapped to.

Ad #6. The first thing to note is that ORE can (as far as I am aware)
be modelled using POWDER. It is less intimidating than vanilla RDF/XML
because there is a prescription (schema) for how it should be done.
Also it looks less intimidating because it uses default namespace - so
less namespaces to contend with. (RDF/XML mandates all elements/
attributes be namespaced - so less than human friendly.)

And, more importantly, the real reason for considering a POWDER
serialization (less we forget) is the facility for constructing
complex resource sets with a handful of basic elements - alright, then
11 (+11) of 'em :). But that is still a very intriguing propsect for a
publisher of complex digital objects. This is something that ORE
lacks.

So yes, ORE has got lots going for it. POWDER's also got some cute
aspects. Can one leverage any of those in ORE descriptions?

Cheers,

Tony

> Fortunately, in the DOI case you already have the omnipresenthttp://dx.doi.org/... that can be used as the HTTP URI for an Aggregation.

> > describing_resource_sets_ore_v_1.html<http://www.crossref.org/CrossTech/2008/12/describing_resource_sets_or...>

>
> > [3]http://tinyurl.com/6o5677
> > <http://www.crossref.org/CrossTech/2008/12/

> > resource_maps_encoded_in_powde.html<http://www.crossref.org/CrossTech/2008/12/resource_maps_encoded_in_po...>

>
> > [4]http://tinyurl.com/5ppbwl
> > <http://www.crossref.org/CrossTech/2008/12/

> > orepowder_remarks_on_ratings.html<http://www.crossref.org/CrossTech/2008/12/orepowder_remarks_on_rating...>