Good to hear from you!
On mån, 2007-02-26 at 15:01 +0000, Miles, AJ (Alistair) wrote:
> Hi all,
> Here are some comments on . I'm sorry I haven't had time to read the
> recent discussion on this list, so these issues may already be noted.
I assume this means work on SKOS is progressing well :-)
Regarding your comments, I must say I'd like some clarifications. I
think I see what you want to have, but I fail to see why you think the
current document is fundamentally lacking in these respects.
> I believe there are serious issues with  that require major revision
> before publication as a DCMI recommendation.
> In a nutshell, DCMI needs an *abstract syntax* and not an "abstract
> My suggestions are:
> 1. Separate Syntax from Semantics
> A clear distinction must be made between an *abstract syntax* for DCMI
> metadata, and a *semantics* for DCMI metadata.
Right. I assume you agree that section 2 *does* contain an abstract
syntax (the "description model"), though mixed with a few comments of
semantic nature. Do you see anything in particular that is problematic
with that part, viewed as an abstract syntax?
> DCMI should seek to define an *abstract syntax* for DCMI metadata within
> a separate document. This document should also contain examples of how
> to map concrete syntaxes (such as DC-XML) to the abstract syntax. This
> would provide a framework for achieving *syntactic interoperability*
> which is a primary goal, and which may be achieved without any
> consideration for the semantics.
We (= mostly Pete) have been working on DC-TEXT. Have you seen that?
This is a concrete syntax, though, but fills a similar purpose.
> DCMI should define the semantics of DCMI metadata entirely in terms of a
> mapping from a DCMI abstract syntax to RDF graphs. This could be done
> within a separate document, or as part of the abstract syntax document.
I don't see why this is necessary. As long as the semantics is defined
in a way that makes it compatible with, and mappable to, RDF, we should
be fine, shouldn't we. I think the mapping is 100%, or at least 99.5.
Note that we are proposing a "domain model" on top of RDF. I know of
*no* such domain model that has actually been *defined* in RDF. Of
course you want it to be expressed in RDF so that the inferences are
valid in both worlds, but domain models are inherently idiosyncratic.
The DCMI abstract model is a way of expressing the DCMI view of the
world of metadata. It needs to be read and understood by the DCMI
community, formulated in terms that they are familiar with, etc. If not,
the model would lose acceptance immediately.
Now, the role of the DCMI abstract model, in my view, is to make sure
that we formulate this model in a way that makes it compatible with RDF
in particular. *very* compatible, even, all while keeping the
terminology of the DC community.
Now, I *do* agree that a separate document describing the *exact*
relationship with RDF in terms of inference, formal semantics, etc etc,
is a good idea, and even necessary. I just don't agree that we can usee
that as a starting point (except in an idea world, where we all be
native RDF speakers...)
> 2. Define Rules for Merging Metadata
> The DCMI must provide a definition of the correct process for *merging*
> DCMI metadata descriptions and description sets. This definition should
> be given entirely in terms of the definition for merging RDF graphs
> provided in  and  (and thus will make use of the defition of the
> mapping between the DCMI abstract syntax and RDF graphs).
I think this is an interesting suggestion, and I know your view of the
importance of merging (nothing wrong with that view!).
I do think we want to keep that discussion out of the abstract model at
this point. The question is whether it should be bound to the RDF
expression, or defined independently.
> 3. Define Valid Inference Processes
> The DCMI must define valid inference processes for DCMI metadata. These
> valid inference processes should be given entirely by the
> model-theoretic semantics for RDF/S  via a mapping from the DCMI
> abstract syntax to RDF graphs.
I think this might be a good idea, too. But I also think it's out of
scope of the abstract model itself. I certainly do *not* think the DCMI
should even try to replicate the work on RDF semantics.
> - Summary
> The DCMI must address the following goals in order:
> A. Provide a framework for syntactic interoperability of DCMI metadata.
> B. Define correct procedures for merging DCMI metadata.
> C. Define valid inference processes for DCMI metadata.
Summary from me:
A) The DCMI abstract model does contain an abstract syntax, *and* a
domain-specific semantics. I think this is correct.
B) Merging should be defined, but not in the abstract model itself.
C) Inference should be defined, using RDF semantics, but not in the
abstract modell itself.
I guess what I'm saying is that
1) The DCMI abstract model is an important point of agreement within the
DCMI community regarding the structure of DCMI description.
2) The details surrounding that model (merging, inference, etc) should
be kept *out* of that model.
3) The detailed relationship to RDF should be kept *out* of that model.
4) Your comments might point to a need to make the DC-RDF mapping
bidirectional, something I've been contemplating for a while.
> Of course, as the saying goes, one should put one's foot where their
> mouth is. So I have tried to draft a normative-style document that
> achieves these goals, with the minimum amount of duplication and
> unnecessary definition, see:
This document contains a number of grave factual errors regarding the
structure of DCMI descriptions. I do see the point, but I *don't* see
the big difference between section 4-5 and the "description model" of
> I hope that's helpful.
It is, more please :-)
>  http://dublincore.org/documents/2007/02/05/abstract-model/
>  http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
>  http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
> Alistair Miles
> Research Associate
> CCLRC - Rutherford Appleton Laboratory
> Building R1 Room 1.60
> Fermi Avenue
> Oxfordshire OX11 0QX
> United Kingdom
> Web: http://purl.org/net/aliman
> Email: [log in to unmask]
> Tel: +44 (0)1235 445440
<[log in to unmask]>
Plus ça change, plus c'est la même chose