registry-updatable data

Matthew J. Graham mjg at cacr.caltech.edu
Tue Apr 5 11:30:50 PDT 2005


Hi,

I've just seen this now: it looks as though we are all already doing 
pretty much the same thing or at least thinking the same (great minds 
thinking alike or maybe fools seldom differing :-).

	Cheers,

	Matthew

On Apr 5, 2005, at 10:36 AM, Ray Plante wrote:

> 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
>
>



More information about the registry mailing list