registry-updatable data

[KevinBenson]

Excellent stuff Ray, yes I started to think along the same lines as what you
have below, yours looks quite good.  I will need to think about it a little
more.  From the looks of Matthew's e-mail (subject Harvesting) were starting
to think alike.

Some initial thoughts of what I am trying to work out:
1.) Do we want to return all <recordCuration> elements there maybe many for
one record, such as one from stsci, one from Astrogrid, one from JVO and so
on or do we just return the one recordCuration that came from the querying
registry if there are any?
2.) Yes maybe a little name changing as we go along, sort of like a few
names on Matthew Grahams last e-mail, but that can get sorted out later.
3.) What is the unique id/identifier on recordCuration? Presumably a
possible concat of what I called the stamped identifier and the curated
registry part of the identifier would work good, or we just make the user
make up another set of idents (but I think it might be easier to automate
it).  The <stampedidentifier> as you say is the ivoa identifier, but wanted
to make sure it got across of what the identifier was that was curated from
a particular registry.  Hence we need to put an identifier on our
<recordCuration> elements that way we don't need to do any kind of mapping
with ri:profile.
4.) Final thought would a lot of apps or services in the beginning might not
want this recordCuration, but not sure how to make it optional unless we add
some kind of boolean to our interface methods.

cheers,
Kevin



-----Original Message-----
From: owner-registry at eso.org [mailto:owner-registry at eso.org]On Behalf Of
Ray Plante
Sent: 05 April 2005 18:36
To: registry at ivoa.net
Subject: registry-updatable data


Hi Gang,

The purpose of the Resource type attributes was to separate what
information came from the resource provider (which should only be
altered by the resource provider) and what came from a registry
holding the record (which may be different registry-to-registry).
Breaking this information out entirely from the Resource element as
Kevin suggests would make this separation even more clear.  In
particular, we can break it out of the VOResource schema definition
and make it specifically part of the Registry Interface schema
(RegistryInterface-v0.1.xsd).

Note that one important point of standardizing this information is to
allow it to be exposed to applications.  Thus, this information needs
to appear via both OAI and the search interface.  It also needs to be
packaged naturally with the resource metadata.  So here's how we might
do it; I've put the namespace prefix to clarify where .  (Feel free to
suggest different names.)

  <ri:resourceRecord
        xmlns:ri="http://www.ivoa.net/xml/RegistryInterface/v0.2"
        xmlns:vr="http://www.ivoa.net/xml/VOResource/v1.0">

     <ri:profile xsi:type="vr:Organisation" created="..." updated="..." >

        <!--
          -  This element contains the resource description (formally
          -  the Resource element).  The attributes created and updated
          -  are only changed by originating registry.  The contents are
          -  only changed by the resource provider.
          -->

        <vr:title>...</vr:title>
        <vr:shortName>...</vr:shortName>
        ...

     </ri:profile>

     <ri:recordCuration>

        <!--
          -  This element contains information that can be updated by any
	  -  registry.  For simplicity, I just show the bits that were
          -  formerly discussed as Resource attribute's; see below for
          -  alternative layout.
	  -->

        <ri:status>active</ri:status>
	<ri:harvestedFrom>...</ri:harvestedFrom>
        <ri:verificationLevel>2</ri:verificationLevel>

     </ri:recordCuration>
  </ri:resourceRecord>

Do we prefer pulling the record curation information out in this way?  If
so, then we can talk the details of the format of this record.

Kevin's suggestion adds some useful information:
   o  the entity that set the "stamping" information.  This would tell us
      whether the information that came from the harvestee was preserved
      or was overridden by the harvester.

      The value should really be the IVOA identifier of the registry that
      set the information.

   o  when the record was harvested.  This would allow us to more easily
      track records that are out of date and not being reharvested (a
      problem we've encountered in the NVO).

I don't know what the "stampedidentifier" refers to; however, if it is an
identifier, it really should be an IVOA identifier.  I'll note that I
think that the word "stamp" could have some negative connotations
associated with it.  I might suggest the following modification to Kevin's
strawman:

     <recordCuration xmlns="http://www.ivoa.net/xml/RegistryInterface/v0.2">

        <verification>
           <setBy>ivo://nvo.ncsa/registry</setBy>
           <status>active</status>
           <verificationLevel>2</verificationLevel>
        </verification>
	<harvestedFrom>...</harvestedFrom>
        <lastHarvestDate>...</lastHarvestDate>

     </recordCuration>

cheers,
Ray