- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Fri, 1 Nov 1996 23:21:11 PST
- To: ejw@ics.uci.edu
- CC: w3c-dist-auth@w3.org, ejw@ics.uci.edu, yarong@microsoft.com
# 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