Pete, I believe that your description of how some see the property used and
and your comparison with rights is correct.  However, as comments from
others on the UB indicate (see Diane's previous post) indicate, that is not
the _only_ way the property may be used and, in fact, any hint of of that
specific use was moved from the definition to the comment (as best practice)
in order to generalize the semantics of the property.  So, just as rights
may contain a string value made up of a rights statement, but can also
reference an separate rights description, so may the accessibility property.

I'd like to hear more regarding your statement: "I think this aspect of
dc:rights has caused us a few headaches as well, and I'm not sure that if we
were starting again we'd take the same approach."

Stuart


On 2/17/05 12:10 AM, "Pete Johnston" <[log in to unmask]> wrote:

> Quoting Andy Powell <[log in to unmask]>:
>
>> Well, I guess I am guilty of having missed the subtle point about matching
>> two sets of metadata - though I think this needs to be brought out in the
>> comment rather than in the definition.
>
> Not sure these thoughts are helpful at this point! ;-)
>
> First, I also had some doubts about the name of the property. I had grasped
> this
> aspect of a process matching resource description and user description, and
> for
> this very reason I always wondered about whether "accessibility" was the right
> name for a property of a resource ;-) Because (according to this very
> principle
> of accessibility being the result of a process), a statement made using the
> accessibility property doesn't actually describe the "accessibility" of the
> resource, if you see what I mean! It just provides a basis for a process to
> take place (involving a description of the resource and a description of the
> user), the outcome of which is an indication of the accessibility of that
> resource for that user.
>
> Secondly, I must admit I was struggling to grasp the underlying model here. I
> did have a couple of exchanges with Liddy and one of her colleagues
> before Shanghai, but they weren't able to provide any examples of how this was
> implemented in RDF (and I got too busy and didn't pursue it). It seems to me
> that as proposed the accessibility property describes a relation between a
> resource and a _description_ of that resource - where that description
> describes
> those specific attributes of the resource that support the "accessibility
> assessment" process). The information that is represented in this
> "accessibility-related attributes description" is a set of statements about
> the
> resource - the same resource as in the first description - and in an RDF
> implementation there would be a set of properties to represent this (about use
> of colour, use of audio etc. It seems to me in this model you would never
> actually need an "accessibility" property at all! If this set of statements
> was
> stored as a separate physical RDF/XML doc from the resource discovery
> description, then you'd just use rdfs:seeAlso to indicate there was more stuff
> about the subject resource.
>
> But the only descriptions I can find of how the "accessibility-related
> attributes description" is represented refer to XML - document-based, rather
> than statement-based, specifically
>
> http://www.imsproject.org/accessibility/accmdv1p0/imsaccmd_infov1p0.html
>
> so it doesn't really help disentangle this.
>
> Having said all this, I'm conscious that the dc:rights property takes a very
> similar approach to that suggested for the accessibility property - I think
> effectively often a dc:rights property points to another "description" (which
> has statements about the same resource covering those attributes of the
> resource that are concerned with rights) - so there is a precedent. OTOH, I
> think this aspect of dc:rights has caused us a few headaches as well, and I'm
> not sure that if we were starting again we'd take the same approach.
>
> Oh dear. Not sure that was constructive at this point in the proceedings!
>
> Pete
> -------
> Pete Johnston
> Research Officer (Interoperability)
> UKOLN, University of Bath, Bath BA2 7AY, UK
> tel: +44 (0)1225 383619    fax: +44 (0)1225 386838
> mailto:[log in to unmask]
> http://www.ukoln.ac.uk/ukoln/staff/p.johnston/

_____________________________________
Stuart A. Sutton, Associate Professor
[University of Washington, Box 354985]
The Information School
iSchool Research Commons
University of Washington
4311 11th Ave NE, Suite 400
Seattle, WA 98105
http://www.ischool.washington.edu