On Fri, Nov 28, 2008 at 10:41 AM, Pete Johnston <[log in to unmask]>
> My main concern is that I feel there is some contextual information
> missing which makes some of the later sections of the document rather
> more difficult to understand than they might be.
Pete, thank you for your comments.
We tried before to include many of those background concepts in this
document, but it became utterly unwieldy -- and totally recursive,
kind of like having to explain everything else in the DCMI universe in
this one document. I think we have to see the DCMI documentation as a
set, with no one document standing entirely alone.
That said, there are documents and explanations that are missing at
this moment in time. We desperately need a document on the creation of
vocabularies. I think we need a document that explains the WHY of the
DCAM, so that people understand the motivation behind it.There needs
to be a better description of literal and non-literal with examples
and practical uses. I do think we need to explain concepts like
"descriptions" -- and we might be able to add a phrase in this
document that covers that, but a full explanation should be outside of
this document, which needs to focus on the creation of Application
Profiles.
> Section 5 deals with the selection or definition, not just of any
> metadata terms, but of metadata terms of the specific types used used in
> RDF and in DC description sets. So I think it's important to have at
> least some discussion of what those types of terms are, some of their
> characteristics (e.g. range/domain relationships) and how the terms are
> referenced in combination in DC metadata, before the current text of
> section 5.
This is why we so desperately need the document on vocabularies and
their creation. Explaining all of this is a document in itself, and
should contain many examples. Unfortunately, a short explanation of a
couple of paragraphs will probably serve more to confuse than
enlighten the readers of this document. You are right that the
background knowledge that they need is extensive and complex. I don't
think we can give readers that knowledge with some short explanations.
We COULD alert them to the fact that certain concepts are in play that
they need to be aware of, even though we can't cover it here. That
way, users who are coming at the document with a different model will
be given notice that they can't apply their current model thinking to
the DCAP.
I agree that the table in section 5 is a huge leap from the text
around it. At one point we had that table in the appendix, closer to
the more technical explanation. Perhaps we could more obviously point
from it to the explanatory parts in the Appendix? Or move it back
there? (But we have to recognize that many readers will not reach the
appendix.)
> Similarly in section 6, and perhaps even more so than for the previous
> section, understanding the discussion of "Description Templates" and
> "Statement Templates" really hinges on understanding what "descriptions"
> and "statements" are. So I think a description of the DCAM description
> model is required before this part of the document. It's difficult to
> understand why these particular sorts of templates are being discussed
> unless I understand the nature of the structures they are templates for
> :-)
Are there definitions we can use here? In the DSP document it says:
* Description templates, that contains the statement
templates that apply to a single kind of description as well as
constraints on the described resource.
* Statement templates, that contains all the constraints on
the property, value strings, vocabulary encoding schemes, etc. that
apply to a single kind of statement.
The DCAM has:
statement
An instantiation of a property-value pair made up of a property
URI (a URI that identifies a property) and a value surrogate.
description
One or more statements about one, and only one, resource.
Do we need to include these definitions in the document, maybe in a
definitions section? (Although I'd want to change the DCAM statement
one to better use the language of the DCAP document.)
>
> To some extent this influences section 4 too: the fundamental nature of
> RDF - making assertions about relationships between resources -
> conditions the nature of the models we use.
We decided not to explain RDF in this document. I can look for a place
to say something about relationships between resources without going
into a full explanation of RDF (which once again gets very long and
complex).
>
> I recognise that Sections 1 and 2 do make references to the fact that
> the DCAM and RDF provide the foundations for the DCAP concept, but these
> are largely passing references, and I think the document needs to
> articulate more fully what this means, by providing more information
> about those foundations: the core principle that we are making
> assertions about relationships between resources; the DCAM vocabulary
> model/RDF Schema; and (especially) the DCAM description model.
>
> I can imagine this being provided as a new section between the current
> sections 4 & 5 (on the basis that the current section 5 is really where
> the material that is dependent on this begins), but it could equally
> well be provided earlier in the document, as part of section 2 or as a
> new section between the current sections 2 and 3?
We had those sections in the document, but we took them out. A lot of
it has to do with narrative -- you want a document to go forward in a
somewhat straight line. A lot of back and forth to cover background
information will lose the momentum and the reader's attention. I will
look for places where we can put a sentence or two, but whole sections
of background information will make the document much less readable.
And note that we have gotten praise for the readability of this
document, so we don't want to lose that.
kc
--
-- ---
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
mo.: 510-435-8234
------------------------------------
|