Re: Open Document Environment (ODE)

[Aaron Turner <aturner@linuxkb.org>]

On Sun, 9 Jan 2000, Greg Ferguson wrote:

> On Jan 9,  1:05am, Aaron Turner wrote:
> > Subject: Re: Open Document Environment (ODE)
> > ...
> > 7a) Local/LAN/WAN retreval is going to be hard.
> 
> I think people need a retrieval capability that scales. It
> should (must?) work in all these situations. One huge master
> site (albeit mirrored in other locations) certainly makes
> life easier for the administrators of such a system. But, I
> should be able to examine/peruse just the content I have
> locally and then be able to jump to the site-based content
> store and/or "master" collection when desired.

Hmmm... I guess I believe that if we get together and work together a
number of things will happen:

1) We will have one of the most kick-ass document retrival engines on the
web.  We're not talking putting a bunch of files in a directory, and then
having ht://Dig index them so you can do keyword searches.  MUCH more
powerful than that.

2) We will have THE most comprehensive archive of documentation for Linux
on the web.

This means a very complicated and difficult to setup web site with 100's
of megabytes of data.  Avg. Joe User isn't going to install the system
(unless we make it really easy) and isn't going to want to download that
much content over a 56K modem (or worse).  Now maybe if we can get someone
to sponsor a CDROM with the site on it that people could buy cheap that
would work, and we could do quarterly updates or something.

Now I'm not saying that we can't our shouldn't do this.  I agree that it
would be a great feature to offer the end user.  (I should've been more
clear about that last time- sorry.)  I'm concerened about doing this as I
know from experiance that this is not something simple to do, and I don't
want to try to bite off too much initially.  I will admit that there is a
definate problem with this thinking- distributability can't be done
correctly as an afterthought.  If you don't build a system that is
distributable to begin with, we'll probably end up throwing it out and
starting over.  That sucks.
 
> > 8) Knowing what software is installed on a users computer and then
> > showing what documentation relates to that is rather interesting.
> > Very interesting actually.  It's also has a ton of privacy vs.
> > usability issues too.
> 
> Have you seen the work of the Dublin Core group, the work
> done by Debian Doc project or what has been done by Paul
> Jones and the crew at Metalab? If not, you should examine
> these documents, which describe a methodology for "resource
> discovery". We, too (SGI) are incorporating a paradigm such
> as this in the Linux documentation and products we are currently
> preparing for release:

[snip]

I took a quick look at the links, and I'm not sure how that would help
discovery of what applications/utilities/etc are installed on a clients
system as it doesn't seem to have any provisions for communications
between client and server, not to mention it is very documentation centric
not application centric.  (Or am I missing something?)  Also, why
re-invent the wheel, when things like RPM (and I assume the deb format
does too) has a database with name and version information of nearly all
software installed?  The information we desire is a mere `rpm -qa` away.

Now I do see where something like the above could be used for distributed
content management.

> > 10) I haven't ever seen SGI's bookshelf thingy or heard anything
> > about it. Maybe you could take a few screenshots for those like
> > me who have no access to SGI/Irix??  Maybe after I see it I'll sing
> > a different tune.
> 
> Although a version of the system we provide does indeed scale
> down to a local system, our "main" site can be accessed with
> any old web browser from:
> 
>    htp://techpubs.sgi.com
> 
> You can home to our Linux collection of documents from this URL:
> 
>    http://techpubs.sgi.com/library/tpl/cgi-bin/init.cgi?coll=linux

Kim, is this what you're talking about when you say bookshelf?  I guess I
really don't care for this.  It's based too much on indexing
alphabetically, and has zero categorization by subject type.  Instead it's
categorized by document type (man page, howto's, etc).  Take the first
entry in the Howto section for example "A mSQL and perl Web Server Mini
HOWTO". This is horribly indexed under A IMHO.  It should be indexed under
DB's and then again under "Web Severs" or something like that.  It also
doesn't scale to 1000's of documents because the index is so flat.

--
Aaron Turner, Core Developer       http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization  http://linuxkb.org/
Because world domination requires quality open documentation.
aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net
The difference between `Unstable' and `Usable' is only two characters: NT



--  
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org