ISHN Numbers | |||||||||||||||||
Books have ISBN numbers (beginning with 978), Magazines and other serial publications have ISSN numbers (beginning with 977). Web publishing shouldn't be left out. How about a hypertext publication number - the ISHN number.
Rods Tiger, Nov 02 2003
What do you think of this idea or comment? | |||||||||||||||||
Add your comment
Why?
Well, let's project it through a set of scenarios and see what happens.
It might be desirable to have ISHN numbers on 'serious' sites that consider themselves a form of 'publication' - even to the extent of obtaining a barcode for the website. A sort of 'sort the men from the boys' situation.
It might cause uproar if that were taken to fruition because the web has always been seen as a place where everyone is a publisher and a consumer simultaneously, and this is setting up an artificial boundary based on who can afford to register and apply an ISHN number (and who is inclined to in the first place).
It might cause reassurance among the general web surfing public, and among the future historians of the semantic web, that there can be this sort of demarcation of 'serious' publications and 'back bedroom' publishing, which otherwise would have little to distinguish other than literacy, current-ness and scope.
It might cause a revolution akin to book-burning. It might cause a lot of things. It might be wholly ignored and bypassed by almost everyone. It might serve to confuse the confusable strata of management into compelling them to register almost every internal document in their intranet as if it were a newstrade-distributed magazine. Who knows what the ramifications might be.
How would you deal with cases where parts of the website are deleted, significantly edited, or significantly extended? Does the publication then become a new one, with a new ISHN number assigned, or is it still the same publication? As convenient and cheap (asymptotically free) as the web makes it to update websites, when does a website cease to be the same website that it used to be? Can you wash in the same bitstream twice? Etc.
Some very profound philosophical questions lie herein.
That raises an interesting point that I was writing about only last week - the notion of a 'broadcast schedule' or 'publication deadline' that other media all have to adhere to, which the web can get a way without due to the inherent fluidity. However, that can be a double edged sword. With no formal 'staging deadline' there can be a remarkably lax attitude to the sort of mistakes that can cost serious money in the wrong places. The notion that it is so easy to edit and correct shouldn't be an excuse to proofread online using the live copy.
I wonder if in years to come, we have datestamp periodicity or some form of temporal quantisation that accustoms the public to a form of stepping, rather than the unrestricted smooth flow of http that we're used to now. The reason I'm thinking in this way is because I was, a few weeks ago, partially occupied with the idea of media servers based on todays web servers, but oriented to multiple mediums on demand (such as print, web, television) but single-path editorial workflows (with late forking).
It's a complicated thing, but if a publication does the biz in parallel across multiple media, it might come to be regarded as 'good manners' to have staging periodicity - ie, if you request a print of some publication, you want to know that the person who does so 10 seconds after you doesn't get a totally updated version. You'd want to know that your request is of roughly useful validity for a while. Meanwhile, over on the web, you might come to expect the same update frequency to apply (which it typically would, on the kind of media server architecture I'm thinking of, in the near future). Or it might not - who knows.
they have one it's called a URL check the reference site called GOOGLE