Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-05-03 Thread Eric Hellman

I'll try to find out.

Sent from Eric Hellman's iPhone


On May 2, 2010, at 4:10 PM, stuart yeates stuart.yea...@vuw.ac.nz  
wrote:


But the interesting use case isn't OpenURL over HTTP, the  
interesting use case (for me) is OpenURL on a disconnected eBook  
reader resolving references from one ePub to other ePub content on  
the same device. Can OpenURL be used like that?


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-05-03 Thread Jonathan Rochkind
Here is the API response Umlaut provides to OpenURL requests with 
standard scholarly formats.  This API response is of course to some 
extent customized to Umlaut's particular context/use cases, it was not 
neccesarily intended to be any kind of standard -- certainly not with as 
wide-ranging intended domain as OpenURL's 1.0 intent (which never really 
caught on), it's targetted at standard actually-existing link resolver 
use cases in the scholarly environment.


But, here you go, live even:

http://findit.library.jhu.edu/resolve/api?sid=googleauinit=ABaulast=Milleratitle=Reporting+results+of+cancer+treatmentid=doi:10.1002/1097-0142%2819810101%2947:1%3C207::AID-CNCR2820470134%3E3.0.CO%3B2-6title=Cancervolume=47issue=1date=2006spage=207issn=0008-543X

Json is also available. Note that complete results do not neccesarily 
show up at first, some information is still being loaded in the 
background.  You can refresh the URL to see more results, you'll know 
when the back-end server has nothing left to give you when 
completetrue/complete is present.


Another XML response with embedded HTML snippets is also available (in 
both XML and Json):


http://findit.library.jhu.edu/resolve/partial_html_sections?sid=googleauinit=ABaulast=Milleratitle=Reporting+results+of+cancer+treatmentid=doi:10.1002/1097-0142%2819810101%2947:1%3C207::AID-CNCR2820470134%3E3.0.CO%3B2-6title=Cancervolume=47issue=1date=2006spage=207issn=0008-543X


Ross Singer wrote:

On Fri, Apr 30, 2010 at 10:08 AM, Eric Hellman e...@hellman.net wrote:
  

OK, what does the EdSuRoSi spec for OpenURL responses say?



Well, I don't think it's up to us and I think it's dependent upon
community profile (more than Z39.88 itself), since it would be heavily
influenced with what is actually trying to be accomplished.

I think the basis of a response could actually be another context
object with the 'services' entity containing a list of
services/targets that are formatted in some way that is appropriate
for the context and the referent entity enhanced with whatever the
resolver can add to the puzzle.

This could then be taken to another resolver for more services layered on.

This is just riffing off the top of my head, of course...
-Ross.

  


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-05-03 Thread Karen Coyle

Quoting Jakob Voss jakob.v...@gbv.de:


I bet there are several reasons why OpenURL failed in some way but I
think one reason is that SFX got sold to Ex Libris. Afterwards there
was no interest of Ex Libris to get a simple clean standard and most
libraries ended up in buying a black box with an OpenURL label on it -
instead of developing they own systems based on a common standard. I
bet you can track most bad library standards to commercial vendors. I
don't trust any standard without open specification and a reusable Open
Source reference implementation.


For what it's worth, that does not coincide with my experience.

kc
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-05-03 Thread Bill Dueber
On Mon, May 3, 2010 at 6:34 PM, Karen Coyle li...@kcoyle.net wrote:
 Quoting Jakob Voss jakob.v...@gbv.de:

 I bet there are several reasons why OpenURL failed in some way but I
 think one reason is that SFX got sold to Ex Libris. Afterwards there
 was no interest of Ex Libris to get a simple clean standard and most
 libraries ended up in buying a black box with an OpenURL label on it -
 instead of developing they own systems based on a common standard. I
 bet you can track most bad library standards to commercial vendors. I
 don't trust any standard without open specification and a reusable Open
 Source reference implementation.

 For what it's worth, that does not coincide with my experience.


I'm going to turn this back on Karen and say that much of my pain does
come from vendors, but it comes from their shitty data. OpenURL and
resolvers would be a much more valuable piece of technology if the
vendors would/could get off their collective asses(1) and give us
better data.

 -Bill-

(1) By this, of course, I mean if the librarians would grow a pair
and demand better data via our contracts


-- 
Bill Dueber
Library Systems Programmer
University of Michigan Library


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-05-03 Thread stuart yeates

Bill Dueber wrote:


if the librarians would grow a pair
and demand better data via our contracts


While I agree with your overall point, it would have been better made 
with the gendered phrasing, in my view.


