DC comments & questions

Tony Linde ael at star.le.ac.uk
Sun Oct 5 14:55:48 PDT 2003


Hi Roy,

> The IVO identifier already is a simple string, right? Like this:
>             ivo://RoysAuthority/RoysDataCollection

In the schema it is implemented as two elements: AuthorityID and ResourceKey
which can be combined in string form to make up a URI.

> > Which is pretty much what I have been arguing for.
> 
> Oh good. It is also what I have been arguing for. So you owe 
> me a beer then?

Other way around, surely? Even better, we'll each buy a round :)

I've been wondering whether, in the short term, we shouldn't just create a
complex type which includes all the DC Simple elements all namespaced to DC
and leave it up to implementors whether they capture all or any data,
whether they fill them on capture or only at harvesting or whatever. Then we
can get around to sorting out a better implementation and if/how to use the
qualified DC next year. What do you think?

Cheers,
Tony. 

> -----Original Message-----
> From: Roy Williams [mailto:roy at cacr.caltech.edu] 
> Sent: 05 October 2003 19:26
> To: Tony Linde; registry at ivoa.net
> Subject: Re: DC comments & questions
> 
> 
> Tony
> 
> I don't think anyone is advocating that we use DC in our 
> syntax. It is the semantic conversion that is important. We 
> could use the French words for Creator, Date, Description etc 
> -- so long as the translation back to the DC terms carries 
> exactly the same semantic meaning.
> 
> > 2. Where, with things like identifier and coverage, we have 
> structured
> data
> > while DC mandates simple string data, how and where does this 
> > conversion take place?
> 
> I am assuming there will be a translation layer to convert 
> VOResource to DC. In our registry at Caltech, it is 
> implemented with an XSLT script. Of course, the mechanism is 
> up to the implementor. In fact, the implementor is not even 
> required to use VOResource. So long as they can produce 
> correct VOResource for the harvestor, it could have been 
> translated from a relational database with column names in Hungarian!
> 
> The IVO identifier already is a simple string, right? Like this:
>             ivo://RoysAuthority/RoysDataCollection
> 
> As for coverage, we should leave it up to implementors for 
> the moment, let the community choose the standard (i.e. next 
> year's interop).
> 
> > 4. If so and where our metadata does not map to a simple string, 
> > should we put the DC term in here and mandate that it is 
> not captured 
> > from the user/dataaset but is constructed from the 
> structured metadata 
> > in some way (as we've defined the way of turning an 
> Identifier into a 
> > URI)?
> 
> Yes precisely.
> 
> > 5. Finally, how do we use DC? When metadata from our registries is
> harvested
> > to non-astro sites, what do they take: only the DC terms or 
> all of the 
> > metadata?
> 
> They take the DC only.
> 
> > And how is OAI related to DC?
> 
> Every OAI repository MUST offer DC as one of its metadata 
> formats. This is how they achieve interoperability of *all* 
> OAI registries. But OAI can also be extended from DC, by 
> offering custom metadata formats, for example VOResource.
> 
> > Which is pretty much what I have been arguing for.
> 
> Oh good. It is also what I have been arguing for. So you owe 
> me a beer then?
> 
> Roy
> 




More information about the registry mailing list