JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-ARCHITECTURE Archives


DC-ARCHITECTURE Archives

DC-ARCHITECTURE Archives


DC-ARCHITECTURE@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-ARCHITECTURE Home

DC-ARCHITECTURE Home

DC-ARCHITECTURE  February 2007

DC-ARCHITECTURE February 2007

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: [DCAM Public Comment] abstract syntax needed

From:

Mikael Nilsson <[log in to unmask]>

Reply-To:

DCMI Architecture Forum <[log in to unmask]>

Date:

Mon, 26 Feb 2007 20:36:54 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (184 lines)

Hi Al!

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 [1]. 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 [1] that require major revision
> before publication as a DCMI recommendation.
> 
> In a nutshell, DCMI needs an *abstract syntax* and not an "abstract
> model".
> 
> 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?

http://dublincore.org/architecturewiki/DCText

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 [2] and [3] (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 [3] 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:
> 
> http://isegserv.itd.rl.ac.uk/cvs-public/~checkout~/dcmi/syntax/index.htm
> l

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
the DCAM...
 

> 
> I hope that's helpful.

It is, more please :-)

/Mikael

> 
> Yours,
> 
> Alistair.
> 
> [1] http://dublincore.org/documents/2007/02/05/abstract-model/
> [2] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
> [3] 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
> Chilton
> Didcot
> 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

Top of Message | Previous Page | Permalink

JISCMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2014
March 2014
February 2014
January 2014
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
September 2005
August 2005
July 2005
June 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
November 2003
October 2003
September 2003
August 2003
June 2003
May 2003
April 2003
March 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
December 2000
November 2000
October 2000


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager