OAI-ORE and other compound/complex digital object standard

[majxster]

I'm interested in the standard of compound/complex digital object.
But I'm confused with the relationship between METS, DIDL, SCORM and
OAI-ORE. Is there someone can tell me the differences and the common
ground between them? Thanks.

[Jerome]

Since it would be all too easy to write a book on this, I'm going to
intentionally try to be as bullet-pointy as possible on this, and
people can feel free to correct/flesh out/add to this as they see fit:

Common Ground:

* All XML based.
* All intended to support exchange/interoperability of complex content
objects between different systems.
* All based on the idea that complex content objects can be modeled as
a hierarchy, with differing bits of content/metadata associated with
different nodes in the hierarchical structure.
* All of them are derivatives of the old HyTime notion of a hub
document, where a root XML file serves as the 'hub' for a surround
wheel of linked content and metadata files.
* All can be easily used in conjunction with content files in a
variety of data formats (text, still image, audio, video).
* All can be easily be used in conjunction with metadata of varying
types.

Differences:

* Starting with the big one: differing communities of practice. METS
emerged out of the Digital Library Federation and its biggest users
and proponents are digital library operations associated with major
research libraries. SCORM is a product of the eLearning community.
DIDL is an MPEG product, with strong interest from the commercial
sector interested in moving image distribution (television industry,
cable industry). OAI-ORE is the most mixed in terms of communities
participating in its development, drawing from eLearning, DL, data
curation, publisher and commercial agencies with a strong interest in
web content management.
* Some slight differences in approaches to implementing the
hierarchical structure which forms the basis of associating content/
metadata. METS and OAI-ORE don't attempt to draw any significant
distinctions between the different levels of their basic tree
structure; DIDL does (Container/item/component), and SCORM draws at
least a two-level distinction of organization/item.
* Differences in terms of trying to impose their own specific semantic
labels on metadata. DIDL and OAI-ORE for try to avoid this. METS
clearly tries to put metadata into its own semantic buckets
(descriptive, technical, intellectual property, provenance), a
property it shares with SCORM which imposes LOM semantics (lifeCycle,
educational, rights, classification) while allowing for extensions in
those categories.
* Differing expectations for processing. SCORM is more than just its
Content Aggregation Model, and the requirements imposed by its Run
Time Environment and Sequencing and Navigation specs have a
significant impact on how the SCORM CAM can actually be used. METS
has assumed a web services like processing environment, but nowhere
near as well defined as what SCORM sets out, and quite a bit of effort
was made to try to insure that this assumption did not impact content/
metadata structuring. DIDL and OAI-ORE are both more circumspect on
the software environment which will process DIDL and OAI-ORE content/
metadata, although clearly in OAI-ORE we have a pronounced web bias.

[Terry Catapano]

One quibble: OAI-ORE is not *based* on XML, but rather has a specified RDF/XML serialization. To be processed as *OAI-ORE* (triples, graphs, etc...), the RDF/XML syntax needs to be processed as RDF, not as just XML; i.e., according to the RDF/XML Syntax Specification (http://www.w3.org/TR/rdf-syntax-grammar/). This isn't the same as METS, for example, which is based on XML to the extent that it doesn't formally specify how to construe the XML markup.

At least I think this is right.

/Terry

PS: I for one wish that Jerry would go ahead and write the book on this.

[Jerome]

Duly noted, but the point I was trying to make is that all three OAI-
ORE serializations are based upon XML. And whatever processing gets
done will be done as XML first, RDF second. So, all of the content
packaging standards put you in the land of XML tools for parsing,
validating, editing, transformation, etc., which is actually a good
place to be.

I have to raise my own quibble though. There will be a lot of
processing of OAI-ORE documents in all serializations that will
happily ignore the fact that it's RDF as not relevant to the task
being accomplished, e.g., display.

As for telling people how to construe the markup, if you think the OAI-
ORE spec really tells people that, wait until you see how people
decide to interpret OAI-ORE once it gets outside the confines of the
standards group. The "similar to" relationship should be particularly
fun to see applied in practice. Voice of experience speaking
here. :)

