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