[Foundation-l] Project Proposal: Wikicat
Jeff V. Merkey
jmerkey at wolfmountaingroup.com
Fri Jul 28 17:59:57 UTC 2006
Erik Moeller wrote:
>WiktionaryZ currently supports multilingual free-text attributes and
>will support other data type attributes in the future. The data you
>can associate with a WiktionaryZ entitity will likely depend on what
>class that entity belongs to. For instance, if an entity is of type
>person, you could associate a birthdate, death date, place of birth,
>place of death, first name/last name (though that might be handled on
>another level), etc.
>
>If the entity belongs to the class "publication", you could associate
>references to specific edition; if it belongs to class "author", you
>could associate publications, and so on.
>
>In this generic model, a reference is just one instance of an entity
>whose associated data you might want to display in a Wikipedia
>article. So we would probably come up with a special type of template
>that can fetch data from WiktionaryZ and insert it into a page layout.
>Then you could, for instance, use
>
><<person:Jimmy Wales>>
>
>to display the person data about Jimbo, or
>
><<country:Germany>>
>
>to make a nice country infobox. Then again, you could also do
>
><<ref:The Origin of Species|author=Charles Darwin|class=book>>
>
>to show _any_ book edition of Darwin's work, or
>
><<ref:The Origin of Species|ISBN=whatever>>
>
>to cite a specific edition. If the title is not ambiguous, you might
>even only have to do something like
>
><<ref:The Cosmic and the Comic: Einstein's Scientific Spirituality>>
>
>and all the properties would be derived automatically from that. In
>fact, the WiktionaryZ model very much matches the work/expression
>distinction, though we use the terminology the other way around: an
>expression refers to _any_ possible meaning of a string of characters,
>whereas each meaning ("work" in this context) has its own defined
>meaning ID and can also be disambiguated by its relations and other
>associated data (for publications: author, year, various codes, etc.).
>
>One advantage, in my view, is that we do not require people to pass
>around codes and numbers unless they really need to and want to, and
>even then, we retain the expression (work title) in the wiki source
>text, making it easy to see what a particular reference is about.
>
>Erik
>_______________________________________________
>foundation-l mailing list
>foundation-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/foundation-l
>
>
>
Erik,
Anything you can do to reduce the dependencies on extensions is a great
move. You should incorporate all of them you
can into the main mediawiki tree. You need to setup the exportDump.php
program to output dynamically generated
image names into the actual names as well.
www.wikipedia.org/wiki/Chess
is a great example of HOW NOT to code a template for image generation.
It makes it a lot easier to keep images
synced up between distributed wikipedia mirrors. For now, I have
modified your php code to create a collision listing
of missing image names when the page is converted into HTML for the
first time so the wikix tools can grab and
input the images into the database.
Jeff
More information about the foundation-l
mailing list