From: Thomas B. <bl...@in...> - 2006-10-08 17:17:09
|
I think it would be cool if SMW exported wiki page properties as attributes and relations. I'm thinking of the following: Attributes: Last edit at Created at Edit count Page size Relations: Created by Edited by Last edit by (I'm no native speaker, so maybe the names should be changed; I think the idea is clear) This would allow a lot of useful things: * The front page could list newly created pages * Category pages could list newly created pages, the pages last edited or the biggest and smallest pages * Users could get a list of pages they had edited or created, e.g. <ask>[[Created by::Thomas]] [[Last edit by::*]] [[Last edit at:=*]]</ask> In short, with these attributes and relations, SMW can emulate many special pages, and make them more powerful and useful. Unfortunately, I don't currently have time to implement this, so I thought I'd post it here; maybe someone wants to code this up :-) What do you think about this idea? Thomas |
From: S P. <ski...@ea...> - 2006-10-09 04:53:43
|
1. Export ========= Thomas Bleher wrote: > I think it would be cool if SMW exported wiki page properties as > attributes and relations. > Plain MediaWiki's Special:Export exports the contributor and timestamp of the latest revision in XML. If you were to enhance this, why not export them as Dublin Core metadata in RDF? That's already a meaningful syntax for these properties. Another project has done this, "Wikipedia3", see e.g. http://labs.systemone.at/wikipedia3/samples.rdf It was announced on the swikig mailing list (http://www.aifb.uni-karlsruhe.de/pipermail/swikig/2006-April/000167.html ) and Markus Krötzsch responded (http://www.aifb.uni-karlsruhe.de/pipermail/swikig/2006-April/000168.html ): However, we thought about creating a meta-data complement of our RDF-export as well (where you have author, license, revision, etc. all in one place). As Markus pointed out, SMW's Special:Export RDF currently exports the facts in the article, not facts about the article. The two are separate; for example, [[last edited by::John Hancock] in the Declaration of Independence article is usually talking about the historic document, not about the Wiki page for it. > I'm thinking of the following: > Attributes: > Last edit at > Created at > Edit count > Page size > Relations: > Created by > Edited by > Last edit by > (I'm no native speaker, so maybe the names should be changed; I think > the idea is clear) > 2. Querying =========== > This would allow a lot of useful things: > * The front page could list newly created pages > * Category pages could list newly created pages, the pages last edited > or the biggest and smallest pages > * Users could get a list of pages they had edited or created, e.g. > <ask>[[Created by::Thomas]] [[Last edit by::*]] [[Last edit at:=*]]</ask> > Ahh, you're not really asking for export of page properties *from* Semantic MediaWiki, you're asking for access to page properties *within* SMW. That's different, but still an interesting idea. Some page properties are already available as variables in Wiki text like {{REVISIONID}}, see http://meta.wikimedia.org/wiki/Help:Variable#Depending_on_page. And the raw information is in the MediaWiki tables, primarily in the page and revision tables. However, to do your useful things you want to query this information using the SMW inline query syntax, and the MediaWiki variables don't help. Yes you might be able to do this as you propose: export page metadata information, then reimport it as special SMW relations and attributes. It would be more direct if you abstracted the powerful inline query facility in SMW so that queries on certain special terms turn into database queries against other tables than the smw_attribute and smw_relation tables: * Querying for your "Last edit by" would query against the revision table. * Querying for "Has type", "Main display unit", "Imported from", etc. would query against the smw_specialprops table. * If the Wikidata project takes off, querying against other special properties would query the appropriate dedicated Wikidata table. Enhancing inline queries this way is worthwhile, but I imagine it will be hella hard to code! Start at lines 477 and 523 in SMW_InlineQueries.php. Best, -- =S Page > In short, with these attributes and relations, SMW can emulate many > special pages, and make them more powerful and useful. > > Unfortunately, I don't currently have time to implement this, so I > thought I'd post it here; maybe someone wants to code this up :-) > > What do you think about this idea? > |
From: Christopher B. <sli...@gm...> - 2006-10-09 05:17:04
|
On 10/8/06, Christopher Baker <sli...@gm...> wrote: > > On 10/8/06, S Page <ski...@ea...> wrote: > > > > Enhancing inline queries this way is worthwhile, but I imagine it will > > be hella hard to code! Start at lines 477 and 523 in > > SMW_InlineQueries.php. > > > > why not just edit the code so that each page that is saved in a namespace > with semantics create these attributes/relations? > |
From: Thomas B. <bl...@in...> - 2006-10-10 08:48:35
|
(Because S Page refered to this: I'm not interested at all in exporting this data outside of the wiki.) On 10/8/06, Christopher Baker <sli...@gm...> wrote: > >On 10/8/06, S Page <ski...@ea...> wrote: >> >> Enhancing inline queries this way is worthwhile, but I imagine it will >> be hella hard to code! Start at lines 477 and 523 in >> SMW_InlineQueries.php. >> > >why not just edit the code so that each page that is saved in a namespace >with semantics create these attributes/relations? I don't think that's the right solution - the attribute and relation pages will grow far too fast, and the data is already available in the database. Yesterday I looked at DynamicPageList2, and it does some of the things I need, but SMW promises to be a much more general solution. As a use case, allmost all of the pages in my wiki have a short description, stored in an attribute. Eventually, I'd like to display this short description in every list of pages. Just imagine: If this was implemented properly, allmost all special pages could be replaced with customizable <ask/>-queries! I don't know if that's doable from a performance POV, but it would be really neat. Thomas |