From dave.morris at bristol.ac.uk  Mon May 28 05:47:17 2012
From: dave.morris at bristol.ac.uk (Dave Morris)
Date: Mon, 28 May 2012 13:47:17 +0100
Subject: VOSpace standard properties
Message-ID: <4FC373D5.4000706@bristol.ac.uk>

Hi all,

How many of the 'standard properties' listed in section 3.2.4 of the
VOSpace specification do we actually need to make VOSpace-2.0 function.

I would like to suggest that we should only use SHALL for the minimum
core set of properties required for interoperability.

Other institutes / groups are free to add their own property
definitions, and the IVOA is free to add or adopt them, but if they are
not required for interoperability, they should be optional.

There are several properties listed in section 3.2.4 the precise
definitions of which are either not listed or still to be defined.

Many of the properties imply either some form of specific vocabulary or
a standard URI/URL format that has not been defined yet.

Two of the most 'interesting' properties refer to the group access
permissions

    ivo://ivoa.net/vospace/core#groupread
    ivo://ivoa.net/vospace/core#groupwrite

Unless we have a specification for what constitutes an identity and a
'group of identities' in the context of the IVOA, then it may be
difficult to get an agreement on exactly what these properties contain
and how the information is represented and used.

One of the benefits of using an open list of property types is that it
enables other groups to register their own types of properties,
encourage others to use them, and then, once they have been used, tested
and refined by use in real applications, propose them as IVOA standards.

Some implementations may already be using properties like this to set
access permissions for groups, but unless we have an established IVOA
standard for groups and access controls that we can refer to, then these
properties should be optional properties defined elsewhere, and not
listed as part of the VOSpace specification.

If someone already has a working definition for one of these properties,
then making the property usable by others could be as simple as
submitting an IVOA note describing the property, its current registry
URI, what the property contains and how it is used.

If we don't have detailed working definitions for these properties, then
we should not require their use by using the word SHALL in the VOSpace
specification.


Thanks,
Dave