Your argument, Mike, boils down to: Let's not have yet another DC variant.
I'm not aware of many DC variants, but perhaps there are.  

DC  is insufficient - too simple - for many users, MOD to complex for many,
and we need something in between for SRU, a "DC Variant" would be most
expedient. Can you point to some of these DC variants and maybe we can
select one or more that seem to be useful for SRU.  

Lacking that, I think we should develop one. We're talking about a
descriptive metadata element set for search applications. Who's better than
SRU implementors to develop it?

And no, you can't necessarily say "use ONIX" the next time someone needs an
element.  "Price" happens to be in ONIX. The next needed element may not be
in ONIX. We need to be in a position to support a needed element when the
need arises, without going to some external body and begging them to add it.


--Ray


-----Original Message-----
From: SRU (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]] On
Behalf Of Mike Taylor
Sent: Thursday, April 03, 2008 11:48 AM
To: [log in to unmask]
Subject: Re: SRU Record Metadata and DCX Schema (was: Price information in
SRU responses)

Ray Denenberg writes:
 >> Finally, there is the proposal that you posted, namely the ability  >>
to extend Dublin Core records with elements from the Record  >> Metadata
namespace.  I think this is a good and useful proposal,  >> but it has
nothing to do with the particular problem we set out to  >> solve.
 >
 > I think you're still not grasping what I'm proposing. 

More than likely :-)

 > I'm NOT proposing to extend our DC schema with the RMD namespace.
 > I'm proposing to extend the DC schema with both the RMD namespace  > AND
the DMD namespace.
 >
 > The DMD namespace will be a discrete set of descriptive metadata  >
elements that we come up with collectively (just as we did for the  > DMD
namespace) one of which will be 'price'.

At that point, we'll have got into application profiling, and we'll run the
risk of ending up with an incompletely specified, half-thought-through
subset of ONIX.  Doesn't seem like a great idea to me.

 > This approach does not have the interoperability problem you cite  >
because, dmd:price for example, will be a well-known element from a  >
well-known namespace.

That's true; but it'll be achieved at the price of introducing yet another
DC variant, and also yet another application-level schema.
Plus I'm not sure there's the will to make this DMD element set.

 > If the person who started this discussion, about price, wants to  > use
ONIX, fine, but at least we'll have this in place for the next  > time
someone has a similar need.

Or we could say "use ONIX" the next time someone has a similar need.

 _/|_	 ___________________________________________________________________
/o ) \/  Mike Taylor    <[log in to unmask]>    http://www.miketaylor.org.uk
)_v__/\  "You adopted a fox-cub whose mother was somebody's coat" --
	 Roger Waters, "Go Fishing"