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