That would work, but then, why don't we reduce this to an existing technology and use the templates:
<LIT:occurence=Tiger,book=Winnie-the-Pooh,name=Tigger>
could easily become
{{LIT|occurence=Tiger|book=Winnie-the-Pooh|name=Tigger}}
where [[Template:LIT]] could be blank, or [[category:Book|{{{book}}}]] or something you want to display in the article.
I *strongly* advice against any table hardcoding for species etc. Instead, what you'd want to do is make a table with the fields * article ID (of the imaginary tiger) * type ("LIT", "TOL" etc.) * key ("book") * value ("Winnie-the-Pooh")
This will complicate the search query, but make it more flexible.
The parsing of the above is already done; what would be missing is * the storage of the ID/type/key/value in a table (quick hack) * a special page to retrieve the information from that table (longer hack) * most important, a schema that we all agree upon *before* we store anything in that table. Otherwise, we'll have "book=", "title=", "volume=", all meaning the same thing.
Magnus
Till Westermayer wrote:
. . . . . . . . . . . . . . . . . . . . . . . . . . . till we *) . . .
Hi Magnus,
there seem to be two obvious possible solutions: the one you described, and the one I described (below). While thinking about my proposal, I thought along the lines of your proposal (not in that general way, rather in the form of: let there be a part commented out in the wiki source, that is only interpreted in wikispecies). Your optional-tag is a much more general and elegant solution to that problem. But I'm still not sure if it is the best solution (even if it is relative easy to hack). This is mainly because I think what project like WikiSpecies, or maybe WikiStamps, WikiRamBotUSTowns, WikiElections etc. need in additionto the free form text editable in Wikipedia is something like a wiki-definable db (so Tim's general WikiDB approach seems to go more in that direction). The other thing all these possible projects have in common that they should continue to be anchored in Wikipedia, but they also should have the db information. One could do that with the solution I proposed, i.e. by using separate but somehow linked dbs and interfaces, or one could invent a special markup for custom variable fields in the wiki text (i.e. something like the Semantic Web people are doing, if I understand their approach correctly). I'm not sure if using markup for db fields to simulate a db in a db is such a good idea, but it's easy editable, that much is sure.
A typical entry on, say, a totally bogus tiger, could maybe look like this in a markup-db-solution:
Tigers are [[mammal]]s living in the [[Sibiria|Sibirian]] [[Tundra]].
...
== Species data ==
[[kingdom]]: [[animal]]s <TOL:kingdom=animalia> [[family or whatever that is]]: [[mammal]] <TOL:family=mammalia> [[species]]: big cats (''felibigus'') <TOL:species=felibigus>
...
== Trivia ==
Tigers are a big issue in Winnie-the-Pooh, especially one tiger called Tigger. <LIT:occurence=Tiger,book=Winnie-the-Pooh,name=Tigger>
This would give the following pseudo db entries:
in the Tree of life database (short: TOL)
in the kingdom table the relation key:Tiger <-> kingdom:animalia in the family table the relation key:Tiger <-> family:mammalia in the species table the relation key:Tiger <-> species:felibigus
in the Literatur database (short: LIT)
in the occurence table the relation key:generated <-> occurence:Tiger,book:Winnie-the-Pooh, name:Tigger
((key generated because the article name appears on the right side of the pseudo db entry in the wikipedia article -> brings to our attention the problem of n:m relations))
I don't know if it is possible to automatically parse changes in such entries to maintan databases. One (rather brute force way) would be to delete everything in such a database which has the article name key of "Tiger" if the article is changed, then parse the article for pseudo-db entries marked with <<...>> and insert the information anew.
There could be a / a lot of specialized interfaces for queries on this database (which is something separate from the wiki article text db), where on could say something like (in very pseudo SQL):
SELECT from the TOL database from the kingdom table all entries where kingdom = animalia
gives back formatted information on Tiger (see Wikipedia article, see all TOL information, see all information) Cat Shark Homo sapiens ...
Just some ideas, some thinking aloud.
Alternate solution, which would require much less special cases:
- introduce "<optional type=wikispecies>lots'o'data</optional>"
tag, which will ** show the data for everyone who has marked himself as a member of wikispecies project in user settings ** show a link "More detail information" for everyone else; that link will then display the full thing
- introduce "<categorytree>" tag, which will show a category tree
for the current article ** attribute "super=1" to show the category below, "super=all" to show everything down to the root ** attribute "sub=1" to show the next subcategory, "sub=all" to show them all
This is
- relatively easy to hack (hide "optional" section unless
this-and-that condition)
- usable for many sub-projects like histroy etc.
- allows everyone to get all the data without "average" users
being squashed by it
- fully transparent for searching (search will find keywords in
the "optional" secation as well)
If required, we can parse-out the "optional" part for editing. But that's optional ;-)
Magnus
Daniel Mayer wrote:
This sounds interesting...
--- Till Westermayer till@tillwe.de wrote:
How to implement this technically speaking, I don't know, but how about this:
- The Wikispecies interface only shows article tagged with
Category:Wikispecies (or whatever is the best category).
- This project uses a specific parser, allowing for the
implementation of tree navigation and a more "scientifically" looking output of data (that can be found in the taxabox).
- Maybe other data is in the articles used as source for
Wikispecies and hidden somehow (via a special comment mode or some other specialized tag in the article, or even as additional stored data in a separate db, accessed via the article name = scientific species name as key)
- "Edit this entry" in the Wikispecies interface would bring up
a window consisting of:
- the wikipedia edit window showing the source text - additional data input fields
- A user in the wikipedia proper will only see the wikipedia
article, but not the additional data. The only thing other for them is the "Category:Wikispecies" tag (which would explain, when opened as article, what Wikispecies project is and how to access it in the "scientific" interface).
__ . / / / / ... Till Westermayer - till we *) . . . mailto:till@tillwe.de . www.westermayer.de/till/ . icq 320393072 . Habsburgerstr. 82 . 79104 Freiburg . 0761 55697152 . 0160 96619179 . . . . . _______________________________________________ Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush _______________________________________________ Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
__ . / / / / ... Till Westermayer - till we *) . . . mailto:till@tillwe.de . www.westermayer.de/till/ . icq 320393072 . Habsburgerstr. 82 . 79104 Freiburg . 0761 55697152 . 0160 96619179 . . . . . _______________________________________________ Wikipedia-l mailing list Wikipedia-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikipedia-l