registry-updatable data

[Aurelien Stebe]

I think we need to keep the status attribute, because otherwise how 
would the deletion
of a resource by its publisher be transmitted and repercuted through the 
whole VO.
Liveliness could be more descriptive. Is the resource a living project 
(more data is still added),
a completed project (or is this what active/inactive status means ?), 
not always accessible,
not really stable, working but not maintained anymore, not working at 
all, ....

For the verification, I'm talking about the compliance of the service to 
the specifications.
Agreed that the data content quality shouldn't be juged.
The xml validation of the resource metadata shouldn't either.
This is the responsability of the registry curator.

Here is an idea to put both verification levels together : a score from 
0 to 99.
- 0 : no score given yet.
- 10 : usable resource metadata, but really poor.
- 20 : more complete resource metadata.
- 30 : xml schema validation of the resource output.
- 40 : full resource metadata (with coverage, region, ...).
- 50 : compulsory methods/functionalities implemented.
- 60 : optional methods/functionalities implemented.
- 70 : service human tested.
- 80 : service human tested ... and pleased.
- 90 : well-known reliable resource.
- 99 : perfect, don't touch anything.

This gives a margin between each step. A resource with a lot of schema 
errors should get 21/22.
If there is only one or two warnings, it gets 29. if it hasn't 
implemented a brand new spec functionality : 49.
The order of importance might not be correct. The compulsory methods 
implementation
is perhaps more important than the full coverage/region metadata.

cheers,
Aurelien

Ray Plante wrote:

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