Diane I. Hillmann wrote:
> Folks:
> 
> This looks interesting, given our recent discussions on accessibility.

That data structure (or a variant of it) has (I think?) been the basis 
for the DC-Accessibility WG's work.

However, mapping that tree data structure into the DC/RDF 
statement/property-value model(s) isn't entirely straightforward. I 
think adopting an approach which takes each component in that structure 
individually in isolation from other components and seeks a simple 
correspondence to a term in the statement/property-value model is 
probably going to hit problems.

e.g.

A first example:

1.1.1 original access mode ("An access mode through which the 
intellectual content of the resource is communicated, not including any 
adaptations.") might - I say might because it depends on how this 
information relates to information elsewhere in the data structure - be 
mapped to a property of the "original resource" (resource:r 
has-access-mode mode:m).

But then

1.1.2 access mode usage ("The role of a primary access mode with respect 
to the intellectual content of a resource.")

This makes things more complex: a resource might have multiple modes, 
each "playing" diff roles. So this impinges on the way you map 1.1.1 
into the DC model. One way of doing it _might_ be to have two properties 
has-informative-mode, has-ornamental-mode (and forget about has-access-mode)

resource:r has-informative-mode mode:m
resource:r has-ornamental-mode mode:m

A second example:

1.13.1 adaptation type ("Nature or genre of the adaptation.") So suppose 
there are two resources: the "original resource" and the "adapted 
resource". How do we map this "adaptation type" info into the 
property-value model. Is it a property of the "original resource"? I 
don't think so. Is it a property of the "adapted resource"? Maybe....

1.13.2 original access mode (This includes the note: "It indicates the 
access mode of the original resource that is being adapted by this 
described resource. For example, if the described resource is a caption 
for a video, then this element would be used to indicate that the 
original access mode that is being adapted is the audio component of the 
original video.") Hmm.... so, after some discussion on dc-accessibility 
I _think_ this is saying that - for a single "adapted resource" - 
different "access modes" of the "original resource" are subject to 
different "types of adaptation" (the auditory mode in the original is 
subject to an adaptation type of textual (e.g. adding 
captions/subtitles); the tactile mode in the original is subject to an 
adaptation of type visual (e.g. adding diagrams?); etc).

1.13.7 education level. Of what? Of the original resource? of the 
captions/subtitles?

And so on.

Also, obviously, we need to be aware of "false friends": the "coverage" 
element in that spec has nothing to do with the dc:coverage property.

If this information which is expressed in that tree data structure is to 
be preserved in a representation designed using the 
statement/property-value model, this does require

(a) a full understanding of what information that tree data structure is 
conveying (which I think can be quite subtle, especially for those of us 
not fully "engaged" with that "domain" and its requirements); and
(b) a very careful handling of how the components in that data structure 
are mapped into properties/classes/datatypes.

If I had one "niggle" about that document, it would be that it is 
perhaps a bit thin on describing the "functional requirements" that are 
being supported/satisfied by that data structure. What does capturing 
this (quite complex/detailed in some respects) data enable a software 
application to do? I understand the general principle about matching 
context-/role-sensitive user preferences to resource characteristics. I 
mean more specifically, what does my application do with e.g. (taking a 
couple of components pretty much at random):

1.13.4 representation form = "enhanced"
1.14 support tool = "note taking"

Cheers
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/