UCD elements

[Martin Hill]

It's not so much the mapping but being able to use 'old' services.  It's 
may not be a problem between UCD1 and UCD1+, but imagine when UCD2 comes 
out.  Most services are unlikely to be UCD2-aware; so we can't send them 
files containing UCD2s.  On the other hand, we want to include UCD2s 
when we send files to new UCD2-aware services, so that we can make the 
most of them.  In these cases we *could* send the files through a 
converter service first, but I don't think we can say that there will be 
a unique one-to-one mapping *both ways*...

We should certainly offer services that generate new UCDs based on old 
ones to make the transition easier.  I don't think we need to make 
including every version mandatory - it will depend on where the user 
expects to send their files too.

Services however will definitely need to describe themselves using both 
so that both old and new clients can use them. And therefore I suspect 
they will need to include both in the results, or we are going to have 
to add another input parameter to specify which UCDs to put in the results.



Clive Page wrote:

> On Thu, 1 Jul 2004, Martin Hill wrote:
> 
> 
>>We will need (at latest when we introduce UCD2 over UCD1+) simultaneous UCDs of
>>different versions in single metadata documents (so both older and newer tools
>>can use them).
> 
> 
> Is that really necessary?  As I understand it there is a unique one-to-one
> mapping from UCD1 to UCD1+, which should be easily encapsulatable in
> software, or even a Web Service.  I'm not sure if that's true too of UCD2,
> but if it isn't doing conversions is going to be labour-intensive.
> Putting duplicated UCDs of different versions in each data file seems a
> bit of overkill if that's true.
> 
> 


-- 
Martin Hill
www.mchill.net
07901 55 24 66
0131 668 8100 (ROE)