- From: <siglun@gungner.lub.lu.se>
- Date: Wed, 26 Mar 2003 11:52:44 +0100 (CET)
- To: Mike Taylor <mike@indexdata.com>
- cc: Andy Powell <a.powell@ukoln.ac.uk>, zig <www-zig@w3.org>
On Wed, 26 Mar 2003, Mike Taylor wrote: ... > > However, it is worth noting that the simple DC schema is > > specifically intended for importing into other, > > applicationp-specific schemas. Therefore it does not define a > > container element for the DC record - it is up to the application to > > define that. > > ... which, to the eye of the layman, is very similar to not having > defined a schema :-) But, OK, point taken. A more Z39.50 oriented metaphore would be to say that it is very much like having defined tagset-g (or tagset-2). A hit should normally also contain tagset-m related stuff (relevance rank or whatever administrative information about a record a gateway or a user might need). So if going this way one need to define schemas for those as well. Now, please let me diffuse away from the subject. The elements of a single hit has to be grouped inside an element, and services using the bath profile would obviously use dc-record for that, but others perhaps rather use oai_dc:dc. OAI put inidividual records inside an envelope <ListRecords> <record > <header > ... some tagset-m like stuff </header> <metadata > <oai_dc:dc xsi:schemaLocation="xsi stuff" xmlns:stuff="other uri Stuff"> ... some tagset-g like stuff </oai_dc> </metadata> </record> </ListRecords> The Bath profile does this in an entirely different way. Obviously the both ways of doing it can easily be built on top of the same service, but since I'm lazy I'd like to have my server to behave OAI-PMH like when queried OAI-PMH like, but I want that behavious to be a special case of ZURL. (Put another way: Why should I need to build different interfaces for export and search?) Now, the kind of data you may search this way are almost trivial. Trivial to the extent that it does not stimulate my fantasy. Consider a database containing METS, EAD or Master records for digital library objects, archival descriptions or medieval manuscripts, respectively. (or perhaps all three kinds of metadata) Most likely, a result set should contain not only simple bibliographic (or archival) references but also navigational information -- tags very much like those defined in the now defunct (I think) collections profile. The problem of delivering XML search results will be even more complex when searching XML documents, TEI, DocBook, OpenOffice or whatever. People at W3C would say that these are not Z issues but X Query ones. That may or may not be correct. But I think its not, because X Query is to closely linked to the syntactic peculiaries of each document type. To whom does these problems belong? Yours Sigge
Received on Wednesday, 26 March 2003 05:56:35 UTC