On Sun, 28 Oct 2001, Peter Jones wrote:
> I wonder whether purple numbering as it appears in a HTML document is too
> concrete an address point if you move beyond simple HTML.
> Or rather, to put it another way, when I point at a purple number anchor
> with a link, what, in the world of DKRs, am I really pointing at?
Great question. As I noted in my talk, it's important not to make purple
numbers out to be anything greater than they are -- markers in HTML pages.
However, the broader implications are well-taken.
Immutable IDs, like the node IDs (NID) in purple numbers, seem great for
dynamic content, but in reality, there are problems. The example that
Eric cited was as follows. Suppose there is a paragraph with node ID 023
that reads:
These is the days that try men's souls.
If I create a link to node ID 023 of that document, then that link will
not break if the paragraph's location in the document changes, as long as
that paragraph continues to exist. However, is that a good thing? If I,
as the author of this document, fixed the typo -- "is" to "are" -- then I
would want all links to continue to point to that paragraph. However,
what if I changed the content of that paragraph to:
Don't worry; be happy!
Now, links to that node ID may not semantically make sense anymore.
What is the solution to this problem? There are lots of possibilities.
Requiring version information in links (which, incidentally, my Purple
software supports) cures this problem by only allowing links to a
particular version of a document. This doesn't seem like a very appealing
solution, though; links ought to evolve. Automatic notification of
changes to authors linking to that document will help. The fantasy
solution is to have a semantic addressing scheme where you could say
something like, "Link to the paragraph with the Charles Dickens quote."
> I note that existing purple numbered documents don't seem to include version
> information at the grain level in the p-number.
In Purple, I have a CGI script that lets you specify version information
in the URL of a document. That, to me, seems to be the preferable
solution. Internet Archives recently made a lot of their stuff available
via their "Way Back Machine," where you can specify the date of the
version of a Web site you want to see. For example, check out:
http://web.archive.org/web/19970629120153/http://www2.bootstrap.org/
Note the timestamp in the URL. Wouldn't it be great if this were a native
feature of all web sites?
> I think it is important to distinguish between the content of the DKR and a
> display document.
Yes!
> When I am engineering content I really want my content editing tool to give
> me the potential to access all of the depth (by which I mean all the grain
> versions and structural re-orderings of the past). Whereas to view some
> material designated for display for others we might only be interested in a
> very shallow presentation of particular data for the browser (the HTML of
> today).
> These are two very different modes of use.
>
> This distinction between modes and uses of addressing has a corollary in
> websites that serve up paragraphs that are dynamically generated from
> ever-changing data sets.
Yes again!
> So I guess I/we have two questions to ask:
> 1) Are p-numbers like we presently see rich enough in information?
Again, purple numbers are simply an interim solution for granularly
addressability. And granular addressability alone doesn't allow this.
What you need is a system that stores all documents as a kind of "node
soup" (to borrow a term coined by Nicholas Carroll) along with all the
requisite metadata, such as version history. In this situation, _all_
documents are simply a _view_ of some collections of nodes, and the
browsers allow you to browse and manipulate these views.
> 2) Are they in the right place in the system? E.g. should they be hidden
> enablers instead of explicit UI content?
The easy answer is yes. The correct answer is sort of. I think the
question behind this question is, what is metadata? A node ID seems to
qualify as metadata, since it is data about data, and by default, it
should probably not be visible. But what if the user wants to see the
node IDs explicitly? In this view, are the node IDs still metadata, or
are they now data? In other words, should I be able to address the purple
number itself? Should the purple number itself have a purple number? :-)
-Eugene
-- +=== Eugene Eric Kim ===== eekim@eekim.com ===== http://www.eekim.com/ ===+ | "Writer's block is a fancy term made up by whiners so they | +===== can have an excuse to drink alcohol." --Steve Martin ===========+------------------------ Yahoo! Groups Sponsor ---------------------~--> Pinpoint the right security solution for your company- Learn how to add 128- bit encryption and to authenticate your web site with VeriSign's FREE guide! http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/IHFolB/TM ---------------------------------------------------------------------~->
Community email addresses: Post message: unrev-II@onelist.com Subscribe: unrev-II-subscribe@onelist.com Unsubscribe: unrev-II-unsubscribe@onelist.com List owner: unrev-II-owner@onelist.com
Shortcut URL to this page: http://www.onelist.com/community/unrev-II
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.0.0 : Mon Oct 29 2001 - 12:37:37 PST