On Thu, Jan 05, 2012 at 02:10:05PM +0100, Kai Eckert wrote:
> >"DCAM Statement" reads indeed cumbersome. And you may well drop it, if
>
> +1 for dropping it, respectively change the definition to the
> definition of RDF statement. Only if that results in conflicts, I
> would think about defining "something" that replaces the old DCAM
> statement.
In order to make crystal-clear that DCAM is an "interface to", and not a
"replacement for", RDF abstract syntax, I am strongly inclined to avoid any
terminology that overlaps between the two in confusing ways -- e.g., "DCAM
statement".
How about "Slots and Boxes"? The high-level story could be:
DCAM provides an interface for designing metadata records. This interface
consists of Slots (for holding pieces of information, such as URIs and
strings) and Boxes (for grouping sets of Slots). Metadata records designed
according to DCAM -- potentially in any concrete implementation syntax --
can be straightforwardly exported as RDF triples. Even where there is no
immediate requirement to expose metadata in RDF or as Linked Data, DCAM
provides guidance for designing metadata records that are
Linked-Data-ready.
Description Set and Description are examples of Boxes. PropertyURI and
LiteralValue are examples of Slots.
I had proposed that "DCAM Statement" be replaced directly with
NonLiteralValuePattern and LiteralValuePattern (which would involve a slight
refactoring of slots), but Pete rightly pointed out that this use of "pattern"
could be confusing.
How about NonLiteralValueBox and LiteralValueBox? The story could be that
Slots descriptive of a non-literal value go into one Box, and Slots descriptive
of a literal value go into the other. As an understanding of the distinction
between "non-literal" and "literal" values is something we should not assume
from beginners, the Primer could provide an example-based interface that guides
metadata designers to the right Slots and Boxes.
Tom
--
Tom Baker <[log in to unmask]>
|