« Inside out - symposium update | Main | FRBR & "Time-Based Media", Part 1 »

May 02, 2008

SWAP and ORE

There's an interesting mini-thread on the jisc-repositories list, started by the announcement by Google to drop support for OAI-PMH which Paul Walk blogged recently.

I reproduce my contribution here, partly because I haven't been blogging much lately and it seems a shame to waste the text :-) and partly because email messages have a tendency to disappear into the ether.

It seems to me that Google's lack of support for the OAI-PMH is largely a non-event - because their support for it was (ultimately) a non-event.  They never supported it fully in any case AFAIK and, in some cases at least, support was broken because they didn't recognise links higher in the server tree than the OAI base URL.

It highlights the fact that the OAI-PMH will never be a mainstream Web protocol, but so what... I think we spotted that anyway!

There are technical reasons why the OAI-PMH was always going to struggle (I say that only with the benefit of hindsight) because of its poor fit with the Web Architecture.  Whilst I don't suppose that directly factored into Google's thinking in any sense, I think it is worth remembering.

On the 'social' thing I very strongly agree and I've argued several times in the past that we need to stop treating stores of content purely as stores of content and think about the social networks that need to build up around them.  It seems to me that the OAI-PMH has never been a useful step in that direction in the way that, say, RSS has been in the context of blogging.

Simple DC suffers from being both too complex (i.e. more complex than RSS) and too simple (i.e. not rich enough to meet some scholarly functional requirements).  Phil Cross suggests that we need to move towards a more complex solution, i.e. SWAPOAI-ORE takes a different but similar step in the direction of complexity - though it is probably less conceptually challenging that SWAP in many ways.  ORE's closeness to Atom might be its saving grace - on the other hand, it's differences to Atom might be its undoing.  Come back in 3 year's time and I'll tell you which! :-)

I like SWAP because I like FRBR... and whenever I've sat down and worked with FRBR I've been totally sold on how well it models the bibliographic world.  But, and it's a very big but, however good the model is, SWAP is so conceptually challenging that it is hard to see it being adopted easily.

For me, I think the bottom line question is, "do SWAP or ORE help us build social networks around content?".  If the answer is "no", and I guess in reality I think the answer might well be "no", then we are focusing our attention in the wrong place.

More positively, I note that "SWAP and ORE" has quite a nice ring to it! :-)

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8345203ba69e200e55220d40b8834

Listed below are links to weblogs that reference SWAP and ORE:

Comments

I strongly agree that the "social" dimension of the research activity is one which we've historically under-estimated in the development of our "repository" services, and one which we need to examine further and support/facilitate in our services.

I'm not sure that "do SWAP or ORE help us build social networks around content?" is really the "bottom line" question though.

Isn't "blaming" SWAP or ORE for the absence of a social aspect to the way we surface research resources a bit like saying, "I want to make more friends. Learning to cook properly isn't making me any friends. I should stop cooking good meals for myself"?

OK, it's not a good analogy, but you get the idea! :-)

Couldn't it be true that we need metadata - and in some cases moderately complex metadata, whether based on SWAP or ORE or other models/schemas (though yes, I totally agree we need to be careful to avoid creating more complexity than we need) - in order to address certain specific problems related to the resources we are managing/disclosing (whether those are problems around 'versioning' (SWAP) or 'composition' (ORE)) _and_ we _also_ need to develop the social dimension?

And indeed the former may contribute to the latter: if part of my "identity" in a "research social network" is related to the various materials I produce ("you're the bloke who co-wrote that DCAM bobbins"), it seems to me it's pretty important that we get those Work-Agent relationships sorted out?

And ideally there's a sort of "virtuous circle" between the two aspects.

I'm not sure this is a good comparison, but look at services like Last.fm http://www.last.fm/ and Discogs http://discogs.com/ both of which have a strong social dimension, but both of which also depend heavily on the provision of moderately complex metadata.

In the case of Last.fm much of the process of metadata provision is hidden from the casual user because it is reusing metadata from global services like Gracenote/CDDB (though many times I've submitted metadata for CDs which weren't recognised).

But on Discogs, many users manually create very complex metadata, way, way more detailed than SWAP - and that metadata supports the social network ("Oooh, you've got that release of xyz on some now defunct label") and the existence of the social network in turn encourages the development of accurate metadata.

Now sure, there are all sorts of contextual and motivational differences that separate musical subgenre trainspotters from overworked academic researchers, and there are a lot of lessons still to be learned about how metadata is created and reused effectively.

But I'm really not sure that the requirement to develop a social aspect to our services - which as I say, I strongly agree with - is an argument for abandoning the provision of metadata which supports other (necessary) requirements and functions - and which may turn out to complement - or indeed be a prerequisite for - the development of the social dimension.

The comments to this entry are closed.

About

Search

Loading
eFoundations is powered by TypePad
http://efoundations.typepad.com/efoundations/2008/05/swap-and-ore.html
efoundations.typepad.com
crawl=CC-MAIN-2017-22
34137
application/http; msgtype=response
sha1:RT7NIV2JCKR324EYGDGL2A43ZOYGB2SX
<urn:uuid:bda58a31-38d8-4867-9fe4-a5b29bbee14b>
2017-05-29T03:44:28Z
104.16.105.123
application/xhtml+xml
sha1:K77NEAAMCPXEUG6NVZYXE55FNLMGVWTL
<urn:uuid:8f4881dc-0fbb-42ec-94ba-7ce781fa8386>
http://efoundations.typepad.com/efoundations/2008/05/swap-and-ore.html
response
<urn:uuid:e57e9580-4a83-489d-af86-eda9d69cd056>
robots: classic
hostname: ip-10-185-224-210.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2017-22
operator: Common Crawl Admin
description: Wide crawl of the web for May 2017
publisher: Common Crawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf