> From [log in to unmask] Fri Apr 19 02:28 MET 2002
> Date: Fri, 19 Apr 2002 09:13:54 +0900
> From: Sugimoto Shigeo <[log in to unmask]>
> Subject: Re: Attributes of DCMI metadata terms
> Comments: To: [log in to unmask]
> Comments: cc: [log in to unmask]
> To: [log in to unmask]
>
> Dear Tom,
>
> I have a question on the attributes from the viewpoint of multilingual
> description. I'm CCing this message to DC-international (localization
> and internationalization group) since the subscribers might have interests
> in this issue.
>
> Given that a term is translated into a language(s) which is officially
> approved by a local community(ies), do you mean that "See also" is to
> be used to point the translation (or translations)?
> Or, no linking from the central description to local but official descriptions?
Dear Shigeo,
think it's just a matter of proper documentation, that one should be able to
find translations - in particular those, with an official standing - from
the DC web-site.
It's not clear to me, whether you address RDF or XML schema stuff -
More precisely: Is it "rdfs:seeAlso" what you want to have in some RDF
schema as part of term definitions or do you want some pointer as
part of the metadata for a schema as such?
rs
>
> I'm thinking that DC Term descriptions in non-English languages could have
> the same set of descriptive elements, e.g. "Label", "Definition", etc..
> And, in addition, each description of an element could have a link to
> the corresponding element to the Official description in English,
> which maintained in the central registry.
>
> Thank you,
>
> -- Shigeo
>
> In <20020417162514.A1856@LEPIDUS>, [log in to unmask] wrote:
> >> Date: Wed, 17 Apr 2002 16:25:14 +0200
> >> Reply-To: "This list, which supersedes dc-datamodel, dc-schema, and
> >> dc-implementors, i" <[log in to unmask]>
> >> From: Thomas Baker <[log in to unmask]>
> >> Subject: Attributes of DCMI metadata terms
> >> To: [log in to unmask]
> >>
> >> Dear all,
> >>
> >> Attached at the end of this message is an appendix showing
> >> which attributes have been used to describe DCMI terms
> >> since 1996. Based on these sets of attributes, and in light
> >> of current discussion on this list, I suggest here a set of
> >> attributes for "DCMI term declarations" and suggest that a "See
> >> Also" link point to further background information collected
> >> by the Usage Board as documentation for new-term proposals.
> >>
> >> I am currently working on the long-awaited Consolidated Term
> >> Declaration (or perhaps Dictionary) that brings DCMES 1.1,
> >> the Dublin Core Qualifiers, and the terms approved by Usage
> >> Board in 2001 into one document using a consistent set of
> >> attributes. Finishing that task depends on resolving the
> >> problem discussed here.
> >>
> >> I would appreciate if some of you could give this a careful
> >> read from various points of view -- Usage Board, Registry,
> >> and Architecture (eg, RDF schemas). A caveat: I have not
> >> tested this by formatting all of the DCMI terms yet --
> >> uh, I'd rather get consensus on the attributes first...
> >> In particular, I'm not very happy with the jargon for "name of
> >> term", "namespace URI of term", and "URI of term's namespace".
> >>
> >> The consolidated term document will supersede all previous
> >> documents and become the definitive declaration of DCMI terms
> >> and therefore the basis for any machine-understandable
> >> representations thereof.
> >>
> >> I would also like to hear opinions on where this set of
> >> attributes should reside -- perhaps in a special Usage Board
> >> document, though it is not clear to me that the Usage Board
> >> should be the group to maintain the schema attributes.
> >>
> >> Also, I cite what I see as the major documents setting the
> >> context for this set of attributes:
> >> http://dublincore.org/documents/dcmi-namespace/
> >> http://dublincore.org/usage/documents/process/
> >> http://dublincore.org/usage/documents/mission/
> >> Am I overlooking any?
> >>
> >> I propose:
> >>
> >> ------------start-----------------------------------------------
> >> A "DCMI term declaration" (see
> >> http://dublincore.org/documents/dcmi-namespace/) should contain:
> >>
> >> Label The human-readable label assigned to
> >> the qualifier.
> >> Definition The definition of the term.
> >> - or -
> >> A statement that represents the concept
> >> and essential nature of the term.
> >> Comment Additional information associated with
> >> the term.
> >> - or -
> >> Information concerning the possible
> >> application of the proposed term
> >> See Also A link to more information about the term.
> >>
> >> Name of term The unique token assigned to the term
> >> URI of terms's eg, http://purl.org/dc/elements/1.1/ or
> >> namespace http://purl.org/dc/terms/
> >> Namespace URI of term eg, http://purl.org/dc/elements/1.1/title or
> >> http://purl.org/dc/terms/audience
> >> Status Cross-Domain, Domain-Specific, or Obsolete
> >> (typology to be taken from
> >> http://dublincore.org/usage/documents/process)
> >> Type of term Element, Element Refinement, or Encoding Scheme
> >> (typology to be taken from
> >> http://dublincore.org/usage/documents/mission/)
> >> Term qualified If an Element Refinement, the Element qualified
> >>
> >> One "See Also" link should point to the following
> >>
> >> Examples Examples of use of the proposed term, making
> >> clear what type of literal values are expected
> >> Why needed A justification of the need for the proposed term
> >> Related DCMI terms A discussion of possible overlap with existing
> >> terms
> >> Related non-DCMI An annotated listing of related terms in non-DCMI
> >> terms metadata vocabularies
> >> Impact on An annotated listing of existing applications that
> >> applications could be affected by recognition of this term
> >> About the proposers A pointer to a description, in standard
> >> form (to be specified) of the working group or
> >> organization putting forward the proposal: its
> >> scope, aims, a brief history, current status,
> >> and a pointer to archives.
> >>
> >> As per Roland's suggestion, the "namespace URI of term" should
> >> not be a "clickable" link on any Web pages made from this term
> >> declaration to avoid the usual questions about "what is at the
> >> end of the namespace".
> >>
> >> ------------end-----------------------------------------------
> >>
> >> Thanks,
> >> Tom
> >>
> >>
> >> APPENDIX
> >>
> >> -------------------------------------------------------------
> >> Elements Version 1.0, September 1998
> >> http://dublincore.org/documents/1998/09/dces/
> >> and
> >> RFC 2413, September 1998
> >> http://www.ietf.org/rfc/rfc2413.txt
> >> -------------------------------------------------------------
> >>
> >> Except for "Label", the attributes of the metadata terms were
> >> not explicitly labelled or discussed in Version 1.0 or RFC 2413.
> >>
> >> [Name?] a natural-language name for the element
> >> Label: a "formal single-word label" for use in
> >> "encoding schemes"
> >> [Definition?] a definition was provided
> >>
> >> -------------------------------------------------------------
> >> Elements Version 1.1
> >> http://dublincore.org/documents/1999/07/02/dces/
> >> -------------------------------------------------------------
> >>
> >> This version recast the element definitions using attributes
> >> defined in ISO/IEC 11179:
> >>
> >> Name The label assigned to the data element
> >> Identifier The unique identifier assigned to the data element
> >> Definition A statement that clearly represents the concept and
> >> essential nature of the data element
> >> Comment A remark concerning the application of the data element
> >>
> >> The following ISO/IEC 11179 attributes were assumed to hold for
> >> all of the elements:
> >>
> >> Version The version of the data element, here "1.1" (for all)
> >> Registration The entity authorised to register the data element,
> >> Authority here "Dublin Core Metadata Initiative" (for all)
> >> Language The language in which the data element is specified,
> >> here "en" (for all)
> >> Obligation Indicates if the data element is required to always
> >> or sometimes be present (contain a value), here
> >> "Optional" (for all)
> >> Datatype Indicates the type of data that can be represented
> >> in the value of the data element, here
> >> "Character String" (for all)
> >> Maximum Indicates any limit to the repeatability of the data
> >> Occurrence element, here "Unlimited" (always)
> >>
> >> -----------------------------------------------------------------------
> >> Dublin Core Qualifiers, July 2000
> >> http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/
> >> -----------------------------------------------------------------------
> >>
> >> The introduction explained that the properties of qualifiers --
> >> in particular the terms Name and Label -- differed with respect
> >> to those defined for the Dublin Core Metadata Element Set
> >> Version 1.1, reflecting a decision to bring Dublin Core schema
> >> terminology in line with terminology in the XML community to
> >> promote easier integration of Dublin Core schemas in XML and RDF
> >> environments.
> >>
> >> Name The unique token assigned to the qualifier.
> >> Label The human-readable label assigned to the qualifier.
> >> Definition A statement that represents the concept and essential
> >> nature of the qualifier.
> >> Comment Additional information associated with the qualifier
> >> (if available).
> >> See Also A link to more information about the qualifier (if
> >> available).
> >>
> >> -----------------------------------------------------------------------
> >> Current requirements for new-term proposals to Usage Board
> >> http://128.253.121.110/DC-UB/DC-UBprocess8.html
> >> -----------------------------------------------------------------------
> >>
> >> Name A suggested unique token for use in encodings
> >> Label A suggested human-readable label for the proposed term
> >> Definition The definition of the term
> >> Comment Information concerning the possible application of the
> >> proposed term
> >> Examples Examples of use of the proposed term, making clear what
> >> type of literal values are expected
> >> Type of term Is the proposed term an "element," or an "element
> >> refinement" (as defined in
> >> http://dublincore.org/usage/documents/mission.shtml)
> >> [NOTE: Encoding schemes will be registered using a
> >> separate process]
> >> Term qualified If the proposed term is a element refinement, which term
> >> does it qualify?
> >> Why needed A justification of the need for the proposed term
> >> Proposed status Is the term proposed as Domain-Specific or Cross-Domain?
> >> Related DCMI terms A discussion of possible overlap with existing terms
> >> Related non-DCMI An annotated listing of related terms in non-DCMI
> >> terms metadata vocabularies
> >> Impact on An annotated listing of existing applications that
> >> applications could be affected by recognition of this term
> >> About the proposers A pointer to a description, in standard
> >> form (to be specified) of the working group or
> >> organization putting forward the proposal: its scope,
> >> aims, a brief history, current status, and a pointer
> >> to archives.
> >>
> >>
> >> --
> >> Dr. Thomas Baker [log in to unmask]
> >> Institutszentrum Schloss Birlinghoven mobile +49-171-408-5784
> >> Fraunhofer-Gesellschaft work +49-30-8109-9027
> >> 53754 Sankt Augustin, Germany fax +49-2241-14-2619
>
>
> =========================================================
> SUGIMOTO, Shigeo, Ph.D.
> Professor
> University of Library and Information Science (ULIS)
> postal address: Tsukuba, Ibaraki 305-8550, JAPAN
> phones: +81-298-59-1348(office), +81-298-59-1556 (lab.)
> +81-298-59-1090(ULIS, Research Assistance Office)
> fax: +81-298-59-1093 email: [log in to unmask]
>
|