It seems to me that Google's lack of support for OAI 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 OAI will never be a mainstream Web protocol,
but so what... I think we spotted that anyway!
There are technical reasons why OAI 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. SWAP. OAI-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!
:-)
Andy
--
Head of Development, Eduserv Foundation
http://www.eduserv.org.uk/foundation/
http://efoundations.typepad.com/
[log in to unmask]
+44 (0)1225 474319
> -----Original Message-----
> From: Repositories discussion list
> [mailto:[log in to unmask]] On Behalf Of Paul Walk
> Sent: 02 May 2008 11:53
> To: [log in to unmask]
> Subject: Re: Google, OAI and the IRs
>
> Hi David,
> I partly agree with your first point - in terms of
> straightforward search, Google clearly dominates and is, for
> many, good enough.
> However it seems to me that there are, potentially, other
> services which might be offered on the basis of a 'scholarly
> information ecosystem', which Google for example are less
> likely to want to offer.
> If repositories are viewed as content management systems, or
> in the case of institutional repositories as 'asset'
> management systems, then we can begin immediately to think of
> archiving/preservation, of workflow, of showcasing &
> marketing, of trend/gap analysis and 'community
> intelligence'. I guess I believe that an emphasis on
> 'discovery' through search might tend to obscure other
> potentially valuable aspects of the repository network.
>
> There have been varied reactions to the story on Google
> withdrawing support for Sitemaps based on OAI-PMH targets. I
> blogged about this briefly - the comments which were made on
> my post represented some of this variety [1].
>
> Regarding your second point - I tend to agree more strongly.
> One vision for the future is that we increasingly deal with
> information overload by allowing our networks of trusted
> individuals to filter, recommend, distill etc. the flow of
> information. This has been happening in some form for ever,
> of course, but the systems supporting 'social networks' are
> getting rapidly better and are finding their way into many of
> our 'workflows'.
>
> [1]
> http://blog.paulwalk.net/2008/04/23/google-gives-up-on-support
> ing-oai-pmh-for-sitemaps/
>
> Cheers,
>
> Paul
>
>
> On 2 May 2008, at 11:19, David Kane wrote:
> > Hi Santy,
> >
> > My perspective on this is that the repository service model
> just has
> > not taken off. I think the hope was that digital
> repositories might
> > have formed the basis for some kind of scholarly 'information
> > ecosystem' but this hasn't happened. This may be partly due to the
> > presence of Google which, although it does a fantastic job,
> does make
> > people less likely to adopt other search strategies. The
> repository
> > service model won't take off in the future either, at least
> not on its
> > own. It is based on an old indexing paradigm, which alone does not
> > deal with the 21st century problem of information overload.
> >
> > What's going to happen, I think, is that people are
> increasingly going
> > to discover relevant scholarly information through social
> networks in
> > the future.
> >
> > Cheers
> >
> > David.
> >
> >
> >
> > 2008/5/2 Santy Chumbe <[log in to unmask]>:
> >> Phil,
> >>
> >> Are you surprised to learn that Google's reason to no
> longer support
> >> OAI harvesting is that "the information we gain from our
> support of
> >> OAI- PMH is disproportional to the amount of resources required to
> >> support it"?
> >>
> >> I wonder what the amount of resources invested by our
> institutions to
> >> harvest & normalize IR metadata via OAI is.
> >>
> >> Sitemaps was one of the few ones if not the last Google
> product to be
> >> offering OAI support.
> >>
> >> Santy
> >>
> >
> >
> >
> > --
> > David Kane
> > Systems Librarian
> > Waterford Institute of Technology
> > http://library.wit.ie/
> > T: ++353.51302838
> > M: ++353.876693212
>
>
> --------------------------------------------
> Paul Walk
> Technical Manager
> UKOLN (University of Bath)
> http://www.ukoln.ac.uk/
> [log in to unmask]
> +44(0)1225383933
> --------------------------------------------
>
|
