On 8/9/12 11:07 AM, Thomas Baker wrote:
Tom, thanks for writing this all up. What i think you are pointing out
here is the issue of where and how DCAM builds on RDF.
>
> I wonder if we could reduce DCAM to a one-pager that simply describes the
> notions of Description, Description Set, VES, and SES -- dropping, for example,
> the Literal and Non-Literal pattern constructs in favor of simply pointing to
> RDF. This pared-down DCAM could be consolidated with the Description Profile
> Constraint language.
Looking at the diagram, the VES and SES are subordinate to Literal and
Non-literal, so it may be hard to remove those latter from the DCAM
unless it is greatly changed. Perhaps the question is: What is the role
of these in the DCAM?
The role that I see (although I think it was over-described) is that of
providing option patterns for the RDF Object. I think that these
patterns can be described with fewer layers in the diagram by
emphasizing their function rather than their form. I'd offer a
suggestion here but I don't speak the formal language that DCAM is
written in, but I would like to see the "surrogate" and
literal/non-literal concepts replaced by value types and patterns, with
somewhere an explanation (in plain language) what those mean for
metadata development.
I also want to note that the inclusion of SES here with a URI could be
read to imply something more than rdf:Datatype. If SES=datatype, then
rdf:Datatype becomes simply one of the possible value patterns for the
Object, and further description of the SES isn't needed, it is simply
another possible value: typed data as defined in rdf:Datatype. In a
sense, I see the current DCAM as both an explanation of RDF concepts as
well as building on them, in which sense the entire "value surrogate"
area needs revision or removal.
kc
>
> Instead of trying to define such higher-level patterns in DCAM itself, these
> patterns could be documented in the form of exemplars. The challenge, then,
> would be to define a DCAM+DSP sort of language expressive enough to express
> those exemplars in a consistent and comparable way. Ideally, those exemplars
> would be machine-actionable, but they would ideally also be readable -- either
> directly, because they were written in a Pythonesque indentation style without
> brackets, or indirectly by automatic transformation into, say, a Web page.
>
> Tom
>
> [1] http://lists.w3.org/Archives/Public/public-lld/2010Nov/0114.html
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
|