registry-updatable data

[KevinBenson]

----Sorry mssl outage was from last night.

Yes there will need to be a status attriubute with the original resource
record or it should still be there.  The livelines like you say should be at
the recordCuration.  Status should stay as "active|inactive|deleted".
Livlieness might be 0=rare to 4=very active possibly.  But no matter how
many people put there stamp "recordCuration" on it once the original
registry puts it as "deleted" (status) such as a cone search service no
longer in use then that is it; it is gone till the originating registry
brings it back to life with an "active" status; No matter how much
livlineess you have.
---
But in general I think we might want to think of another solution on how to
get at this recordCuration.  Actually I am really starting to not like the
name "recordCuration" there is no "curation" involved, your putting stat
information for a record, a stamp to it, a critical review if you want.

One of the primary purposes of the Search interface should be any app
connected to any registry can do virutally the same query and get back
consistently the same data and information back.  And here we are trying to
weave in inconsistent data.          (--ignore non-ivoa registry extensions
schemas that is a different kind of issue)

I think we might want to come up with "Use case" scenarios of how apps will
use it.

Almost all registry apps will not want to query on "recordCuration"/"stamp"
because you will not get the same results back.   Only special apps such as
actual curation apps will ever want to do any querying on this
"recordCuration" area.

I think we might need to think about some other type of solution for this
and possibly leave the search and VOResources for the most part alone (but
that is just my opinion).

Any ideas?

I will throw out a possible guess: Just another web service interface method
called getRecordCurationsForIdentifier  or searchRecordCurations that deal
with just returning "recordCuration" elements.  And make the app do a second
query if they want to get at the Resource hence VOResources.  This would
entail I guess that we are somehow harvesting our "recordCuration" between
our apps probably via sets.  I will try to send a link later of the older
Stamping area from a year ago, I think it was on a similiar basis.

Cheers,
Kevin




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


Hi Aurelien,

On Wed, 6 Apr 2005, Aurelien Stebe wrote:
> I have a few comments on this :
> - I think the "status" attribute should stay with the resource record,
> and a "liveliness", as was suggested at first, would be put in the
> recordCuration

what would be the difference between status and liveliness?

> - two verification levels : one for the metadata and one for the actual
> service

Would the verification of the service rate the compliance of the service
behavior and the output format?  True, we had be thinking of putting these
two together under one value.  It's likely that we may have a service that
operates well but is poorly described by its metadata.  In the interest
in adding metadata that does not get used, one question we should consider
is, do you think applications that use this information will care to
distinguish between quality of the service interface and the quality
of the metadata?  Is a single value for both good enough (for now)?

Note that we specifically trying to steer clear from rating the quality of
the resource content itself (e.g. is this a good dataset or not).

> The problem I see with all this is that it would change the level of the
> resource metadata.
> It was : VOResources/Resource .... it would become :
> VOResources/resourceRecord/profile
> It might be a problem during the transition.

Yes, this definitely has transition pains associated with it.  In general,
any change to the core VOResource schema will have pain in the transition
(which is why I'm keen on getting VOResource & RI out of working draft
status).

cheers,
Ray