Sorry to lag behind the conversation a bit... I'm only seeing e-mail late
at night at the moment...  :-(

I feel the need to express some worries about Stu's posting, below,
picking up points that others have also alluded to.

My understanding was that DC-simple (or whatever we call it) was
effectively that which is enshrined in our first RFC. i.e. NO MORE (and no
less) than the names and definitions of the 15 elements, expressed in an
implementation-neutral manner.

QUALIFIED DC, as expressed in the drafts of our third and fourth (and
fifth?) RFCs, which some of you have seen, and which you'll all see just
as soon as the current storm dies down, is something else. QUALIFIED DC is
a series of recommendations/guidelines on the way in which the Canberra
Qualifiers of SCHEME, LANG and SUBELEMENT can be used to enhance the
richness of Dublin Core. RFC 3 also includes a list of 'core' SUBELEMENTS
which are likely to be of generic use across the community and some
thoughts on why/how SCHEME should be used. This list of SUBELEMENTs is (a
bit) longer than the version Stu has derived from it, below.

Simple DC is, basically, PURE and SIMPLE. Qualified DC allows people to
add richness, both from a set of 'core' additions, and on their own,
within an established framework.

As my train-, meeting- and tiredness-addled brain reads Stu's posting, it
is trying to encompass the simplicity of DC simple and the richness of
Qualified DC in a single thing which, thus, FAILS to be either. It's too
complex for the minimalists, and too restrictive for the rampant
extenders.

Can we not have the (surely, going by the various working group postings,
VERY nearly finished) old two-tier model back?

More contributions at some ungodly hour TOMORROW night...

Paul

On Tue, 27 Jan 1998, Weibel,Stu wrote:

> Folks,
> 
> Due to the shortness of time, I am bringing some issues for finalization
> to the entire list from some of the working group lists.  This message
> has relevance for many of the WGs: 
> 
>   Subelements
>   Date
>   Relation, and 
>   Coverage
> 
> Please note that it is not my intention to set aside the arduous work of
> many in forging positions around these issues, but it is my strong
> believe that for the purposes of the Finnish Finish, that the results of
> these groups should be pared down to their simplest representations.
> 
> The special requirements that others have brought to the discussion must
> find accomodation, but I think it is NOT in DC-Simple that these needs
> should be met.  Remember, above all, we must have a succinct, coherent
> message for would-be adopters:  a path forward for the adoption of
> simple metadata that has as few ifs-ands-and-buts as possible, and an
> evolutionary path for those with more complex objectives.
> 
> Thanks for looking closely at these.  I need to pin all this stuff down
> by the end of this week so I can finish the report next week.
> 
> NOTE BENE:  If you wish to lodge support or criticism of some aspect of
> this position, please address ONE TOPIC per message, and indicate the
> topic clearly in the subject message.  I will be coordinating these
> things on a very short time frame, and will miss important messages if
> we're not careful about threading of messages.
> 
> let the slings and arrows begin
> 
> regards,
> 
> stu
> 
> --------text taken largely from Paul Miller's and John Kunze's working
> groups -------------------------
> 
> A list of widely applicable subelements for the Dublin Core
> 
> Implementors are free to develop their own subelements in order to meet
> specific local requirements. However, 
> while application of numerous subelements to the Dublin Core is likely
> to increase its value to any one application area or subject grouping,
> the same action is equally likely to reduce the potential for
> interoperability between domains. As such, the addition of subelements
> to the 15 core elements of Dublin Core should be kept to a minimum and
> should be used ONLY when there are compelling local reasons to support
> such refinements.
> 
> It should also be emphasized that applications may simply collapse all
> subelements into their parent element, and definition of subelements
> should be deployed with this in mind.
> 
> Elements intended to extend the scope and functionality of Dublin Core
> beyond the original 15 elements (rather than refining some aspect of the
> existing elements) should adopt element-set extension strategies.  The
> Resource Description Framework is evolving to meet these needs in the
> Web, and several instances of such development are now evolving.
> 
> Nonetheless, early implementers have identified requirements for certain
> key subelements. Rather than encourage proliferation of these common
> subelements, with each application employing slightly different
> nomenclature and semantics, some of the most commonly used subelements
> are identified here and presented in a standardised form.  As can be
> seen, most of the 15 elements remain unqualified.
> 
> The list of 'approved' subelements presented here does not in any way
> exhaust the possibility of such elements, but every attempt will be made
> to keep this list intuitive and succinct.  Note that applications
> wishing to promulgate a formal set of additional elements can do so by
> specifying a formal scheme enumerating such subelements.  Wide adoption
> of a given scheme (or lack of adoption)is one mechanism for the
> marketplace to signal desireable evolutionary paths for subelements,
> either within bounded communities or more generally.
> 
> TITLE
>  
>   Title.Alternative
> 
>   Used for any titles other than the main title; including subtitle,
> translated title, series title, vernacular name, etc.
>  
>  
> CREATOR
>  
>   Creator.Name
> 
>   The name of a person or organization primarily responsible for
> creating the intellexctual content of the resource.
>  
>   Creator.Address
> 
>   An electronic or physical address for the individual or oganization
> specified in Creator.Name.  This could be an electronic mail address,
> web page URL, postal address, etc., and might be further defined by use
> of a SCHEME.
>  
> SUBJECT
>  
>   No SUBELEMENTs at present.
>  
> DESCRIPTION
>  
>   No SUBELEMENTs at present.
>  
>  
> PUBLISHER
>  
>   Publisher.Name
> 
>   The name of a person or organization associated with the publication
> of the resource.
>   
>   Publisher.Address
> 
>   An electronic or physical address for the individual in question. This
> could be an electronic mail address, web page URL, postal address, etc.,
> and is most useful if further defined by use of a SCHEME.
>   
> CONTRIBUTORS
>  
> Contributors.Name
> 
> The name of a person or organization (not specified in a Creator
> element) who has made a contribution to the intellectual content of the
> resource.
>  
> Contributors.Address
> 
>  An electronic or physical address for the person or organization in
> question. This could be an electronic mail address, web page URL, postal
> address, etc.,
> and might be further defined by use of a SCHEME.
>   
> DATE
> 
> DC.Date.Created
>  
>   Date the resource was made available in its present form.  This is the
> default notion of the DC.Date field.  It should only be qualified
> further as DC.Date.Created when there are additional date subfields
> specified.
>  
> DC.Date.Accepted
>  
>   Date of acceptance (e.g., for a dissertation, manuscript, or treaty)
> of the resource.  The date assigned by a formal authority to signify
> official acceptance.
>  
> 
> DC.Date.Valid
> 
>   Valid entries here include a range of dates (start date and end date)
> specifying a range of dates during which the information in the resource
> is asserted to be valid.
> 
> DC.Date.ValidFrom
> 
> A single date entry specifying the first date on which the information
> in the resource is asserted to be valid.
> 
> DC.Date.ValidUntil
> 
>   A single date entry specifying the last date on which the information
> in the resource is asserted to be valid.
> 
> 
> 4.3.8  TYPE
>  
>  No SUBELEMENTs at present.
>  
>  
> 4.3.9  FORMAT
>  
>  No SUBELEMENTs at present.
>  
>  
> 4.3.10  IDENTIFIER
>  
>  No SUBELEMENTs at present.
>  
>  
> 4.3.11  SOURCE
>  
>  No SUBELEMENTs at present.
>  
>  4.3.12  LANGUAGE
>  
>  No SUBELEMENTs at present.
>  
>  
> 4.3.13  RELATION
> 
> The RELATION element logically requires three components: two entities
> and a named relationship that links them.  The base entity is the
> resource described by the metadata.  The target entity is separate
> object that should be identified  in an unambiguous way with a globally
> unique identifier (see the IDENTIFIER element).
> 
> Many communities have identified relationship hierarchies specific to
> their fields of endeavor, and it is expected that scheme-qualified
> relationship specifications will come to be used in domain specific
> applications.  Unqualified relation specifications should chose from
> among the following relation types for DC-Simple applications:
> 
>  
>  Relation.IsPartOf [TARGET RESOURCE IDENTIFIER]
> 
>  The resource being described is physically and/or logically part of a
> larger resource, referred to by this use of the element.
>  
>  Relation.HasPart [TARGET RESOURCE IDENTIFIER]
> 
>  The resource being described physically and/or logically contains one
> or more constituent resources, referred to by this use of the element.
>  
>  Relation.IsVersionOf [TARGET RESOURCE IDENTIFIER]
> 
>  The resource being described is an historical state or edition of an
> earlier resource by the same creator, the earliest instantiation of
> which is referred to by this use of the element.
>  
>  Relation.HasVersion [TARGET RESOURCE IDENTIFIER]
> 
>  The resource being described is the earliest edition of a resource
> later altered through further editions, one of which is referred to by
> this use of the element.  As a practical matter, this will be unusual,
> given that it would require updating of existing metadata, but automated
> versioning systems might make good use of such a relation.
>  
> 4.3.14  COVERAGE
> 
> For the purposes DC-Simple, the only practical solution appears to be
> the inclusion of a place name or epoch (period) name selected from a
> controlled vocabulary (a gazetteer, for example, of national or
> international scope.  These are the most widely anticipated uses of such
> an element for discovery.
> 
> It is recognized that many other means of specificaction of coverage are
> possible (epoch names, geographical coordinate systems, polygonal
> specifications, and others), but it is expected that these will be
> outside the scope of common usage and should be elaborated as registered
> schemes for the specific applications that grow around them.
> 
>  
> Coverage.PeriodName
> 
>  The resource being described is from or related to a named historical
> period, referred to by this use of the element.
>  
> Coverage.PlaceName
> 
>  The resource being described is associated with a named place,
> identified by this use of the element.
>   
>  
> 4.3.15  RIGHTS
>  
>  No SUBELEMENTs at present.
> 
> 
> 


  == paul miller ================== [log in to unmask] ==
   collections manager, archaeology data service, king's manor
   york, YO1 2EP, UK                  tel: +44 (0)1904 43 3954
  == http://ads.ahds.ac.uk/ahds/ ==== fax: +44 (0)1904 43 3939 ==