On Nov 21, 11:43 am, "Terry Catapano" <catapan...@gmail.com> wrote:
> One quibble: OAI-ORE is not *based* on XML, but rather has a specified
> RDF/XML serialization. To be processed as *OAI-ORE* (triples, graphs,
> etc...), the RDF/XML syntax needs to be processed as RDF, not as just XML;
> i.e., according to the RDF/XML Syntax Specification (http://www.w3.org/TR/rdf-syntax-grammar/). This isn't the same as METS, for
> example, which is based on XML to the extent that it doesn't formally
> specify how to construe the XML markup.
>
> At least I think this is right.
>
> /Terry
>
> PS: I for one wish that Jerry would go ahead and write the book on this.
>

[Mark Diggory]

I'm wary of the example serialization of ORE to RDF/XML as explicitly
dictating that any RDF serialization of ORE is required to be RDF/
XML. It is simply the format used in the documented example. It may
be the case when embedding RDF/XML into Atom. But I most certainly
do not see any benefit to suggesting that an ORE aggregation being
requested directly as RDF need be in any serialization format other
than that which the server supports and the client can request (i.e.
via accepts headers etc). RDF parsing/serialization tools generally
support multiple formats and its best that ones application not be
designed to expect one format (RDF/XML) explicitly.

There are guidelines for working with RDF in that SW/LoD that explain
how content renegotiating and Accepts headers should be applied to
control the selection of the appropriate representation of a resource
serialized to the client. It would behoove one to attempt to work
within these guidelines so ones content can actually be utilized
(that is the goal isn't it?)

Some resources:
http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/
LinkingOpenData
http://linkeddata.org/
http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/

This said, if all your server supports is generating RDF/XML for your
ORE, there is nothing to suggest that you "need" to provide
serialization to other formats if thats all you can support. I just
would advise against creating clients that parse RDF/XML as if its
XML (unlike the expectations one can place on a parser parsing Atom),
RDF/XML allows a great deal of variation depending on how one wishes
to represent ones Descriptions. You have almost no predicability
there, don't ever expect a serialization of an RDF model to RDF/XML
to ever be the same identical XML each time.

I'd recommend making the RDF/XML more generic to RDF in general and
present examples in multiple formats (n3, turtle, rdf/xml). I do
think there is risk that it will be misinterpreted the way that
Jerome suggests.

Cheers,
Mark

~~~~~~~~~~~~~
Mark R. Diggory
http://purl.org/net/mdiggory/homepage

[Terry Catapano]

On Fri, Nov 21, 2008 at 6:50 PM, Jerome <jmcd...@uiuc.edu> wrote:

Duly noted, but the point I was trying to make is that all three OAI-
ORE serializations are based upon XML.  And whatever processing gets
done will be done as XML first, RDF second.  So, all of the content
packaging standards put you in the land of XML tools for parsing,
validating, editing, transformation, etc., which is actually a good
place to be.

Absolutely. Duly noted.

 

I have to raise my own quibble though.  There will be a lot of
processing of OAI-ORE documents in all serializations that will
happily ignore the fact that it's RDF as not relevant to the task
being accomplished, e.g., display.

Yes, there will definitely be LOTS of such processing. I'm tempted to say to say that at that point an OAI-ORE instance is just well formed XML; if it's irrelevant that it's RDF, then it's almost as irrelevant that it's OAI-ORE. But you're making the more valuable and useful point.

 

As for telling people how to construe the markup, if you think the OAI-
ORE spec really tells people that, wait until you see how people
decide to interpret OAI-ORE once it gets outside the confines of the
standards group.  

No, all I'm saying is that the OAI-ORE spec profiles the RDF-XML spec to (attempt to) specify a particular construction of XML syntax. Specifying a construction of XML is something METS (again, for example) doesn't do. However, that the "intent" of any spec, or of any instance, does not determine its use is an notion with which I wholeheartedly agree.
 

The "similar to" relationship should be particularly
fun to see applied in practice.  Voice of experience speaking here.  :)

A voice well worth hearing, indeed.

/Terry