MHonArc v2.5.0b2 -->
tab message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Metadata, filenames, and knowledge in access paths
As promised last week, this is a brief note on the importance of
metadata visibility in artifact names and in access paths to artifacts.
I'm trying to raise issues and start a discussion.
Often people will cache/copy working files and other data from a web
site. This is usually done explicitly, but is sometimes done by e.g. a
web site copier. Metadata related to an artifact (without loss of
generality I'm going to stick with "artifact" in the rest of this note)
can be maintained in several places:
(1) Inside the artifact itself (e.g., metadata tables in a document,
metadata in comments in an XSD, copyright, author, Contributor information)
(2) Related to the artifact (e.g. a parallel file with "meta" added to
the name, or bound with an artifact as in the pre-OSX versions of the
Macintosh filesystem resource fork, or by database key)
(3) In the specific path used to access the object (e.g. go down a
source tree to an artifact where and how it's used depends on the path
taken - think of a big-endian vs a little-endian binary data object, or
path components of a URL/URN)
(4) In the name of the artifact itself (e.g.
"tab-artifact_naming_guidelines-1.0-spec-wd-09-diff.doc"), regardless of
how the artifact is accessed.
In passing, note that the access should not be confused with the
metadata for the artifact - the metadata (as embedded in an artifact)
must be maintained, but a path may not be. Much discussion has taken
place around creating fixed URLs/URNs for OASIS documents, which is
difficult with Kavi as the only access mechanism.
The suggestions made by Jamie and Mary in their comments seem to be a
combination of #1 and #3. The ANG wd09 are a combination of #1, #3 (for
URNs in particular), and #4.
One problem with the #3 approach is that at least part of the entire
path used is, in effect, part of the name of the artifact. We'd not
like to have a 30 character name for [the final component of] a
namespace, but since namespaces are aliased in use this is not a major
issue: a hostname, without domain or subdomain names, is allowed to be
up to 255 characters [or bytes? not relevant to this discussion] , so a
URI can be very much longer than one might expect.
One of my favorite examples has been of a collection of TCs (without
loss of generality, use TC names A, B, C) that each serially number
their artifacts - WLOG, say 1, 2, ... - and thus looking at the artifact
WITHOUT THE PATH TAKEN TO REACH IT provides no information about the
artifact. One must use approaches #1 and or #2.
So if I have a folder on my laptop called "DocsToReview" I must manually
rename every document that I cache locally. In turn, I can't tell
whether I've already downloaded a document, without a great memory or a
document management system. The files presented to me in a standard
file save dialog are of the form "1", "2", "1" from another TC, "2" from
a third TC, etc. The manual renaming is a problem because I can't
easily detect that I have a collision with a new artifact that I
download. And reproducing the hierarchy/paths leads to other errors
("where did I put the wsrp files? oh, it's under
.../oasis/not-quite-standards/wsrp2!") and without standardization of
pathname components creates another set of problems.
This makes multiple conflicts in artifact names as saved in files:
1, 2, 1 (again but different), 2 (again but different)
and if I try to download TC B's artifact 1 there's a conflict that I
must resolve EACH TIME I DOWNLOAD AN ARTIFACT WITH a conflict in this
simple naming scheme. Consider also where each TC calls a file
"schema.xsd".
If instead I push the name of the producing TC (which we should do for
traceability under the new IPP, I'd aruge), the final path component for
each of those documents is
A-1, A-2, B-1, C-2
and if I try to download B-1 the first time there's no name conflict
with A-1. Likewise with C-2, and other artifacts that conflict in the
last/filename component.
Moreover, while in some circumstances (e.g. source code build trees for
multiple process architectures) the ambiguity of the final name
component is beneficial, I argue that that is true only because the
access paths and the naming hierarchy/paths are highly contstrained.
COMPLAINTS ABOUT LONG NAMES
The ANG explictly do not require full metadata-bearing names where e.g.
an archive bears an appropriate name - one review comment was on help
systems and html documentation, where there would be significant burden
in very long file names - this was resolved in favor of (in essence)
naming the root and using relative references as is most common in web
site implementation and design.
Namespaces are essentially always abbreviated to a few characters at most.
WHERE FROM HERE?
I have no issue with (say) a URN with a simple final component name, but
remember that these URNs are always aliased usually to a couple of
characters. So a longer final component name that has meaningful
information in it is not a barrier to the common use. My concern is
that if we were to strip out all metadata from the final component name
we introduce a lot of USELESS ambiguity.
This does not argue for keeping ALL metadata in the final component
name, but does argue for a consistent naming style that incorporates
significant distinguishing metadata in the final component name. In the
QSC discussions and multiple reviews outside the TAB of the ANG, there
was one comment that objected to metadata in the artifact/final
component name.
While some may enjoy disambiguating each artifact name by erecting a
path above it, at least one common use case makes that difficult,
subject to error, and does not permit easy detection of those errors.
CONCLUSION
OASIS needs to support some set of metadata in the artifact name. The
set in the ANG D09 is adequate, once conformed to the just approved
IPP. The utility of the ANG patters can be discussed further, and
examples with more cases should be done (including sequencing for e.g.
working drafts).
As a side note, Jamie and Mary's comments seem to request a set of rules
for major.minor version numbers. In my considerable experience, this is
a waste of time. The only requirement is that they are monotonically
increasing over time. If OASIS staff would like to assign version
numbers, that's fine with me, but we designed the ANGs to minimize the
burden on staff. Bring it on, as the phrase goes...
bill cox
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]