Alternative proposal

Tony Linde Tony.Linde at leicester.ac.uk
Fri May 11 01:24:16 PDT 2007


Hi Ray,

> that there is little gained by slicing up the core Resource metadata--
that
> is, in RM parlance, the identity, curation, and content metadata.  It's

That effectively rules out my proposal then. I was suggesting that we
separate the content from the location/curation metadata. The registry would
be a simple unambiguous pointer to resources and their management and (as
Doug suggested) the links between them. The content metadata is what is used
for discovery and is the site of the fine/coarse grained dispute which is
why I sought to move it to a separate area. If you want to keep the content
metadata in the registry then we keep the registry exactly as it is with
*all* metadata contained within it.

> refered to as core for good reason as it is generally applicable and was
> considered during the development of RM as important for providing quality
> descriptions of resources.  

I don't agree - it was only considered core by a few people, those for whom
it was the core requirement. What is core is what is essential to get a job
done, in which case *all* the metadata currently in the registry is what I
consider as core since it is all essential to allow our apps to work. The RM
was always a point of contention in the past: it is seriously deficient in
what I (and others) consider necessary for client discovery and use of
resources and that deficiency was corrected in the development of the
schemas. The RM was only ever a starting point for registry discussions and
was (IMO) left behind by the schema discussions.

I guess the only point of consideration for the meeting next week is
therefore your proposal for the extra URL pointer: I hope it can address all
the concerns raised during the email exchange of the past few days and look
forward to perusing the results of the discussion.

I hope you and everyone else going to the meeting have safe journeys,
productive discussions and get some time to enjoy Beijing.

Cheers,
Tony.

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] On Behalf
> Of Ray Plante
> Sent: 11 May 2007 08:17
> To: 'IVOA Registry WG'
> Subject: Re: Alternative proposal
> 
> Hi Tony,
> 
> As I alluded before, I can't delay my preparation for the meeting
> anymore,
> so I haven't been able to fully digest your proposal, yet.  On second
> reading, it sounds like it is an attempt to generalize some of the
> basic
> ideas from myself and Matthew, so for that reason it is intriguing.
> 
> A major concern is how big of an impact this will have on our current
> systems, and I'm still trying to assess this.  In particular, I want to
> understand what changes in our standards and implementations will be
> required.  (Remember, our registry people are right now in the middle
> of
> rewiring their registries for the current spec.  We would not make
> friends
> if we told them they would have to go through this again.)
> 
> There are currently some natural dividing lines in the schemas that
> could
> be used to mark out our so-called "selection" metadata.  I agree with
> Bob
> that there is little gained by slicing up the core Resource metadata--
> that
> is, in RM parlance, the identity, curation, and content metadata.  It's
> refered to as core for good reason as it is generally applicable and
> was
> considered during the development of RM as important for providing
> quality
> descriptions of resources.  However, beyond that set there are some
> natural places to separate out metadata.
> 
> Another thing is that we should not let this scheme make the publishing
> of
> simple resource types overly complex and/or overly dependent on
> remotely
> accessed data.  Resources like Authority really need its extension
> metadata included directly directly in all registries.  Similarly, we
> will always need the full coordinate system definition to appear in a
> StandardSTC record or the coordinate system referenceing schema it
> serves
> will not work.
> 
> cheers,
> Ray



More information about the registry mailing list