[seqfan] Re: moving to wiki

[Joseph S. Myers]

On Thu, 27 Aug 2009, David Wilson wrote:

> Your ideas are great. And all of them would be more effective on a Wiki 
> project page than in a seqfan message. :-)

Well, let's continue brainstorming for possible improvements now; once we 
have the wiki we can start copying across ideas to there and developing 
them further.

> All great ideas, IMHO. My ulterior motive is, once we have localized the 
> sequence data into the (hidden) b-files, we can use the b-files to 
> auto-generate sequence attributes (%STUVWXO lines, some keywords, etc) 
> and views (list, graph, listen, download = current b-file link).

Or view/download as a decimal constant, or as a table - or in a different 
base for those "base" sequences not related to base 10 where the numbers 
are entered in base 10.  (As sequences of *integers* not *digit strings*, 
entering the integers in base 10 is the mathematically correct way of 
storing sequences related to any base - but not the most convenient for 
spotting patterns.  Some sequences are present in both the mathematically 
proper base 10 form, and in the own-base form.)

> Once we have localized the numeric data into the b-file, we can begin to 
> think about, say, auto-generating the b-file itself for simpler sequences.

Yes, there are some sequences for which it should really be a matter of 
entering the range you'd like to download as a b-file, rather than just 
storing some initial segment precomputed (though the initial precomputed 
segment will still be needed for searches).

Groups of sequences that are identical apart from their initial terms and 
offsets should really only need one b-file between them (extending one 
should extend all).

> > - Reference and external link databases separate from the uses of those 
> > references and links in individual sequences, so only one place needs 
> > changing to update a widely used reference or link (e.g. changing a 
> > reference to a preprint to refer to the final version, updating a link to 
> > a website that has moved).
> 
> What a concept. We maybe could do the same for, say, editors, 
> contributors and references and indeed OEIS entries, so that when they 
> moved or changed, we need only update them at one location. The OEIS 
> looks more and more like, well, a database.

When you do this for editors/contributors it also helps address the email 
address problem - you have a profile for each contributor with a real 
name, an email address or web page for contact purposes (possibly with a 
CAPTCHA or registration required to get the email address if there are 
spam issues) and maybe other information the contributor wants to add, and 
just one place to change if the details change or someone no longer wants 
an email address listed directly.

-- 
Joseph S. Myers
jsm at polyomino.org.uk