RM v1.1 feedback loop from VOResource

[Doug Tody]

Hi Ray -

On Wed, 8 Jun 2005, Ray Plante wrote:
> 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.

An issue here is that in DAL we have dataset identifiers, used by the
creator, publisher, etc., to assign unique identifiers to datasets.
Hence we have at most one "creator dataset ID" and any number of
"publisher dataset IDs".  The names currently used for these identifiers
are "CreatorID" and "PublisherID" (or "PubID").  The term "ID" is commonly
used for record IDs in databases, so these are logical names from the
perspective of a table describing a number of individual datasets.
An unresolved issue is what to do about a name such as PublisherID being
used to mean different things in both places; in this sense a naming
convention such as "XxURI" might avoid the problem.  Can we come up with
a consistent naming convention which avoids this problem?

At the level of DAL we also want to identify resources such as a
collection, publisher, etc.  In this case, since there can be many
individual datasets, there may be thousands or millions of records which
refer to a single such resource.  Using a URI to identify such a global
resource results in poor information hiding; we are essentially embedding
a pathname in the data.  In this case it might be better to refer to
the resource via a short name of some sort.  We would then look up the
short name in the registry to get a full description of the resource.

Hence it may be best to refer to global entities like "collection"
or "publisher" via a unique short name of some sort, which we resolve
indirectly via registry lookup.  For low level entities such as individual
datasets a pathname (e.g., a URI such as a dataset identifier) works best,
and can resolve to individual data entities.

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

What we really need here is not who performed the validation, but the
level of compliance as defined by the interface in question.  If this
is well defined, it doesn't really matter who performed the validation.

Note a complex resource such as a service is not merely valid/invalid,
rather there are levels of compliance.  A valid resource meets the
criterial for some such level of compliance, for example a service which
supports all the MUST elements of the interface is said to be minimally
compliant; if in addition it supports all the SHOULD elements it is
fully compliant, etc.


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

A service could potentially have more than one URL endpoint.  It really
depends upon the protocol.  In principle there could be one for each method;
if the service supports multiple protocols they might have different
service endpoints, etc.

	- Doug