cheers
stuart
--
Stuart Yeates
http://www.nzetc.org/   New Zealand Electronic Text Centre
http://researcharchive.vuw.ac.nz/ Institutional Repository


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-05-02 Thread stuart yeates

Ross Singer wrote:

On Fri, Apr 30, 2010 at 11:52 AM, Mike Taylor m...@indexdata.com wrote:

On 30 April 2010 16:42, Ed Summers e...@pobox.com wrote:

On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer rossfsin...@gmail.com wrote:

Just to clarify -- OpenURL 1.0 does not assume HTTP is being used.

Oh, so that's the problem!

Yes!  Exactly!

Poor old OpenURL 1.0 is abstracted to hell and back.  The sad old
thing doesn't even know what transport it's running on (why?  Because
Abstraction Is Good, not because anyone actually had any reason for
wanting to use a different transport than HTTP), and as a result it
can't assume it has, for example, the ability for the transport to
report errors.



Of course, per Eric's earlier comment, there's no reason why we can't
take what's there and refine it so that there are assumptions like
HTTP and optimize it to actually *work* in such an environment.

Is there?


But the interesting use case isn't OpenURL over HTTP, the interesting 
use case (for me) is OpenURL on a disconnected eBook reader resolving 
references from one ePub to other ePub content on the same device. Can 
OpenURL be used like that?


cheers
stuart
--
Stuart Yeates
http://www.nzetc.org/   New Zealand Electronic Text Centre
http://researcharchive.vuw.ac.nz/ Institutional Repository


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-30 Thread Owen Stephens
Dead ends from OpenURL enabled hyperlinks aren't a result of the standard
though, but rather an aspect of both the problem they are trying to solve,
and the conceptual way they try to do this.

I'd content these dead ends are an implementation issue - and despite this I
have to say that my experience on the ground is that feedback from library
users on the use of link resolvers is positive - much more so than many of
the other library systems I've been involved with.

What I do see as a problem is that this market seems to have essentially
stagnated, at least as far as I can see. I suspect the reasons for this are
complex, but it would be nice to see some more innovation in this area.

Owen

On Thu, Apr 29, 2010 at 6:14 PM, Ed Summers e...@pobox.com wrote:

 On Thu, Apr 29, 2010 at 12:08 PM, Eric Hellman e...@hellman.net wrote:
  Since this thread has turned into a discussion on OpenURL...
 
  I have to say that during the OpenURL 1.0 standardization process, we
 definitely had moments of despair. Today, I'm willing to derive satisfaction
 from it works and overlook shortcomings. It might have been otherwise.

 Personally, I've followed enough OpenURL enabled hyperlink dead ends
 to contest it works.

 //Ed




-- 
Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: o...@ostephens.com


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-30 Thread Kyle Banerjee
 Dead ends from OpenURL enabled hyperlinks aren't a result of the standard
 though, but rather an aspect of both the problem they are trying to solve,
 and the conceptual way they try to do this.

 I'd content these dead ends are an implementation issue.


Absolutely. There is no inherent reason that an OpenURL has to be a plain
text link that must be manually clicked nor is there any requirement that
the resolver simply return an HTML page that may or may not contain plain
text links the user can click on.

An obvious thing for a resolver to be able to do is return results in JSON
so the OpenURL can be more than a static link. But since the standard
defines no such response, the site generating the OpenURL would have to know
something about the resolver.


 What I do see as a problem is that this market seems to have essentially
 stagnated, at least as far as I can see. I suspect the reasons for this are
 complex


I suspect they are simple. The easy part of OpenURL addresses a compelling
use case, but there just isn't that much pressure to take things to the next
level. If people really got that upset about dead links -- and in many
systems this is impossible because you'll be offered ILL fulfillment if no
electronic copy is available -- there would be more incentive to handle
resolution before the user clicks on the link.

In short, you reach a point of diminishing returns with OpenURL very
quickly.

kyle


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-30 Thread Ross Singer
On Fri, Apr 30, 2010 at 7:59 AM, Kyle Banerjee kyle.baner...@gmail.com wrote:

 An obvious thing for a resolver to be able to do is return results in JSON
 so the OpenURL can be more than a static link. But since the standard
 defines no such response, the site generating the OpenURL would have to know
 something about the resolver.

I actually think this lack of any specified response format is a large
factor in the stagnation of OpenURL as a technology.  Since a resolver
is under no obligation to do anything but present a web page it's
difficult for local entrepreneurial types to build upon the
infrastructure simply because there are no guarantees that it will
work anywhere else (or even locally, depending on your vendor, I
suppose), much less contribute back to the ecosystem.

