Semantic MediaWiki

From OLPC
Revision as of 17:04, 1 August 2008 by Femslade (talk | contribs) (Trivial Fixes (ie just install something/ fix something that’s already installed))
Jump to: navigation, search

Trivial Fixes (ie just install something/ fix something that’s already installed)

Edit with form tab
Semantic google maps
Way to embed google maps in wiki with locations of projects/deployments and with links to appropriate wiki pages.
Create a property of Type:Geographic coordinate and you get "service links" to Google maps for free (see e.g. [1], click the (?) symbol). However, displaying several such locations on one Google Map is tricky, you either need the Semantic Google Maps extension with SMW version 1.2 and/or the Google Maps extension (see example) -- Skierpage 10:26, 31 July 2008 (UTC)

Easy Fixes (ie just edit a little bit of code)

Auto generate templates
Make template an activity and edit with form
Move around the <no include> tags
But when empty it should show something
Make a tag that says this is not semantic stuff


Add new types
  • It's easy to add a property that has some built-in type (like [[Has type::Text]] and restrict it to certain values and maybe control its format.
  • It's possible to add a new "linear" type that converts between different units , e.g. a Type;Area
  • it's hard to add other kinds of types, it requires writing PHP code.
  • -- Skierpage 10:42, 31 July 2008 (UTC)
Time duration
If you want auto-conversion between e.g. weeks and days and seconds, copy what you want from [2] -- Skierpage 10:42, 31 July 2008 (UTC)
User
Not sure what this means. If it's links to User:skierpage then maybe just create Property:User of type:page.
Trac
This could be done as Property:Ticket, of Type:URL and you use a template to fabricate the URL, or Property:Ticket of Type:Number and you use Service links and templates to turn the number into a trac URL.
Image
Just some property of Type:Page (the default), in most cases SMW do the right thing and display the image .
Template?
Not sure what you mean.


Make the free text box larger.


When creating a template, you should be able to create properties in that window as well as use already created properties.


Way to 'prettify' links when used in SMW properties with a "Page" type.
Example: Color Change instead of Tests/Sugar_Control_Panel/About_Me/Color_Change.
See #Suggestions_for_test_cases. Maybe have a "Brief name" property and display that while linking to the full page name. Or, in queries use format=template and in the template use a parser string function to change the title from Tests/Sugar_Control_Panel/About_Me/Color_Change. Or, use categories to identify the hierarchy. You risk collision if the page title is just Color change, so you could have a little "TC" prefix, just TC/Color Change or a pseudo-namespace TC:Color_change


Translating Property names
Nathany on #cc


When making a template add a more organized presentation of properties

Complex fixes (ie require creating a new extension)

Aggregate semantic information using a template
I think you mean by using templates on pages, then aggregate the information from those pages not by copying and pasting or transcluding, but by making inline queries of semantic data.


Something in between a list of specific allowed values and free text
I want to be able to have the equivalent of an other field
One approach: have two properties like Property:Version and Property:Version_more that you always display together, the first has restricted values, the other is text. Another is to use Type:Page and have pages for the allowed values. So not-allowed values "work", but stand out in red.


Way to automatically email users who maintain pages


Automatically populate data
ex page last updated case
SMW 1.1 can't query on or display such metadata. I think other extensions like DPL can.
Way to pull %translated from pootle
Could have a bot that gets this information and populates wiki pages with it.

Semantic annotations

The wiki has the wikipedia:Semantic MediaWiki extension installed, the thing to do is use it appropriately.

Successful rollout suggestions

  • Deliver benefits early.
    • To a casual editor, SMW is just more markup, more stuff to learn, an ugly factbox on pages, more "Semantic Web 3.0" hype. So find use cases that deliver obvious benefits early
  • Don't create lots of properties and spend time annotating lots of pages until you have use cases for them. A person reading one wiki page after another does not need semantic annotations.
  • It's fine to convert templates to make semantic annotations, since you get this "for free"

Semantic MediaWiki in use on wiki.laptop.org

Template conversion

  • Use arraymap to turn lists of things into multiple property assignments.
  • Use Semantic Forms... (not sure about it)
  • Beware, people take advantage of wiki markup to stick all kinds of text inside templates. Maybe have an "fieldname extra info" field for arbitrary text.

For tests

Many tests are using semantic annotations, so we can query for them. See Test cases 8.2.0 for an example.

Suggestions for test cases

Use subcategories of Category:Test Case to identify the kind of test. A query for a category will find things in its subcategories, so it's fine to have a detailed category hierarchy.

Example, Tests/Acquiring_a_developer_key is organized on Test cases 8.2.0 under

  • Sugar Control Panel
    • About Me

So should Template:Test_case have

  subcategory|=Sugar Control Panel
  subsubcategory|=About Me

that fabricates a category and allows organization?

Or should the editor choose a subcategory when editing a page?

Or should the tests have such detailed article names Tests/Sugar Control Panel/About me that when you query for things in Category:Test Case, you get all the names?

Hmmm.

For projects

Very generally, any thing with tasks that can be farmed out.

For deployments

For activities

For releases

Put the information in Releases into separate pages. Then each ECO can query this information instead of repeating it.

Generic names

Should Property:Objective be a generic name, or specialize it to Property:Test case objective ? My bias is to use generic names, but document on their property page what they are for.