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

# 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.

I think it's wrong to think that the 'source' of a resource is somehow
'metadata'. I know it's cute when you can do that, and I've known (and
worked on) systems that do, but it's not true that all data is
metadata.

I think really for 'obtain source' you need a link, not metadata. What
if there's more than one source? What if one source is combined to
create two derivatives? I think we just have to accept that the
relationship between "retrieved resource" to "editable resource that
generates retrieved resource" is complex, and not try to shove it into
the metadata hole just because it sometimes fits.

You might think that 'lock discovery' is also a metadata issue, but
it's a peculiar one, because it's transient, and has less to do with
the resource than with the manager that supports the resource. For
example, a cached entity shouldn't become invalidated just because the
lock state of the resource it was derived from changes. We're often
blurring the distinction between those elements of metadata that apply
to the resource and those that apply to the resource location.


# 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,

Yes, unless your documents are songs and you want to distinguish
between the composer and the artist. Author's common, but it's not
universal. It will fit lots of collections, of course.

# "Last Modified" date is another.  Of these, some require
# standardization on the data format so their use is interoperable.

Standardization of 'author' is pretty difficult. Last name first?
First name first? Chinese given name after honorific?

# 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?).

Well, again, HTTP defines some metadata for resource locations that
can be thought of as distinct from metadata of the resource itself.
(When _did_ Herman Melville write Moby Dick? Should that be the
'creation date'?)

# 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.

I think it will be easy to make this be the empty set.

# 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.

I think this is also the empty set in general, although there are
specific application profiles for which it is not.

Let me try to be careful: Distributed Authoring and Versioning as a
protocol shouldn't have any 'well known attribute sets'. However,
there is likely a profile for 'Authoring Web Sites in 1996' which
_does_ have a metadata profile.

But don't put its specification in the DAV draft.


# 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.

This isn't really metadata.

# 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.

Date of what, though? If you just mean last modified, this is already
part of HTTP and shouldn't be replicated somewhere else. If you mean
something else than what's already in HTTP, I think you'll have
difficulty finding a common requirement and use.

# 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?

I don't see any reason for a separate DAV profile.

Curmudgeonly yours,

Larry

Received on Saturday, 2 November 1996 03:21:25 UTC