Is there any chance that this DCAM work could be centered around user
tasks or goals? That is, defining things in terms of what users need
to do rather than defining a structure that is mainly theoretical.
What are the tasks that people want to perform that would be aided by
having additional structure over and above RDF? Something like:
- define a property that takes a literal value ("plain text")
- define a property that takes its value from a controlled list of text terms
- define a property that takes its value from a controlled list of
terms, each with a URI
- etc.
Once this is fleshed out, then the question becomes: what do people
need in order to create their metadata? It could even turn out that no
"AM" is needed, just a set of instructions ("design patterns"). Or
there may need to be an AM to support the design patterns. But the AM
is not an end in itself -- which is why I suggest a user-oriented
approach. Otherwise, it's DCAM 2.0, with little uptake.
People won't use it unless it is useful, and it is up to DCMI to make
its usefulness obvious. Couching the effort in terms of user tasks
rather than abstract structures is where the "use" comes in, IMO.
kc
Quoting Pete Johnston <[log in to unmask]>:
> 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
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
|