Attribute Inclusion Criteria (was: Attributes in Prelim DAV Spec)

>Danger! Here Be Dragons!

Agreed.

># This group must define a fairly robust set of attributes. Else everyone
># will invent their own and it will take forever before things sort
># themselves out.
>
>Having been at the Dublin meeting that tried to define the Dublin core
>and watched what's happened since, I think this would be a poor
>choice: there's no reason to believe that _this_ group could converge
>faster on an identical problem. Why not just use the Dublin Core, for
>that matter? Or the DMA set? Or ... well, see, part of the problem is
>that there are so many core attribute sets around! Which to choose
>from? Add another?

First, for those who were not at the Dublin meeting (I was not, but Roy
was, and he has described it to me), the homepage of the meeting is
available at:

http://www.oclc.org:5046/research/dublin_core/

According to Roy, the meeting was held in Dublin, Ohio, where it was "damn
cold." :-)  It was organized by Stu Weivel of OCLC, and the project has a
definite digital library influence.

An overview of the attributes recommended by this effort can be found in
the document, "Dublin Core Metadata Element Set: Reference Description."

http://purl.org/metadata/dublin_core_elements

These attributes have been unified into an extensible naming scheme which
is described in the document, "A Proposed Convention for Embedding Metadata
in HTML," available at:

http://www.oclc.org:5046/~weibel/html-meta.html

Since the drafts produced at these meetings represent the result of several
thousand person hours of effort, it seems wise to use as much of their work
as we can in our distributed authoring and versioning effort, and we should
certainly have a good reason for NOT using their results.

>I'm guessing you won't take my advice that these things are ratholes
>and we should desist from thinking we can solve them quickly, and

I agree that this is a rathole, but one we do have to go down.  However,
before we do, we need to set explicit bounds for how far we go into the
hole.

In order to meet the distributed authoring and versioning requirements, we
do need to have some attributes whose name and semantics are precisely
defined in the specificaiton.  As two examples, precisely defined
attributes are necessary to support access to the source of a resource, and
to support lock discovery.

Beyond those attributes which are integral to our technical approach for
meeting the requirements, there are attributes which seem to crop up in
most "core" attribute/metadata sets.  "Author" is one, "Last Modified" date
is another.  Of these, some require standardization on the data format so
their use is interoperable.  For example, any date requires agreement on
the format of the date encoded into the attribute.  Is it # of seconds
since 1900?  Is it a string date (and which string date format?).

One way of limiting the size of the attribute rathole is to have clearly
defined criteria for the inclusion of an attribute into the DAV
specification.  To this end, I propose the following inclusion criteria:

An attribute may be included in the distributed authoring and versioning
specification if it meets one of the following two conditions:
1) The attribute must be integral to the technical approach described in
the specification OR must be required to directly satisfy a distributed
authoring and versioning requirement.
2) The data format of the attribute must be specified to ensure
interoperability of distributed authoring tools AND the data format for the
attribute must not have been previously defined in an open specification
AND the attribute must be in use in an existing Configuration Management or
Document Management system.

Examples:
LockInformation - OK - satisfies requirement 1, since it is integral to the
technical solution for satisfying the requirement for providing a means of
discovering which locks are active on a resource.
Date - OK - even though this is defined as part of the Dublin core, I could
not find where the date format is specified.  Hence, it would be OK to
include in the spec. a  description of how DA tools should interpret the
data of this attribute.  Many existing systems have a Date attribute,
Continuus/CM is one.
Author - NO - it is allright and interoperable to interpret this attribute
as an opaque string, so it should not be included in our spec., especially
since it was previously defined in the Dublin core.

Attributes which do not meet the criteria outlined above should be
described in a separate document. If you are interested in taking the lead
on the development of this document, please contact me.  I do recommend we
include pointers to existing, openly specified attribute/metadata sets in
the DAV specification.  I am open to suggestions from the list for
appropriate sets to reference.

I also recommend we use the hierarchical naming scheme described in "A
Proposed Convention for Embedding Metadata in HTML," which essentially
means we would use a "." instead of a "_" for a hierarchy separator.  We
should also define a hierarchy name for the attributes we define in this
specification -- "DAV" perhaps?

It is my hope that by having a rigid set of criteria for inclusion of
attributes, and by using the results of previous attribute/metadata
efforts, we can limit the extent to which we travel down this rathole.

>we'll have to have a long back and forth where I sound curmudgeonly
>and tell you about all the problems...

Of course, impudent youth is the perfect foil for the curmudgeon. :-)

- Jim

Received on Friday, 1 November 1996 19:01:58 UTC