Umlaut was able to exist because (for better or worse) SFX has an XML
output.  It has never been able to scale horizontally, however,
because to work with another vendor's link resolver (which should
actually be quite straightforward) it requires a connector to whatever
*their* proprietary API needs.

I could definitely see a project like Umlaut providing a 'de facto'
machine readable response for SAP 1/2 requests that content providers
could then use to start offering better integration at *their* end.

This assumes that more than 5 libraries would actually be using it, however.

-Ross.


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-30 Thread Ed Summers
On Fri, Apr 30, 2010 at 9:09 AM, Ross Singer rossfsin...@gmail.com wrote:
 I actually think this lack of any specified response format is a large
 factor in the stagnation of OpenURL as a technology.  Since a resolver
 is under no obligation to do anything but present a web page it's
 difficult for local entrepreneurial types to build upon the
 infrastructure simply because there are no guarantees that it will
 work anywhere else (or even locally, depending on your vendor, I
 suppose), much less contribute back to the ecosystem.

I agree. And that's an issue with the standard, not the implementations.

//Ed


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-30 Thread Corey A Harper

Hi All,

Though hesitant to jump in here, I agree with Owen that the dead ends 
aren't a standards issue. The bloat of the standard is, as is the lack 
of a standardized response format, but the dead ends have to do with bad 
metadata being coded into open-URLs and with breakdowns in the 
connection between content aggregators/providers and knowledge base 
maintainers.


Work in this area isn't completely stagnant, though. The joint NISO/UK 
Serials Group's Knowledge Bases And Related Tools working group is 
looking towards solutions to exactly these problems.

http://www.uksg.org/kbart

Their initial report on best practice for content providers and KB 
maintainers is worth a look.


-Corey

Owen Stephens wrote:

Dead ends from OpenURL enabled hyperlinks aren't a result of the standard
though, but rather an aspect of both the problem they are trying to solve,
and the conceptual way they try to do this.

I'd content these dead ends are an implementation issue - and despite this I
have to say that my experience on the ground is that feedback from library
users on the use of link resolvers is positive - much more so than many of
the other library systems I've been involved with.

What I do see as a problem is that this market seems to have essentially
stagnated, at least as far as I can see. I suspect the reasons for this are
complex, but it would be nice to see some more innovation in this area.

Owen

On Thu, Apr 29, 2010 at 6:14 PM, Ed Summers e...@pobox.com wrote:


On Thu, Apr 29, 2010 at 12:08 PM, Eric Hellman e...@hellman.net wrote:

Since this thread has turned into a discussion on OpenURL...

I have to say that during the OpenURL 1.0 standardization process, we

definitely had moments of despair. Today, I'm willing to derive satisfaction
from it works and overlook shortcomings. It might have been otherwise.

Personally, I've followed enough OpenURL enabled hyperlink dead ends
to contest it works.

//Ed







--
Corey A Harper
Metadata Services Librarian
New York University Libraries
20 Cooper Square, 3rd Floor
New York, NY 10003-7112
212.998.2479
corey.har...@nyu.edu


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-30 Thread Eric Hellman
Eek. I was hoping for something much simpler. Do you realize that you're asking 
for service taxonomy?

On Apr 30, 2010, at 10:22 AM, Ross Singer wrote:

 I think the basis of a response could actually be another context
 object with the 'services' entity containing a list of
 services/targets that are formatted in some way that is appropriate
 for the context and the referent entity enhanced with whatever the
 resolver can add to the puzzle.


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-29 Thread MJ Suhonos
 What I hope for is that OpenURL 1.0 eventually takes a place alongside SGML 
 as a too-complex standard that directly paves the way for a universally 
 adopted foundational technology like XML. What I fear is that it takes a 
 place alongside MARC as an anachronistic standard that paralyzes an entire 
 industry. 

Hear hear.

I'm actually encouraged by Benjamin's linking (har har) to the httpRange-14 
issue as being relevant to the concept of link resolution, or at least 
redirection (indirection?) using URL surrogates for resources.  Many are 
critical of the TAG's resolution (har har har) of the issue, and think it 
places too much on the 303 redirect.

I'm afraid I still don't understand the issue fully enough to comment — though 
I'd love to hear from any who can.  I agree with Eric's hope that the library 
world can look to W3C's thinking to inform a better way forward for link 
resolving, though.

Which causes me to wonder whether I should mention some disturbing research 
we're finding within PKP that using identifiers (DOIs, Purls, Handles) for 
resolving resources (notably journal articles) actually *decreases* search 
engine relevance because most link resolvers (including CrossRef) use 302 
redirects instead of 303s, which Google ignores (but some suspect treats as 
spam, and thus demotes the target domain).

