Question: harvesting managed vs. all resource records

[Gretchen Greene]

Kevin, Ray

Well I'm still not completely clear on these discussions (smile),  only
passing along some details I gleamed along the way.  The owned/managed
Authority concept makes sense yet I see how we have struggled with local
curation and I'm concerned about the "global" curation with the multiple
resources.

Let me see if I can summarize (thinking like Roy now ;) ,  sorry if this
is repetition on the Twiki now.

threads of Resource maintenance each seems to have it's own flavor and
complexity.  Partial descriptions along these topics...

1.  OAI 
	- Sets 
		* ivo_managed, oai_managed
	- Resource headers
2.  The vr: Resource attributes
	- created, updated, status
3.  Verification/Stamping
	- verificationLevel (score)
	- whoDidIt ;)
4.  HarvestedFrom, ManagedAuthority, OwnedAuthority

Would like to see more examples for addressing the practical questions,
Where should the verificationLevel/stamp fit in with the VOResource+
schema package?  How do the OAI header elements synchronize with the
Resource attributes,  namely the OAI header status and datestamp,
vr:Resource status and updated attributes (or are these the same?)
Curation control of these components, i.e. which components are modified
by Owned, Managed, Local Authority.

-Gretchen


-----Original Message-----
From: owner-registry at eso.org [mailto:owner-registry at eso.org] On Behalf
Of KevinBenson
Sent: Tuesday, April 05, 2005 11:09 AM
To: Gretchen Greene; 'Ray Plante'; registry at ivoa.net
Subject: RE: Question: harvesting managed vs. all resource records


Okay Thanks for the information Gretchen, I might have mis-read Ray's
first e-mail about this, now I see it says (not the resource itself).
So my apologies, I thought I originally was understanding it might be
part of the Resource (hence a change to a Resource that the registry
does not own). But the e-mail still mentions "status" attribute sounding
like were talking about the Resource metadata data status attribute
which concerned me, but if your talking about it being at another
location/level and not part of the Resource metadata then okay just need
to discuss it further.  I was just getting worried that a query on lets
say status='active' would all of a sudden have different results
depending on the registry your connected to, which would not be good.

So okay yes I think the idea of stamping/verificationLevel would be a
good thing.  This seems agreed upon.  I would just like to make sure it
is not part of Resource xml records that the Registry does not
manage/own.

So with that it might be best to move this discussion on another Thread.

Cheers,
Kevin


-----Original Message-----
From: owner-registry at eso.org [mailto:owner-registry at eso.org]On Behalf Of
Gretchen Greene
Sent: 05 April 2005 15:29
To: 'Ray Plante'; registry at ivoa.net
Subject: RE: Question: harvesting managed vs. all resource records


To expand a little on the concept of verificationLevel,  while it was
not suggested as a schema dependent attribute originally the idea was
that it would be along the lines of the stamping.

A set of score values initially proposed (again, I don't know of any
group that has implemented these to date) were simple int to represent 0
- base, 1 - XSLT type VOResource/schema validation, 2- auto 'invoke'
service w/Response Ok, 3 - human review of Metadata.

Even if the registries have unique internal scoring method,  it would be
good to standardize at some 'level' for minimum consistency with the
assignment value meaning.  I think it would be worthwhile to consider
how to include this as part of schema extension or whatever,  especially
if we are now discussing resource harvesting between multiple registries
with variable publishing sources.  The number of schema metadata fields
for inter-registry curation/exchange is increasing and one more
simplistic "stamp" dare I say might be all that is needed in many cases.

-Gretchen


---------------------------
Ray's comment...


In addtion to these attributes, we have discussed adding an attribute
called verificationLevel to aid with registry curation.  The value would

be assigned to a resource record by a registry to indicate quality of
the resource metadata (not the resource itself).  Registries would set
their

own standards for what earns the highest quality rating; thus, they
would feel free to override the value that might already be in there
when the value is harvested.

These attributes are the only place where values can differ across
registries (really, only status and verificationLevel).  A harvestedFrom

added to these attributes.  The rest of the record--that is, the
information held in the Resource type's child elements--should NOT be
changed by anyone other than the original publisher.