On Tue, Jan 03, 2012 at 02:19:21PM -0500, Tom Baker wrote:
> I propose to limit the entities of the DCMI Abstract Model to the following,
> and to use the same names for a DC-TEXT-inspired notation (which could be
> folded into the "technical" DCAM document and used for examples):
>
> Record
> DescriptionSet
> Description
> StatementSet - alternative suggestions welcome - this will require discussion!!
An RDF Statement -- a Subject-Predicate-Object triple -- is so significantly
different from a DCAM Statement -- an attribute-value pair plus optional
dcam:memberOf and rdf:value statements about the value -- that I'm thinking it
is perhaps unhelpful to call them both "statements".
StatementSet would capture the notion that (what is now called) a DCAM Statement
is mappable to more than one RDF Statement, and the word StatementSet is roughly
comparable to DescriptionSet. However, this is arguably sub-optimal because the
attribute-value pair at its base consists of just a Predicate and Object.
ValueDescription comes to mind as an alternative, inviting a comparison to
Description itself, which could be renamed ResourceDescription, but I don't
like that direction. The term AttributeValuePair misses the notion of
additional dcam:memberOf and rdf:value information about the value.
Might we just drop the notion of a "DCAM Statement" altogether and refer just
to Literal and Non-literal Value Patterns -- for which PropertyURIs, ValueURIs,
ValueIDs, and ValueStrings and ValueLabels, with their LanguageTag,
SyntaxEncodingSchemeURIs, and SKOSConceptSchemeURIs, would simply provide the
slots?
Tom
--
Tom Baker <[log in to unmask]>
|