Actually, no, I won't mention that.  Carry on.

MJ


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-29 Thread Eric Hellman
Even the best standard in the world can only do so much!

On Apr 29, 2010, at 1:14 PM, Ed Summers wrote:

 On Thu, Apr 29, 2010 at 12:08 PM, Eric Hellman e...@hellman.net wrote:
 Since this thread has turned into a discussion on OpenURL...
 
 I have to say that during the OpenURL 1.0 standardization process, we 
 definitely had moments of despair. Today, I'm willing to derive satisfaction 
 from it works and overlook shortcomings. It might have been otherwise.
 
 Personally, I've followed enough OpenURL enabled hyperlink dead ends
 to contest it works.
 
 //Ed


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-29 Thread Jakob Voss

Eric Hellman wrote:


What I hope for is that OpenURL 1.0 eventually takes a place
alongside SGML as a too-complex standard that directly paves the way
for a universally adopted foundational technology like XML. What I
fear is that it takes a place alongside MARC as an anachronistic
standard that paralyzes an entire industry.


But all the flaws of XML can be traced back to SGML which is why we now 
use JSON despite all of its limitations. May brother Ted Nelson 
enlighten all of us - he not only hates XML [1] and similar formats but 
also  proposed an alternative way to structure information even before 
the invention of hierarchical file systems and operating systems [2]. In 
his vision of Xanadu every piece of published information had a unique 
ID that was reused everytimes the publication was referenced - which 
would solve our problem.


SCNR
Jakob

[1] http://ted.hyperland.com/XMLisEvil.html
[2] Ted Nelson: A File Structure for the Complex, The Changing and the 
Indeterminate, ACM 20th National Conference, pages 84-100, 1965. 
Presented in 1964.


--
Jakob Voß jakob.v...@gbv.de, skype: nichtich
Verbundzentrale des GBV (VZG) / Common Library Network
Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
+49 (0)551 39-10242, http://www.gbv.de


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-29 Thread Boheemen, Peter van
 But all the flaws of XML can be traced back to SGML which is 
 why we now use JSON despite all of its limitations. 
excuse me, but JSON is something completely different. It is an object notation 
and in not at all usable to structure data. XML is great to describe complex 
data, but it is often badly used, like in MARC XML (ISO 2709 described in XML). 
And it is musunderstood by a lot of programmmers that only thing in strings, 
integers and the lot str name=array1water/str

 In his vision of Xanadu every piece of published information had a 
 unique ID that was reused everytimes the publication was referenced - 
 which would solve our problem.
Keep on dreaming Jakob :-)


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-29 Thread Alexander Johannesen
On Fri, Apr 30, 2010 at 04:17, Jakob Voss jakob.v...@gbv.de wrote:
 But all the flaws of XML can be traced back to SGML which is why we now use
 JSON despite all of its limitations.

Hmm, this is wrong on so many levels. First, SGML was pretty darn good
for its *purpose*, but it was a geeks dream and pretty scary for
anyone who hacked at it not fully getting it (like most normal
developers). As with many things where the learning curve is steep, it
fell into the not good for normal consumption category and they
(well, people who cared, and made decisions about the web) were
forced to make XML. But JSON? Are you sure you've got this figured
out? JSON as a object serializing format is good for a number of
things (small footprint, embedded type, etc.), but sucks for most
information management tasks.

However, I'd like to add here that I happen to love XML, even from an
integration perspective, but maybe that stems from understanding all
those tedious bits no one really cares about about it, like id(s) and
refid(s) (and all the indexing goodness that comes from it), canonical
datasets, character sets and Unicode, all that schema craziness
(including Schematron and RelaxNG), XPath and XQuery (and all the
sub-standards), XSLT and so on. I love it all, and not because of the
generic simplicity itself (simple in the default mode of operation, I
might add), but because of a) modeling advantages, b)
cross-environment language and schema support, and c) ease of
creation. (I don't like how easy well-formedness breaks, though. That
sucks)

But I mention all this for a specific reason ; MARCXML is the work of
the devil! There's a certain dedication needed for doing it right,
by paying attention in XML class, and play well with your playmates.
This is how you build a community and understanding around standards;
the standards themselves are not enough. The library world did nothing
of the kind ;
http://shelter.nu/blog/2008/09/marcxml-beast-of-burden.html

The flaws of XML can most likely be traced back to people not playing
well with playmates, and not the format itself.

 May brother Ted Nelson enlighten all of
 us - he not only hates XML [1] and similar formats but also  proposed an
 alternative way to structure information even before the invention of
 hierarchical file systems and operating systems [2].

