Question: harvesting managed vs. all resource records

[Aurelien Stebe]

I rather agree with Kevin on this.
The whole resource metadata should be exactly the same between all 
registries.
So, "status" should only be modified by the originating registry and
"HarvestedFrom/HarvestedDate" should be kept out of the resource schema.

This stamping idea is new to me, but I think it would be a good solution.
It would even allow each registries to put specific extensions like 
curation/coverage
remarks on the resource itself, comments or even extra data needed by 
their particular user interface.
Although, it would be more useful to get it directly with the resource, 
instead of calling another method.

Some more small comments :
I also think that the status, created and updated attributes should be 
made "required".
As I understand the W3C doc, xs:date allows for an optional timezone, 
but not an actual time.
And, consider to restrict the result to "active" resources for 
"KeywordSearch" only,
because otherwise it would be impossible to edit an inactive or deleted 
resource
by specifying its identifier using "Search".

Cheers,

Aurelien STEBE


KevinBenson wrote:

>Wow you definitely threw some new things at me that I did not know about.
>Maybe I missed the loop, but I think we might have a nightmare if your
>saying these attributes may be different between all our registries.  I feel
>they should come from the originating registry.  Was there some other thread
>talking about these attributes are allowed to be different between
>registries. How does a resource ever go to "deleted" if everybody is keeping
>different statuses and now our "oai_full" set will be completely different
>between registries (unless we keep 2 different copies of resources yuck).
>Also the verificationLevel your sliding in there could be quite a lot of
>trouble if they are changing between different registries.  Also possibly
>give me a "harvestFrom" attribute example, I could see some worth of a last
>harvest date, but again not on the actual Resource record.
>
>I feel that all changes should come from the originating (managed or owned)
>Registry otherwise things are going to get very jumbled.
>
>A POSSIBLE SOLUTION OR COMPROMISE WITH STAMPING:
>Originally Wil suggested an idea of stamping this was some months ago it
>could be something we all welcome back.  We decided at the time it might be
>a little difficult on this first pass, maybe now is the time to resurrect it
>to life.  If my memory serves me correct changes are not on a particular
>Resource record (hence the Record stays the same).  Instead internally  (or
>possibly even a separate type of Resource type if we want to go that way), a
>Registry may stamp other Resource records.
>
>>From our recent transactions on e-mails we might have something like this:
></stamprecord>
><stampedidentifier>CDS/Vizier/II/2A</stampedidentifier>
><stamp>
>  <approvedby>JVO</approvedby>
>  <itsverificationLevel>Good/5</itsverificationlevel>
>  <livliness>active|inactive</livlieness>
></stamp>
><harvestedFrom>Some registry</harvestFrom>
><lastHarvestDate>Last Harvest Date</lastHarvestDate>
><stamprecord>
>
>The above is just a first thought, we might want to pull the original
>stamping idea from the past it was more clear.  In general the way I
>remember there would be one or two additional web service interface methods
>such as getStampByIdentifier.  Anyways we now have the notion of what was
>approved by a registry and verification level for that Record at that
>particular Registry plus livliness at that Registry that you wanted; and
>finally we can throw in some other stat information such as harvestFrom,
>lastHarvestDate, and others.  The original Resource record will remain
>consistent throughout our Registries.
>
>Cheers,
>Kevin
>
>  
>