Tag Time Issues

[This has mainly to do with keeping an administrative track of what
tags one uses, and is therefore more of an implementation and usage
matter than a syntax issue. N.B. I would not have much of a problem
with any of this, but you can see that the W3C or some large
organization would have to be very careful indeed in its tag
policies.]

The main question that I want to address in this email is,
"could/should one mint a tag for an event occurring on e.g. 1-3-8 on
1-3-18?".

This all stems from one of the most interesting aspects of the "tag:"
delegation, which is its dependence upon the notion of "tag time",
i.e. one particular day on or after 1st January 2001. This raises the
question: how specific is this particular unit of time given the
resources that it is binded to? For example, I had always considered
the date-stamping of URIs as popularized by the W3C to simply mean
"what on 2001/03 we referred to as EARL" for /2001/03/earl/ (this is
supported by a quote from "Cool URIs Don't Change" [1]). That is until
I saw the TANN URI proposal [2], which states:-

[[[
An example: W3C obtained "w3.org" on 1994-07-06. Had this TANN scheme
been in place, W3C might have used "tann:1994-07-06,w3.org," for the
first few weeks. If it wanted, come August 1 it could switch to
"tann:1994-07,w3.org,". Come Jan 1, it could switch to
"tann:1995,w3.org," which would be a good name to use until some
problem arose. If in July of 2000 (say), it realized a wholely new
organization and policy was needed, it could start using
"tann:2000,w3.org,". Also, if some need arose for a temporary
namespace, an arbitrary narrow time could be used, like
"tann:2000-01-01-00-00-00.00001,w3.org,". (This is probably best
avoided by using sensable namespace policies.)
]]]

This implies that the shorter the time period, the more whimsical the
resource being identified. It also implies that long time periods are
very broad, and should have distinct namespace policies. In other
words, "1" would be something which is used "until some problem
arises". However, this seems to go against the flow that each date
component in a tag identifies a particular *day* and not a longer
period of time. This appears to be something that has changed in the
transition from tann => tag, and yet some of the semantics of tann are
being alluded to, i.e. that the more general the resource, the shorter
the date component in the tag. Thus, although the first day of a
particular day is still just a day, it could be envisaged as having
some kind of special meaning in that it is a very general identifier
that has a certain namespace policy, whereas three part date
components are for more pointed identifications.

As a practical example, earlier today, I looked out of my window onto
the lawn outside to see a blackbird hopping around... let's mint a tag
to identify that particular blackbird:-

     tag://sean@mysterylights.com;1-4-28/blackbird

Now, the only reason that I should ever want to reuse that URI is if I
saw possibly another blackbird on the same day, or if I wanted to
issue some other remark about a blackbird. However, due to
persistence, that URI is now bonded to that particular resource, so
what would I use to represent another blackbird? What if I want to
refer to the concept of the blackbird in the 1-4-28 tag in a different
context; would I use the date where I create that new context? One
idea would be to use the date of something in that path itself (e.g.
tag://sean@mysterylights.com;1-4-28/2001-4-10/myconcept) which
identifies the "myconcept" on that particular date, but that goes
against the flow of having a dating system for the authority component
in the first place. However, in some cases (e.g. for dates before
2001) this would probably be necessary. Still, the general rule still
holds true that, "concepts that one rarely refer to should have the
three tier part, whereas the broader concepts get the 1sts".

One problem with using "1" as a very generic namespace is that if I
want to create a very whimsical term on that date, I have to be wary
of the policy for using "1" which I will no doubt want to use again.
In this case, you could just prepend a "1" to the path or something;
no big deal. In other words, there is a big difference between "The
Simpsons" and "the episode of Simpsons I watched on a particular day".
In actual fact, I think that unless this is some *really* important
namespace, reusing the 1st of January namespace is a bit lazy; simply
not wanting to type a few extra digits. Why not use a slightly more
specific URI if it clears up the confusion?

Still, there are some advantages to using the date part as put out in
the TANN proposal: i.e. that tags could then point to any kind of
concept: from those well thought out (using shorter date components)
to those which are thought up quickly, and may only apply for a short
time period. For example, I am always creating concepts and so on that
I use in emails (hey, I'm an SW developer)... I don't want to have to
keep track of all of these for any longer than a day, so I can just
use the three-tier date component for them, knowing that I'll get 353
of them a year, and will not have not reuse these at some point in the
future. If I want a structured namespace that I can use in a project
or something, I can use a "first of the month" or possibly "first of
the year" tag. Also, I guess it would be legal to use subdomains at
ones domain name? e.g. tag://sbp.infomesh.net;1/myterm

This is not something that could be particularly constrained by the
specification for tags itself, because it is fully up to the user how
they manage their own tag space, but I do think it would be sensible
to advise people on the best practices in managing their namespaces.
Certainly, date stamping, and using URIs to identify abstract resource
in general is an very difficult concept for some people to grasp,
especially those that only know about HTTP URLs, and look upon them as
simply locations for some data.

Another part of this problem is related the difference between 2x3 and
3x2; they are different strings, but they both have the same answer
mathematically. If I was referring to this sum as a mathematical
expression, would I use "/math/2x3" or "/math/3x2"? I conclude that it
doesn't matter as long as one refers to the same namespace
consistently, or states an equivalence in a particular implementation.

P.S. Sorry about the "rant" nature of this email (which reminds me a
little of [3]), but it is an important topic.

[1] http://www.w3.org/Provider/Style/URI states:-
[[[
1998/pics can be taken to mean for your server "what we meant in 1998
by pics", rather than "what in 1998 we did with what we now refer to
as pics."
]]]
[2] http://www.w3.org/2001/02/tann/
[3]
http://www.dilbert.com/comics/dilbert/archive/images/dilbert2001043045
614.gif

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Saturday, 28 April 2001 17:35:13 UTC