Bah. For someone who don't see the SGML - XML - HTML transgression
as an inherited and more rigid structure (or, by popular language,
more schematic) as a document model as a good thing, I'm not
impressed. Any implied structure can be criticized, including pretty
much any corner of Xanadu as well. (I mean, seriously; taking
hypermedia one step closer to a file system does *not* solve problems
with the paper-based document model of HTTP, it just shifts the focus)

 In his vision of Xanadu
 every piece of published information had a unique ID that was reused
 everytimes the publication was referenced - which would solve our problem.

*Having* an identifier doesn't mean that identifier is a *good* one,
nor that it solves your problem. There's plenty of systems out there
where everything has an identifier (and, if you knew XML deeper,
you'll find identification models as well in there, but people don't
use them because the early onset of XML didn't understand nor need
them). Have a look at the failed XLink brooha for something that
worked and filled the niche, but people didn't get nor did tool-makers
see the point of implementation, and the thing died a premature death.
The current model of document structure and XQuery is somewhat of an
alternative, but people are also switching to CSS3 styles as well. The
thing is, just because you've got persistence in a system of
identifiers, it does not follow that the information is persisted; the
problem of change is *not* solved in neither systems, and so we work
with the one we got and make the best of it.

One thing I always found intriguing about librarians were their
commitment to persistent URIs for information resources, and use of
303 if need be (although I see this mindset dwindling). I think you're
the only ones in the entire world who gives a monkeys bottom about
these issues, as the rest of the world simply use Google as a
resolver. I can see where this is going. :)


Regards,

Alex
-- 
 Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ --
-- http://www.google.com/profiles/alexander.johannesen ---


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-29 Thread Eric Hellman
May I just add here that of all the things we've talked about in these threads, 
perhaps the only thing that will still be in use a hundred years from now will 
be Unicode. إن شاء الله


On Apr 29, 2010, at 7:40 PM, Alexander Johannesen wrote:

 However, I'd like to add here that I happen to love XML, even from an
 integration perspective, but maybe that stems from understanding all
 those tedious bits no one really cares about about it, like id(s) and
 refid(s) (and all the indexing goodness that comes from it), canonical
 datasets, character sets and Unicode, all that schema craziness
 (including Schematron and RelaxNG), XPath and XQuery (and all the
 sub-standards), XSLT and so on. I love it all, and not because of the
 generic simplicity itself (simple in the default mode of operation, I
 might add), but because of a) modeling advantages, b)
 cross-environment language and schema support, and c) ease of
 creation. (I don't like how easy well-formedness breaks, though. That
 sucks)

Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

e...@hellman.net 
http://go-to-hellman.blogspot.com/


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-29 Thread Alexander Johannesen
On Fri, Apr 30, 2010 at 10:54, Eric Hellman e...@hellman.net wrote:
 May I just add here that of all the things we've talked about in these 
 threads, perhaps the only thing that will still be in use a hundred years 
 from now will be Unicode. إن شاء الله

May I remind you that we're still using MARC. Maybe you didn't mean in
the library world ... *rimshot*


Alex
-- 
 Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ --
-- http://www.google.com/profiles/alexander.johannesen ---


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-29 Thread Eric Hellman
Ha!

One of the things OpenURL 1.0 fixed was to wire in UTF-8 encoding. Much of 
the MARC data in circulation also uses UTF-8 encoding. Some of it even uses it 
correctly.

On Apr 29, 2010, at 8:58 PM, Alexander Johannesen wrote:

 On Fri, Apr 30, 2010 at 10:54, Eric Hellman e...@hellman.net wrote:
 May I just add here that of all the things we've talked about in these 
 threads, perhaps the only thing that will still be in use a hundred years 
 from now will be Unicode. إن شاء الله
 
 May I remind you that we're still using MARC. Maybe you didn't mean in
 the library world ... *rimshot*
 
 
 Alex
 -- 
 Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
 --- http://shelter.nu/blog/ --
 -- http://www.google.com/profiles/alexander.johannesen ---


Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-29 Thread stuart yeates

Eric Hellman wrote:
May I just add here that of all the things we've talked about in 

 these threads, perhaps the only thing that will still be in use a
 hundred years from now will be Unicode. إن شاء الله

Sadly, yes, I agree with you on this.

Do you have any idea how demotivating that is for those of us 
maintaining collections with works containing characters that don't 
qualify for inclusion?


cheers
stuart
--
Stuart Yeates
http://www.nzetc.org/   New Zealand Electronic Text Centre
http://researcharchive.vuw.ac.nz/ Institutional Repository