Hi Antoine,
> Thanks, Pete! I think it is clearer to me, now.
> Though it may look weirder, in a way. The production rules are the same for
> DC-Text, aren't they? I is just the mapping to RDF that changes.
Ah, OK. I guess I misunderstood what you meant by production rules :)
> In that case, I would have rather expected the distinction to be made
> strongly in DCAM (where is matters, if one wants a good alignment with RDF
> there)
I think this was the motivation (or one of them) for introducing the "non-literal value surrogate" and "literal value surrogate" containers.
The previous version of the DCAM
http://dublincore.org/documents/2005/03/07/abstract-model/
omitted them and it wasn't clear whether "value string" was supposed to map to
(a) the simple single triple, literal-as-object case
(b) the two triple, second triple with rdf:value predicate and literal object case
(c) sometimes (a) and sometimes (b) depending on whether other components were present (!)
> and hidden in DC-Text (where it does not really matter, unless DC-
> Text is meant as a complete implementation of DCAM and all the distinctions
> it could make).
DC-Text was intended to be a complete implementation of DCAM.
IIRC, I/we did briefly toy with including constructs like
Statement (
LiteralValueSurrogate (
ValueString( )
)
)
Statement (
NonLiteralValueSurrogate (
ValueString( )
)
)
but it just seemed simpler to "flatten the structure down" to
Statement (
LiteralValueString( )
)
Statement (
ValueString( )
)
It's probably not ideal, or at least it's probably incomplete in a "formal" sense, e.g. I think we left undefined how/whether to interpret "contradictory" cases like
Statement (
LiteralValueString( )
ValueURI( )
)
Pete
