WiktionaryZ currently supports multilingual free-text
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
to display the person data about Jimbo, or
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.
foundation-l mailing list
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.
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.