Aggregation/Resource Map relationship question - OAI-ORE

Message from discussion Aggregation/Resource Map relationship question
Received-SPF: pass (google.com: domain of mdigg...@mit.edu designates 18.7.7.80 as permitted sender) client-ip=18.7.7.80;
Mime-Version: 1.0 (Apple Message framework v753)
In-Reply-To: <33e12845-00c9-4b95-9eae-b3d9f3d6706b@26g2000hsk.googlegroups.com>
References: <15c4095c-12ba-4ef4-9865-db0d234d184c@79g2000hsk.googlegroups.com>  <20080814194905.GA1749@ice.cs.cornell.edu> <33e12845-00c9-4b95-9eae-b3d9f3d6706b@26g2000hsk.googlegroups.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8230E87E-5FC2-406A-97E7-FFF35C03713E@mit.edu>
Content-Transfer-Encoding: 7bit
From: Mark Diggory <mdigg...@MIT.EDU>
Subject: Re: Aggregation/Resource Map relationship question
Date: Thu, 14 Aug 2008 19:54:18 -0700
To: oai-ore@googlegroups.com

Interesting topic...

On Aug 14, 2008, at 5:49 PM, Jeff Young wrote:

>
> Thanks for the feedback Simeon. I admit that I need to review AWWW and
> will do so ASAP.
>
> On Aug 14, 3:49 pm, Simeon Warner <sim...@cs.cornell.edu> wrote:
>
>> Well, this is a difference between English and the Architecture of  
>> the
>> World Wide Web [AWWW] document. In English I think one could
>> reasonably say that the Resource Map is a representation of an
>> Aggregation. However, in the language of AWWW there is no bitstream
>> for resource A-1 obtained via content negotiation so no
>> representation.
>
> I can believe that AWWW recognizes the possibility of resources
> without bitstreams, but I will be surprised if it dictates that an RDF
> graph is such a resource. It's difficult to imagine why a set of
> triples can't be a content-negotiable resource.

So, we currently have

http://dspace.mit.edu/handle/1721.1/30972

and it does have content negotiation enabled on it... redirecting RDF  
Browsers now to:

http://dspace.mit.edu/metadata/handle/1721.1/30972/rdf.xml

Which is a representation of the DSpace Item in RDF/XML of type  
ore:Aggregation.

It is named in a ore:ResourceMap identified in the representation as:

http://dspace.mit.edu/handle/1721.1/30972#rem

but it might be more appropriate that the URI on the ore:ResourceMap  
actually be the original

http://dspace.mit.edu/metadata/handle/1721.1/30972/rdf.xml

Likewise, if we did decide to put up a "n3" version of the  
Aggregation we might use

http://dspace.mit.edu/metadata/handle/1721.1/30972/rdf.n3 (non- 
functional)

or if we had an atom version, we might use...

http://dspace.mit.edu/metadata/handle/1721.1/30972/atom.xml (non- 
functional)

The statements which asserted on the RDF Resource represented by  
these URI describe various features of the Map itself rather than the  
Aggregation it is naming. Specifically, creation and modification  
Timestamps and the service which created the entire Resource Map.


>
>> One does get either redirected to resource R-1 from
>> which a representation is available, or -- as a shortcut -- one  
>> gets a
>> represenation of R-1 back with a header saying that is is from R-1  
>> and
>> not from A-1.
>
> It's also hard for me to imagine why an HTTP redirect shouldn't be
> understood as a type of resource representation. I'd have to look
> closer, but I don't recall anything in HTTP/1.1 that undermines this
> interpretation. Maybe AWWW deals with this too. If so, I fear that it
> is splitting hairs that are already too thin and obscure.
>

Interestingly, if you look at the output of the TBL's Tabulator  
extension for Firefox, most of the entire content negotiation request  
interaction is represented in RDF, thus asserting, this negotiation  
of the following request is in fact a capture-able itself as also a  
set of resources.

Cheers,
Mark

~~~~~~~~~~~~~
Mark R. Diggory - DSpace Developer and Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology
Home Page: http://purl.org/net/mdiggory/homepage