[uf-new] ISBN, ISSN and the case for moving forward now

[Scott Reynen]

On Mar 18, 2007, at 11:29 AM, Brian Suda wrote:

> We don't have individual pages for TEL TYPE FAX so why have pages
> for UID TYPE ISBN?

Because it's less clear that UID solves the ISBN problem than it is  
that TEL solves the FAX problem, as evidenced by this thread.  If we  
start seeing suggestions to create a new FAX microformat, I think it  
would make sense to create additional documentation explaining how to  
use TEL to solve that specific problem.

> By keeping all the UID types together at the UID
> page we can (hopefully) help the next person find information better
> when they want to mark-up things like their Nintendo DS code for the
> world to see, or other unique identifers.

Improving documentation of the UID technique in general and improving  
documentation of using UID for ISBN markup are not at all mutually  
exclusive and we should do both.

> Things like MD5 and SHA-1
> hashs for downloads also fall into the category of UID and NOT their
> own formats.

Right, but those could be documented on separate pages without being  
separate formats (though I see no evidence that would be useful in  
this case).

> This is certainly worth exploring, but re-use is best.

Re-use of techniques is best.  But re-use of documentation is not,  
because it's not conducive to re-use of techniques.  If I'm a  
publisher looking for a standard markup for my ISBNs, I'm more likely  
to end up re-using the UID technique if it's explained to me in the  
context of my specific use case.  Obviously we can't document every  
specific use-case, but it's something we should encourage.  Not only  
because it would result in better documentation, but also for a more  
subtle reason: If we don't treat documentation of a general technique  
for a specific use case as a successful outcome, we're left with only  
two possible outcomes: successful new microformat or failure.   
Naturally, this leads to everyone pushing hard for new microformats  
for everything, as no one wants their work to result in failure.

--
Scott Reynen
MakeDataMakeSense.com