bug-gne
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnupedia] Re: A Detailed Proposal - Mk I


From: Simon Cross
Subject: [Bug-gnupedia] Re: A Detailed Proposal - Mk I
Date: Sat, 20 Jan 2001 16:06:09 +0200 (SAST)

Poing!

A collection of replies and hopefully clarification of my ideas.

** My reply to Marcos Mello, who wrote:

>> <article articleserver="articleserver.gnu.org"
>>          authorserver="gnu-authors-reviewers.gnu.org"
>>          authorname="joesoap" articlename="whales" 
>>          articleversion="2.1">whales</article>
>> in the ocean.
>> - ---

> That sounds acceptable except for the fact that there might be
> multiple articles with that same subject link.  There might have to be
> a link to a page that lists all available links instead of a single
> link.  Any thoughts on this?

The point here is that the five fields (articleserver, authorserver,
authorname, articlename, articleversion) uniquely identify an
article.  The meanings of the five fields are:

articleserver:  The server to which the article was originally submitted.
author name:    The virtual name of the author who submitted the article.  
author server:  The name of the author/reviewer server which has the GPG
                Public key for the author name.
articlename:    The articles name, as given by the author.  Hopefully the
                author will use something sensible like the subject of the 
                article.
articleversion: The version of the article.  This is optional.

The server then uses this unique identification to find the
article.

The article need not be located on the article server specified by the
articleserver field.  This merely identifies the article.  The server
which has been asked to locate the article may fetch the article from
where ever.  The server to which the article was orginally submitted need
no longer exist.  The exact technique used to find the article is up to
individual GNU/Alexandria sites.  Initially this technique will be
extremely simple (look for the article on the site on which the article
was published) but will eventually grow to be more complex (look for the
article on mirror sites, etc).



** My reply to Mike Warren, who wrote:

>> <article articleserver="articleserver.gnu.org"
>>          authorserver="gnu-authors-reviewers.gnu.org"
>>          authorname="joesoap" articlename="whales" 
>>          articleversion="2.1">whales</article>
>> in the ocean.
>> ---

> Embedding a server-name in the actual data seems like a bad idea; what
> if it changes? A better solution might be to give all articles unique
> IDs, with optional versions, then links can be:

> <article id="some-unique-id" [version="1.2"]>whales</article>

> Ideally, the version would be left out, too, since probably the latest
> one is the one you'd like (which should be what happens if there's no
> version). There could be servers which return the unique ID of an
> article given some of the specifications you suggest above...

The embedded server name forms part of the unique ID that you are
suggesting.  See my reply to Marcos Mello's post above.  The beauty of
using the ID that I suggest rather than some random number (like a MD5
checksum) is that the ID that I have suggested provides meaningful
information at a glance.  You don't have to go look the number up in some
silly database.  You read the ID and you immediately know:

1. Who the author was.
2. Which server the article was first submitted to.  This also gives you a
   good place to start looking for the article.
3. What the subject of the article is. (Hopefully contained in the
   articlename field).



** My repply to Stan Seibert, who wrote:

> At first, I'm thinking that article writers in a particular category
> can review each other's articles.  In essence, the core of the article
> writing team is also the article reviewing team.  Later on, the two
> could diverge, with the article reviewing team probably being larger.

Yes.  This was my intention.  Except I see no need to ever separate
authors and reviewers.  An author may use his/her virtual identity to
review articles.  A reviewer may use his/her virtual identity to author
articles.  This parallels the situation in scientific journals.  It makes
sense since good authors are often good reviewers.



** My reply to Bruce Harrington, who wrote:

>> I think adding categories for reviewers would unnecessarily complicated
>> matters.

> I disagree.  It is neither complicated nor unnecessary.  I think you
> are being too dismissive of it.

> On the other hand, I feel digital signatures are too complex, as I
> pointed out before.  It has the potential for blocking out editors who
> might be extremely good in their subject but not know a thumb about
> digital signatures.  Do you plan on providing indoctrination, or do you
> prefer to just filter out people who can't/won't use them?

The categories are unnecessary since the review teams I have suggested
filfull the same function.  The teams are a better idea since they allow
people to organise themselves as they wish.

Without the digital signatures I can't see how the system will work.  I
understand that some people might find them complicated.  We will probably
have to work with the GPG people to develop digital signing tools for the
masses.  I think that eventually we will have to release an authoring tool
which does your signing and formatting for you.  Until we can provide
these tools we'll just have to go with the indoctrination and
filtering. ;)

>> My hope is that reviewers will organise themselves into teams
>> for specific subjects.

> Hmm.  Surely you are aware of the potential abuses prevalent in such a
> loose system...  How would you plan to address them?

I don't.  Readers will address the problem themselves.  Let us say, for
example, that we have two review teams, A and B.  Team A was founded and
is managed by a member of the GNU/Alexandria working group and has been
doing sterling reviews for 5 years.  Team B was founded a week ago by an
anonymous user and its members have been abusing the system since
them.  When you search for articles do you search for articles reviewed by
Team A or articles reviewed by Team B?

Quite frankly, I don't see a problem here.

>> Perhaps a case could be made for review teams to be able to group
>> together.  Thus there could be a GNUPedia-All review team, which has as
>> sub-teams GNUPedia-Science, GNUPedia-History, and so on.

> How does this differ from the Nupedia model?  It seems to be the same,
> except giving up control over factionalizing.  If you wish to go this
> route, then it would make sense to simply adopt Nupedia as
> (essentially) the GNUPedia-All.  I think it would be highly ironic if
> the GNUPedia team refused merging with Nupedia on principles, and then
> went ahead and adopted those same approaches, themselves.  ;-)

