RM v1.1 feedback loop from VOResource

[Robert Hanisch]

Hi Ray.  Working late?

These sound easy to fix in RM and now is of course the time to do it.
Should I assume that ServiceURL and BaseURL get collapsed to AccessURL?  Is
that the way you think things will go in the tiger team?

Thanks,
Bob

----- Original Message ----- 
From: "Ray Plante" <rplante at ncsa.uiuc.edu>
To: <registry at ivoa.net>
Sent: Wednesday, June 08, 2005 3:43 AM
Subject: RM v1.1 feedback loop from VOResource


> Hi Bob,
>
> Now that I have gone through VOResource release and some testing, I've
> noted some remaining differences between VOResource and the RM that might
> be best resolved by a changes to RM.
>
>   o  I recommend changing "StandardURI" to "StandardID".  This makes it
>      parallel to "PublisherID".  Both take an IVOA Identifier as a value,
>      so I think it would be good to give them similar names.
>
>      If you would rather keep "StandardURI", I'm happy to change
>      VOResource to match that.
>
>   o  Add "served-by" as a possible value for "Relationship" with the
>      definition, "The resource (e.g., a data collection) can be accessed
>      via another service resource."
>
>      This was requested by Paul Harrison to support Astrogrid work.
>
>   o  Add a new term, "ResourceValidatedBy" whose value is an IVOA
>      identifier and whose value is the IVOA identifier for the registry or
>      organisation that set the "ResourceValidationLevel".
>
>      This came out of our discussion of ResourceValidationLeve discussed
>      in Kyoto.
>
> There is one other descrepency I wanted to point out that we may fix in
> VOResource, but it depends on the results from our registry data model
> tiger team effort.  RM defines "ServiceURL" and "BaseURL"; in VOResource,
> these are both encoded with an element called "accessURL" which accepts
> an attribute, "use", that can indicate if it is a base URL.  The reason
> for this is somewhat historical, but the reasons this are two:
>
>   1. to enforce that all interface descriptions provide a URL for
>      accessing the service, be it a base URL or web service URL, via a
>      single element.
>
>   2. this same name is reused in the DataCollection resource type (not
>      defined in the VOResource core but in the extension VODataService
>      schema to optionally provide a URL (e.g. to an FTP directory) where
>      the data can be downloaded from.
>
> I would expect we'd have this accessURL issue settled before the end of
> the month when RM v1.1 is scheduled to go to PR.
>
> cheers,
> Ray
>
>
>
>