Re: Tag Time Issues

Hi Aaron,

I wanted to respond to your posting about bicycles but that'll have to wait 
'cause I'm about to go to a conference for a few days. But I think I have 
time for a reasonably sensible response to this one:

At 01:15 PM 4/29/01 -0500, Aaron Swartz wrote:
>1) Why does tag insist on using such strange dates? It seems that the magic
>date 2001-1-1 will cause confusion and misuse of tags. Certainly it confused
>me for a bit. Wouldn't it be simpler just to specify full dates as in the
>original proposal -- I think this would make more sense and be more
>compatible.
>
>You seem to indicate that the shortness rule is because you need to encode
>these in barcodes. Perhaps I'm missing something, but it seems unlikely that
>the few extra characters needed will make that much of a difference. And
>even if they do, can't you put this in the barcode encoding/decoding
>mechanism, and not bother the users with it?

As has been said during this discussion, it'll be software that produces 
tags by-and-large, so I'm not too worried about mistakes. I'm more 
concerned about practices (see my response to your next point).

The date is almost always used opaquely: as I'm sure you appreciate, its 
role is to make the tag unique and it's not a timestamp of any resource. So 
I'm less concerned as to whether it can be construed very easily as opposed 
to moderately easily, and more concerned about brevity.

Of course, brevity can be undone by long specific identifiers (not to 
mention long domain names) but I'd like to try to make brevity possible. 
The majority of tags will contain very short date strings like ";1" and 
";2-3", thus making them that bit easier for humans to write and say to one 
another. Aesthetically, I just like the way that that those short strings 
are unobtrusive.

(I'm settling down to the idea of seeing a ';' in there but 'semi-colon' 
isn't very nice to say as compared to 'dot', 'dash' etc. 'Comma' would be 
phonetically nicer.)

I used the term 'tag' because literal tagging of physical entities is my 
original motivation. Linear barcode symbologies (like some other id 
technologies) aren't very forgiving when it comes to length. Yes, I could 
have special conventions for writing tags into barcode form, which would be 
converted into canonical tag form. But then we have things floating around 
that sort of are tags and sort of aren't. We went through a process of 
allowing multiple forms for tags but Sandro persuaded me not to and now I'm 
a true convert to that idea.


>2) Similarly, the rule that you can mint tags on dates before you've "owned"
>the domain just seems silly. There is no technical reason for this, it just
>seems like an exception so that people can use the magic date mentioned
>above. People are highly unlikely to do diligent research on past domains,
>and thus will probably accidentally run into conflicts. Since the scheme can
>make a simple change to prevent this, I think it should.

I think you (and several others) are right that our motivations are less 
than convincing. In our defence, it's not that we specifically want to make 
it possible for just about everyone to use ";1" but that we think people 
would be sorely tempted to do that and we wanted to see if there was a 
valid way for that to be done.

I'm tempted to remove the use of unassigned authority names from the 
proposal. I also think we should consider removing the parts about putting 
hints in the specific identifiers, and how those who mint tags can declare 
their true identities (by using an appropriate authority name). It seems to 
have created more trouble than it was worth to make that explicit.


>Overall, I think the tag scheme should be simple.
>This will insure that it
>will be understood and used properly.

Agreed.


>tag:me@aaronsw.com;2001-04-29/example
>
>is relatively easy to grok. We've got an email address, a date, and a path.
>On the other hand:
>
>tag:sandro@w3c.org/1:my-dog
>
>is relatively confusing. At first glance, one can't really figure it out.

Yes but I think the '/' in the tag authority is (was) the really confusing bit.


>Hope this feedback helps,

Thanks for the feedback.

Tim.



Tim Kindberg

internet & mobile systems lab  hewlett-packard laboratories
1501 page mill road, ms 1u-17
palo alto
ca 94304-1126
usa

www.champignon.net/TimKindberg/
timothy@hpl.hp.com
voice +1 650 857 5609
fax +1 650 857 2358

Received on Monday, 30 April 2001 11:43:03 UTC