On Jan 3, 6:02*pm, Keith H Duggar <dug... (AT) alum (DOT) mit.edu> wrote:
Since none of salmonbytes, whileone, BS, etc have any response
I can only surmise that they now realize a forum discussion is
in fact not a hierarchy. Glad I could help.

KHD

Keith H Duggar wrote:

I strongly doubt it.

Indeed, sometimes I do; but not often. Is this due to an arbitrary
restricion in the interfaces, or is it due to a more fundamental
restriction in how discussions proceed? I think the latter.
Reply to multiple postings would be more complex in character,
e.g. quoted material would now have to be marked with the originating
posting in some way and it's not clear whether they would be
sufficiently understandable to those who arrive at them having
read just one or only a few of them. Will readers be prepared to
back up all the time into threads they haven't read in order to
make sense of the exchange? Won't the result produce the 'lost
in hyperspace' problem that has caused pretty much every hypertext
and website to structure its material into a hierarchy
full of crosslinks even when there is little or no technological
support to do so? I think it will.

But you have a good point: has it even been tried?

In my posting software I can arbitrarily edit the References:
header, but you're right, all the viewers I know only present
threads as trees, never as arbitrary directed acyclic graphs.

Cross-linking in discussion happens a lot in web-based writing
of course. E.g. blogs responding to each other, with talkback/pings
to create the forward links. This approaches what you have in mind,
I think. Yet, while blogs are full of hyperlinks, their internal
organization is nearly always linear or hierarchical. This is
not because of necessary tehcnological limitations, but
because of limitations in their users: if they weren't,
postings would be much harder to find, to read and to write.
E.g. I find editing and organizing Wikis pretty difficult.

Yes, but we can't preemptively guess NNTP Message-IDs.
This is of course an implementation restriction, not a
fundamental one.

Yes, this happens all the time, and in USENET well-established
conventions exist for keeping this manageable (that I'm using here).
A strong point is that they are really simple and expressed
in plain text. Can something equally simple suffice for a
discussion environment in which multi-replying is the norm?

No, but the question is how useful it would be for the discussion
environment to allow postings with *multiple* parents (meaning,
I suppose, that we can navigate the postings as a DAG rather than
just a tree).

What does this mean, exactly? That we can follow the reference?
Just hyperlink to it, quote it or attach a copy.
That we have multiple documents open while browsing?
In my web browser I have this all the time.
That we can quickly determine a specific set of documents
that become parents when initiating a reply? This is harder.
Hypertext systems of the past supported stuff like this
but I don't know how user-friendly it is.

What does this mean? That when at the referenced source we can follow
the reference backwards to arrive at the reply? This is also hard,
because the software controlling the creatin of the reply doesn't
usually control how the referred sources are presented (usually
to others, and written by others). But e.g. trackbacks/pings address it.

Anything more?

How to do this in a sufficiently useable way?

Some forum software allows this. Replies may become invalid.
What you end up with is not a discussion forum, but a Wiki:
writing for Wikis is very different.

The problem with this idea, as with any semantic enrichment,
is that the labels, even when users can be trained to apply them,
will rarely be accurate, unambiguous or complete.
E.g. I may agree with your premise, but disagree that it
supports your conclusion. Do I get to modify your
SUPPORTS to CALLS-INTO-QUESTION?

It doesn't make any difference.

The basic issue is the need to traverse along the discussion threads,
which relational systems aren't usually optimized for,
if they can express it at all.
Whether the relation forms trees or arbitrary DAGS
doesn't make any difference.

The resolution, I think, is to optimize this type of use,
either within the query engine or in some other way.

You can; but will you? And where do you stop?
E.g. why not label with specific logical fallacies? (STRAW-MAN,
AD-NAUSEAM, BEGS-QUESTION). I'll tell you: the labelers won't agree
on when to use which labels.

--
Reinier

salmobytes wrote:

[...]

This is a broad statement. What is needed as far as I can see is
efficient traversal of relations (i.e. arbitrarily wide, very selective
joins). This can be supported, even if many existing RDMBSes don't.

Not so fast.

XML itself is just a standard for serializing labelled trees. In my
experience, most of my "trees" are really arbitrary graphs (relations),
and while XML supports crosslinks as well, XML definition and manipulation
languages tend not to support their traversal well.
For a forum this need not be an issue.

But XML also assumes that all data is stored as documents and processed
by operating on documents one at a time. USENET does the same thing,
but it really isn't very practical.

Some issues from a database perspective: What if we want to query
or manipulate across the whole collection? Why do we always have
to parse documents whenever we want to use the data they contain?
Why do I, when writing queries or transformations on my data
(e.g. with XPath, XQuery or XSLT) or schema definition (XML Schema - please)
I always have to concern myself with stupid serialization and document
management issues such as the consistent use of file names and URLs,
file system limitations, character encodings, etcetera?

Not to mention that XPath, XSLT and XQuery are still pretty hideous
languages, both syntactically and semantically, although they have much
improved. Try representing an arbitrary relation (graph) in XML, then
writing, say, an XPath expression to compute its connected components.

Not such a good match for a discussion forum, if you ask me.
XPath queries may be expressive enough, but what about speed?
Do you want to represent the whole forum contents as a single XML
document that is updated whenever some posting or edit is performed?
Or are you thinking of some solution that keeps the whole thing in memory
in parsed form? How to make it scale?

I'm not familiar with this, but does it work well for a big discusion forum?
How sophisticated is the querying you allow?

.... and consists of small enough bits (documents) that don't need to be
queried or manipulated collectively.

I think this is far too strong a statement.

--
Reinier