All

Some additional thoughts and information in response to discussion on the announcemount, which I hope will clarify and stimulate further discussion:

I think that most, if not all, of the 00X element set can be used immediately to create triples from existing MARC21 records;

e.g.  <resourceURI> m21:M006c01-02 m21:musicfoc#bg .
m21:musicfoc#bg skos:prefLabel "bluegrass music" .

(Identified resource hasFormOfCompositionOfNotatedMusic "bluegrass music")

Some of the 00X properties are repeats;

e.g. m21:M008BK18, m21:M008BK19, m21:M008BK20, m21:M008BK21 allow for up to 4 values for Illustrations of Books, all taken from the same value vocabulary

e.g. <resourceURI> m21:M008BK18 m21:bookill#o .
m21:bookill#o skos:prefLabel "photographs" .

There is no priority order in the code values, so all 4 properties carry an identical semantic.

A Level 1 property might therefore simply gather the 4 Level 0 properties;

e.g. m21:M008BK18 rdfs:subPropertyOf m21:bookillustrations .
m21:M008BK19 rdfs:subPropertyOf m21:bookillustrations .
m21:M008BK20 rdfs:subPropertyOf m21:bookillustrations .
m21:M008BK21 rdfs:subPropertyOf m21:bookillustrations .

In this case, there are 8 additional properties at Level 0 with the same semantic:

m21:M006a01, m21:M006a02, m21:M006a03, m21:M006a04, M006t01, M006t02, M006t03, M006t04

so they could also be declared as sub-properties of the hypothetical m21:bookillustrations.

The entailed instance triples, 

e.g. <resourceURI> m21:bookillustrations m21:bookill#o .
etc.

can then be used directly by an application which asks "What resources contain photographs?".

Sure, this can also be achieved by mapping legacy data straight into Level 1, but then some subtle semantic differences between the 006/007/008 tags would be lost.

Other Level 1 elements might support aggregated statements, where specific Level 0 properties (mostly 1XX-8XX) need to be aggregated, often in sequence, to preserve information; this is always the case where a MARC21 tag is repeatable and contains more than one subfield. This issue is not confined to MARC or its encoding; it is common to all schemas, such as RDA and ISBD, which allow combinations of elements to be repeated when describing a single resource. For more information, see [1]

More generally, one of the approaches we are looking into is the use of DC Application Profiles and the DC Abstract Model.

One of the assumptions MMA is making is that it is not necessary to create instance triples from MARC21 (or, indeed, any other format) records as an all-in-one, one-off activity. The process can be carried out in ad hoc stages, provided a resource URI has been established for the subject of the record, to be used as the subject of each triple.

I myself see the minting and maintenance of resource URIs as a priority, to prevent needless duplication of URIs for the same thing, and avoid needless expense on local minting and maintenance. I raised this on the W3C LLD XG listserv [2]. Since then, the idea has been discussed by the IFLA Namespaces Task Group, and has recommended that the IFLA Bibliography Section consider coordinating or encouraging the minting of resource URIs for things described in national bibliographies.

In particular, the 0XX element set can be used immediately to support this;

e.g. <resourceURI m21:M015__a "[National bibliography number statement]" . 
<resourceURI> m21:M020__a "[ISBN statement]" .
<resourceURI> m21:M020__z "[Invalid or cancelled ISBN statement]" .

(The identifiers given in the string objects of these triples are the ones that will be present in the item-in-hand, and/or in local MARC21 records, so can be used to look-up and obtain the resource URI.)

Note that the objects of these triples need to be treated as strings in the first instance, as the number can be followed by a free-form text qualifier within the MARC21 subfield value (which is why I have referred to them as statements, and not numbers).

Sure, this is low-hanging fruit - but why are holding back picking it until we can strip the whole tree?

Another assumption that MMA is making is that we can't and won't predict what use others might make of these element sets and value vocabularies.

Please note that Diane, Jon and I are busy with preparations and travel for DC-2011 next week. We will be presenting some of this stuff at the conference, and we are looking forward to discussing it face-to-face with fellow delegates as well as continuing discussion on the listservs.

Cheers

Gordon

[1] http://www.dlib.org/dlib/january10/hillmann/01hillmann.html

[2] http://lists.w3.org/Archives/Public/public-lld/2011Apr/0125.html