Re: Proposal: Searching XML

> Right.  Or if you wanted to search a record encoded in XML but return
it 
> in GRS1, MARC, SUTRS etc, then the second part would get really get
messy 
> :)

One approach (and I don't know if I'm twisting Sebastian's original
proposal) would be to view the attribute sets as defining some abstract
XML structure which can be viewed as a hierarchical attribute set.

e.g. the XML structure

<name>
  <personal/>
  <secondary/>
</name>
<title>
  <uniform/>
  <series/>
</title>

would allows us to use XPaths of the form author/primary, title/added
etc. 

However, the above XML does not actually exist in the database,
author/personal, title/uniform are really just alternative ways of say
Bib1 Use attributes 1 and 6.  Apart from explicitly indicating the
hierarchy (and being easier to read) I'm not entirely sure what the
advantage of this would be (that's an invite to be persuaded btw),
although the above maybe more applicable to the new attribute
architecture.
 
> > On the URI issue, however, we have a easy mechanical way of
generating
> > those from the OIDs namely a URI of the form urn:z3950-odi:OID (or
> > similar).
> 
> I think that one advantage is that URIs are now much more predominant
in 
> terms of unique identifiers than are OIDs.  To take an Explain--
example, 
> currently we hide OIDs behind the names assigned to them on the MA OID

> page.  Because OIDs aren't human reader/author friendly.  On the other

> hand URIs can be and generally are.
> 
> http://explain.z3950.org/attributeSets/1.0/ 
> vs
> 1.2.840.10003.3.19
> 
> I even had to go back to our website to find out what the OID was!

I think I would prefer to see an URI schema adopted which mirrored the
existing OID structures and which is easily translatable between URI
forms and normal OID forms. Given that there are names to hide OIDs I
agree we should look at using those - so perhaps something like

urn:oid://iso/member-body/US/ANSI-standard-Z3950/Z39-50-attributeSet/Bib
-1

Matthew

Received on Sunday, 21 April 2002 17:37:29 UTC