Print

Print


I agree with Matthew's generic wrapper and Ray's "keep it simple"
proposal.
I'm not sure whether it will be a real requirement, but I am thinking
on different tracks for 1) concatenating completely different schemas
and 2) using a single schema for complementary metadata element sets
with DC as kernel.

For 1) we might want to support to deliver MARCXML and DC and
possibly other schemas in a single request and in this case I would
use recordSchema=DC+MARCXML with a response in a generic wrapper.

For 2) we will use DCX but if DCX is not in explain we might ask for
alle schemas that are recognized as a meaningful compliment to DC,
eg. recordSchema=DC+REC. For us it doesn't make any difference
whether DC and REC are wrapped in their own container or are in a
single container. In fact DCX can to some extent be interpreted as
"DC + *".

I do not think support for requesting multiple schemas is a real
requirement although we (KB) might perhaps want support it for
internal use.

Theo



On 9 Aug 2005 at 14:32, Ray Denenberg wrote:

> If this is a real requirement I believe the only sensible solution is
> the straightforward one (that I think Matthew is suggesting), that is,
> add another parameter -- next version of course. Call it something
> like 'container', with two sub-parameters (1) name/id of a container
> schema, e.g. mets; and (2) one or more "base" schema name/ids, e.g.
> mods, rec, dc.    Or, if we insist that we cannot have structured
> parameters in the request then a space separated list of schema names
> where the first is a container and those following are base schemas.
> Or this could be defined as an extension.
>
> But the point is, don't make it any more complicated than that -- in
> particular don't overload the existing schema parameter. Hopefully
> we've learned that lesson from Z39.50, where ironically it was almost
> the exact same problem we were solving more than 10 years ago, widely
> cited as a requirement,  we spent enormous effort solving it for
> version 3, and it was never widely implemented, if at all --  I don't
> know if the reason was that the solution was so complicated or if
> people decided it really wasn't a requirement after all.  But (1) we
> really did make it more complicated than it needed to be, and (2) we
> really didn't adequately scope out the problem.
>
> I think we've learned our lesson about overloading parameters in the
> name of compatibility, and the solution to this problem isn't terribly
> omplicated  -- however I remain skeptical about whether this is a real
> problem - real in the sense that if we solve it (in a reasonable
> fashion) people will implement the solution.
>
> --Ray
>
>
> ----- Original Message -----
> From: "Matthew J. Dovey" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Tuesday, August 09, 2005 12:30 PM
> Subject: Re: rec context set schema
>
>
> > What's to stop us defining a (potentially infinite) group of
> > new schemas, each identified by a URI of the form
> >         http://loc.gov/sru/mets/<path-to-some-other-schema>
> > each of which represents METS records using that nominated schema?
>
> I think the problem here is that a METS record is typically a
> container for multiple formats.
>
> So for instance a returned METS record might include the object itself
> as an OpenOffice XML doc, the metadata about the object as a MODS XML
> doc and the metadata about the record as a rec XML doc (all neatly
> wrapped in METS).
>
> So my request would need to be something like
> http://loc.gov/sru/mets/path-to-OpenOfficeXMLSchema&path-to-MODS-schem
> a& path-to-rec-schema - which is workable but messy (and would require
> a similar messy mechanism for MPEG21 DIDL and any other wrapper
> schema)
>
> A neater solution might to be consider how to ask for multiple schemas
> within a generic wrapper schema explicitly rather than overloading the
> mets/DIDL/etc. schema name - with wildcard support it may even meet
> Theo's needs.
>
> Matthew