Just to muddy up the water with a couple more issues that impact how we
express Relation ...
1) By adding the concept of "Identifier" to Relation we will limit the
scope of Relation. The current definition and proposed syntax limits
Relations to being based on the Identifier element. Admittedly, _most_ of
the time there will be an identifier, but conceptually, there will be
situations where it will be desirable to create relationships between
resources based on some other element. I hate to see us narrow the design
unnecessarily.
Current Definition & Syntax - the only thing to which a relationship can be
indicated is another resource that has an Identifier:
Definition:
An _identifier_ of a second resource and its relationship to the present
resource. This element permits links between related resources and
resource descriptions to be indicated. ...
Syntax:
<meta name="DC.Relation.Identifier"
content="http://purl.org/metadata/dublin_core_elements">
<meta name="DC.Relation.Type" content="IsBasedOn">
The previous definition and syntax left much more flexibility:
Definition
Relationship to other resources. The intent of specifying this element is
to provide a means to express relationships among resources that have
formal relationships to others, but exist as discrete resources themselves.
For example, images in a document, chapters in a book, or items in a
collection.
Syntax
<meta name="DC.Relation.IsBasedOn"
SCHEME="URL"
content="http://purl.org/metadata/dublin_core_elements">
2) By adding a new and different semantic style (different from any of the
other elements), we are making DC more complex and making the tool
creators' job more difficult.
We already have two mechanisms for refining the elements: qualifiers and
SCHEMEs. This introduces a third mechanism for refinement. Do we really
need another?
|