[OAI-implementers] returning *data* (as opposed to metadata)

[Hussein Suleman]

This is a multi-part message in MIME format.

--Boundary_(ID_LeCbx9Gg9P9HDVZ65kNl4g)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit

hi

always eager to add my 2-cents worth, here goes :)

metadata vs data:
who cares ? if anyone was at JCDL, you might recall Bill Arms saying
that we have as a community not yet proven the worth of metadata ... in
a similar vein, there are some researchers who tend to think of metadata
as merely a representational model or transformation of data ... i think
the bottom-line is that we want OAI to be used to convey useful
representations of the objects and do so in an efficient manner ...
right now, generally, the most useful data is title, author, etc. and it
is most efficient to transmit only the most discriminating of these
fields ... but in different contexts, usefulness and efficiency may mean
different things - hence the justifiable position to transmit full
content in XML-encoding form ... i fully support extending the
boundaries of the common definition metadata to experiment with meeting
the needs of specialized communities ...

as another suggestion, i have in the past advocated forming community
metadata sets with semantically well-defined links - not just simple DC
identifier URLs ... i think this would be another approach that may be
sort of a middle road

do remember that if your archive is registered publicly you should try
to be "nice" to people using your data - dont burden them with quantity
- its all well and fine to send 10000 large records in XML, but have you
tried parsing an XML document of that size ?

what are the semantics of OAI:
OAI-MHP is a protocol for transferring metadata (as loosely defined as
above) ... it is meant to be experimental and if we can do interesting
things with it, that will further justify its existence, promote its use
and contribute to the constant evaluation effort ... that said, i should
add that while most people are thinking about extensions, i have spent
the last 2 months actively building OAI-based Digital Library components
... my research focuses (among other things) around testing the
hypothesis that componentized digital libraries can be best served by a
common baseline model like OAI, and that with minimal changes we can
create "intraoperable" systems using "semantic overlays" for OAI (bear
with me for taking the liberty of creating a vocabulary to explain what
im doing) ... i am also testing the viability of the OAI protocol to
meet the needs of such an approach, and trying to determine what other
protocols would be needed to complete the picture of what i have begun
to call the "Open DL Design" within the framework of OAI principles
(Herbert, sorry about using Open one more time :))
i cannot point to any reports yet but within the next few months i will
probably try to get some of this published as well as making available
drop-in OAI-in/OAI-out modules that act as search engines, browse
engines, filters, converters, etc. ...

dc.identifier:
about the identifiers, please note that as Simeon pointed out, the DC
identifier field does not have specific semantics ... i think issues are
being confounded here ... the OAI identifier is the one in the header
and that is very particular - as far as i remember, the DC identifier
isnt even required !

well, thats it for now ... if my perspectives are too radical, please
just ignore them ... i have scant respect for the establishment - id
much rather push the boundaries since these are after all our home-grown
boundaries and if we dont push we will never know if we got them right
in the first place :)

ttfn
----hussein

-- 
========================================================================
hussein suleman -- hussein@vt.edu -- vtcs -- http://purl.org/net/hussein
========================================================================

--Boundary_(ID_LeCbx9Gg9P9HDVZ65kNl4g)
Content-type: text/x-vcard; name=hussein.vcf; charset=us-ascii
Content-description: Card for Hussein Suleman
Content-disposition: attachment; filename=hussein.vcf
Content-transfer-encoding: 7bit

begin:vcard 
n:Suleman;Hussein
tel;work:+15402313615
x-mozilla-html:FALSE
url:http://purl.org/net/hussein
org:Virginia Tech;Digital Libraries Research Laboratory
version:2.1
email;internet:hussein@vt.edu
adr;quoted-printable:;;2030 Torgerson Hall=0D=0A;Blacksburg;Virginia;24060;United States of America
note;quoted-printable:http://www.dlib.vt.edu=0D=0Ahttp://www.vt.edu=0D=0A
fn:Hussein Suleman
end:vcard

--Boundary_(ID_LeCbx9Gg9P9HDVZ65kNl4g)--