Hi Pete,
OK, I hope that if the construct will go in DCAM, your explanation will somehow re-surface in the doc.
This is also back to the root of my question, also: if the construct is there, I hope "ValueString" will be used in both cases (literals and non-literals), as you're doing below. As opposed to "LiteralValueString" vs. "ValueString"...
Cheers,
Antoine
> Hi Antoine,
>
>> What's the motivation here? To me if there's no "something else" to mark (b)
>> out of (a), then there's no rationale for (b). Or at least no obvious one...
>
> I think the motivation goes back to the context in which the DCAM was created.
>
> We were trying to bridge a world of:
>
> (a) a "classical Dublin Core" "data model", only rather informally described, probably best in Tom's paper in Dlib
>
> "A Grammar of Dublin Core" http://www.dlib.org/dlib/october00/baker/10baker.html
>
> and/or in
>
> DCMI Grammatical Principles http://dublincore.org/usage/documents/principles/
>
> (b) RDF
>
> The two docs in (a) talk about "appropriate literals" or "appropriate values" but don't have any of RDF's notion of distinguishing literals from URI Refs/blank nodes.
>
> But in the DCAM we wanted structures which would enable us to make those distinctions
>
> In some cases, we simply wanted the "appropriate literal" to map to a literal object in a single triple (e.g. when used with dcterms:title, dcterms:identifier)
>
> In other cases, the "appropriate literal" was a URI of a second resource so we wanted it to map to a URIref as object in a single triple (e.g. dcterms:references etc - but only if the "appropriate literal" was a URI!)
>
> But in other cases, the "appropriate literal" was really - or we wanted to treat it in RDF as - the label of (or code for or string related in some other way to) a second resource, so we really wanted to generate the blank node and second triple with literal object
>
> So the DCAM introduced those three separate constructs
>
> Literal Surrogate/Value String
> NonLiteral Surrogate/Value URI
> NonLiteral Surrogate/Value String
>
> In the "classical Dublin Core"/"appropriate literal" model, I'm not sure those cases would always be distinguishable from the structure alone, even with some sort of property-specific processing. So I think moving from data based on "classical Dublin Core" to data based on DCAM would often require an element of "intelligent" (re)interpretation.
>
> I'm not arguing that the complexity in the current DCAM should all be "carried forward" into the new DCAM - my own preference is to see the DCAM structures and concepts as close to the RDF structures and concepts as possible, and to get rid of as much of the complexity as possible. I'm just trying to recall/reconstruct some of the background to how we ended up with what is there currently.
>
> Pete
|