The difference between my proposal and Nupedia is fundamental.  
GNU/Alexandria is supposed to accept any and all contributions.  Nupedia
have teams of trusted people doing their reviewing for them.  
GNU/Alexandria will not have this luxury.  This makes the setting up of
the GNU/Alexandria system more complex and more exciting.

> I think you're obsessive about digital signatures.  ;-)

I'm obsessive. :)  But I can't see the proposal working without them.

>> - Getting reviewers:  My proposal has a kind of "Catch 22" problem
>> inherent in it.  How do we get reviewers when we have no articles, and
>> how do we get articles when we have no reviewers?  The solution to the
>> conundrum is that articles do not need any reviewers to be submitted.  
>> I stated in my proposal that authors would be responsible for the
>> review of their own articles.  It is, however, possible for reviews to
>> be added without the author.

> I'm dubious of this solution...  How would the authors not be biased in
> favor of their own articles?  Or if they have their friends review them
> (and pick the "most appropriate" ones), the reviews are going to be one
> sided.  Might as well simply allow for un-reviewed articles to be used
> initially.  It is certain that at some point someone will say, "This
> article sucks!!!" and then you recruit him as your first reviewer.  ;-)
 
The point, which I've made before, is that the reader chooses who's
reviews he/she trusts.  If authors wish to review there own articles
that's fine (although though pointless).  Unless the reader thinks they're
a good reviewer, their review is going to have no effect.  At the same
time reviews which are biased or unwarranted will harm the reputation of
the reviewer.

> Btw, I suspect that there is always going to be overlap between
> reviewers and authors.  It is in author's best interests to
> participate in review, and I imagine reviewers are going to want to
> share their commentary too.  This seems like a Good Thing, although I
> suspect there are potential abuses/factionalizing/cliquing that
> someone might want to ponder solutions to if we choose to go this way.

As I said in my reply to Stan (see above), this is a GoodThing(tm).  Abuse
of the system is not a problem since any abuse will harm the reputation of
the authors/reviewers involved.



** My reply to Imran Ghory, who wrote:

> I'd think that the filtering be kept seperate from the actual articles, 
> i.e the server could keep a copy of who has signed what, this will 
> allow for other servers setup which could allow different systems of 
> peer review

The reason for having the signatures with the articles is so that someone
reading the article can confirm that the article was indeed written by the
author it claims it was.

> If we do this we really need to have a better implimentation of gpg 
> for windows to avoid putting authors off.

Having not used gpg on windows, I couldn't say.  But if people need it,
people will write it.  That's part of what free(dom) software is all
about.

> We could also allow teams of teams so layers of trust could be 
> created.

Good idea.

> As I said elsewhere we really need to a have a unique key, 
> preferably something like MD5 fingerprinting.

As I pointed out we already have a unique key, which is superior (for our
purposes) to MD5 fingerprinting.  Read my reply to Mike Warren (See
above).

> Also maybe we should give each article a directory like structure 
> for instance a linux related article could be in,
>
>  /tech/comp/software/os/linux
>
> This would allow users to navigate thorugh similar areas rapidly, 
> and also to break off seperate areas into their own encyclopedia 
> (for instance, for an computer encyclopedia we create a data set 
> which jsut contain /tech/comp/* articles).

I had a long discussion on cataloging (which is what you suggest with your
directory structure) last night with a friend of mine who studied library
science.  The point of cataloging is to allow browsing of articles.  While
I think what you suggest would be useful, I think the catalog should be
kept separate from the articles themselves.

> I think we should also allow for editorial alternations on a server so 
> all the articles can have a unified style. This could be achieved by 
> having the alterations stored as diffs from the originals, this would 
> allow for the original article to be verified and at the same time 
> allow a overall editorial style to be overlayed.
 
The <header stuff> and <footer stuff> which is not part of the article
itself can be used for altering the 'look' of the document to some
extent.

> <splutter>
>
> Physics and maths sections would be almost usless without 
> formulas(formulae ?) and other sciences and engineering topics 
> would also suffer.
>
> (Maybe we should just have latex -> graphics)

Go read an encyclopedia.  They don't have that much maths in them.  An
article on 'Calculus' for instance is more likely to contain information
on when it was developed, who developed it, what its uses are, and so on
than a bunch of formula.  That said, I think GNU/Alexandria will want to
expand beyond the traditional encyclopedia format.  For this some sort of
maths authoring language will be required.

> The server could also offer the ability to send you the article "raw"  
> without processing so that you can check it by hand. This will also
> allow for other preprocessing to be done before the html is sent to
> the user.

This is an interesting suggestion.  I hope that we can avoid resorting to
this, but having two different retrievals (one to fetch the raw signed
article and one to fetch the article for viewing) may provide a way out if
other options for modifying the document but still allowing the signature
to be checked, fail.  That said I still prefer the idea of having a copy
of any modified information delivered with the article when it is
viewed.  For example, if we change <article ...> to <a href="..."> then
the resulting HTML would look something like:

<!-- start orginal section
<article ...>
end original sectiom -->
<!-- start modified section -->
<a href="...">
<!-- end modified section -->

This could be used in many ways.


** Ping.

GNUPedia is dead.  Long live GNU/Alexandria. :)

Ciao
Simon

--- Imagine there's no heaven.  It's easy if you try.
    No hell below us.  Above us only sky.
                           John Lennon, Imagine.  ---

[ email:        address@hidden
  tel:  (c) 4979 486 380        (w) 4072 056 (120)
  Information reversed to foil spambots ]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]