|This page is a proposal for a new Wikimedia Foundation Sister Project.|
|Reason||Sort of a predecessor of Wikidata. --Sannita (talk) 21:04, 17 September 2013 (UTC)|
|What is the proposed name for the project?||Slotipedia - A Proposal|
What is the project purpose? What will be its scope? How would it benefit to be part of Wikimedia?
|How many wikis?
Will there be many language versions or just on one multilingual wiki?
|How many languages?
Is the project going to be in one language or in many?
If the project requires any new features that the MediaWiki software currently doesn't have, please describe in detail. Are additional MediaWiki extensions needed for the project?
I would like to propose a new project, related by separate to Wikipedia—Slotipedia. Both would aim to be encyclopedias, of sorts; but they would differ as follows: Wikipedia articles are free-form; Slotipedia articles are restricted to a precise framework, a set of slots to be fit in. Suppose we have an article about Albert Einstein. A Wikipedia article might look like the following:
- Albert Einstein, born in 18xx in Austria, is a Nobel Prize-winning physicist famous for formulating the Theory of Relativity...
While a Slotipedia article would look like:
- 1. PERSON: Albert Einstein
- 1.1. YEAR-OF-BIRTH: 1800
- 1.2. COUNTRY-OF-BIRTH: AT (Austria)
- 1.3. NOTED-OCCUPATION: Physics
- 1.3.1. CREATED:
- 184.108.40.206 SCIENTIFIC THEORY: Special Theory of Relativity
- 220.127.116.11 PUBLISHED-IN:
- 1.3.1. CREATED:
Okay, so this is really like a cross between an Encyclopedia, and a knowledgebase for some kind of AI application (although the user is left to come up with the AI application to use it:). The main idea here is to structure the data very precisely. This makes searches possible (e.g. what 18th century composers were born in France?) with a precision that otherwise would not be available (there may be many articles containing "France", "18th century" and "composer" which do not answer this question... for example, a 17th century German composer, who had to flee temporarily to France due to disfavour at the court, and whose work was rediscovered in the 18th century after many years of neglect...). It also is filled with lots of suggestions for more information required—e.g. if there is an empty slot for "YEAR-OF-BIRTH" under a person, that serves as an instant suggestion to go research that information (the system could even generate automatically a list of unanswered questions, e.g. "In which town or city did Friedrich Nietzsche die?").
In the initial incarnation, I propose restricting Slotipedia articles to being biographies, since they have lots of easily structured slots (e.g. DATE-OF-BIRTH, PLACE-OF-BIRTH, WROTE-BOOK, HELD-OFFICE, NOTABLE-PROFESSION...) Maybe later extend it to things like countries and so on. Of course, since it is structured, it is unlikely to ever have the same depth of detail as Wikipedia (some topics are two complex to be reduced to a simple structure of ENTITY SLOT VALUE), but since the emphasis would be on breadth, not depth, it might be much wider (and would be much more amenable to computer processing).
Wikipedia could be used as a source of information for Slotipedia, and Slotipedia objects could be linked to corresponding Wikipedia articles.
To develop Slotipedia, the first step would be to develop the Slotipedia software; this should be a general purpose collabarative high-level database system. The next step would be to define and document the slots (define the classes of entities, the slots they can have, and the data types those slots must have, and create documentation to explain to the user the purpose of the slot and the rules governing its use.) Finally, Slotipedia could be populated with data.
Instead of a separate project, maybe you could include slotipedia markup in normal articles, so in any article you could have <DATE-OF-BIRTH>May 1, 2003</DATE-OF-BIRTH> and <DATE-OF-DEATH>May 2, 2003</DATE-OF-DEATH>, or in Wikipedia markup [ o|< May 2, 2003] and [ X|< May 2, 2003]
This sounds like a good idea. I think with articles too long it's difficult to obtain the correct information. -Adrian
Taking this to an extreme, have: Events (type, date, place, desc, etc), People (events /link to Events entry/), Places (type, location, etc.), States (or Conditions, type, date, etc). Think of it as a giant genealogy database, but not limited to that use. History, geography, sociology, ecc. Probably not practical, and certainly not too useful for aggregate research if incomplete (and would always be incomplete...) - Bwood
How about filling in all the information, and then having it generate an article? - Calmypal 00:18, 23 Feb 2004 (UTC)
This is a good idea. Customization of the slot definitions should be doable by users at RUN-TIME - not by administrators at design time. If the Wikipedia farmed out the content creation, the slotipedia would have to farm out the object/attribute (slot) creation.
This isn't as hard to do as it might appear, using an sql database.
Just create four meta-tables in a "diamond" inheritance structure with the following SQL pseudo-code for the primary and foreign keys:
class_id PRIMARY KEY)
slot_id PRIMARY KEY, class_id REFERENCES Class.class_id)
object_id PRIMARY KEY, class_id REFERENCES Class.class_id)
attribute_id PRIMARY KEY object_id REFERENCES Object.object_id, slot_id REFERENCES Slot.slot_id)
You could even hang the Class table off a parent Module table - to allow grouping sets of Classes into a Module, and then importing a Module while possibly renaming its Classes and Slots.
What you've essentially done is "soft-coded" the definition of Classes and their Slots - allowing the users to do this at run-time, rather than the programmers at design-time. So as the slotipedia evolves, the set of trees available for structuring articles would also evolve.
Of course, different articles in the Slotipedia would need different tree structures. An article on Albert Einstein would talk about his life and work - and article about Hip-Hop would talk about its producers and products. Letting users define different types of trees on the fly would permit just this.
I've attempted something like this already in Microsoft Access. It certainly gives a lot of power.
Of course, I also like the separate idea someone proposed upstream about tagging the articles themselves with the slot identifiers.
Some similar work in this area has been done using RDF (Resource Description Framework) for the Semantic Web.