Semantic MediaWiki: Difference between revisions
(→Issues for test results: I have a dream...) |
m (categorize) |
||
Line 178: | Line 178: | ||
=== Generic names === |
=== Generic names === |
||
Should [[Property:Objective]] be a generic name, or specialize it to [[Property:Test case objective]] ? skierpage's bias is to use generic names, but document on their property page what templates and pages use them. |
Should [[Property:Objective]] be a generic name, or specialize it to [[Property:Test case objective]] ? skierpage's bias is to use generic names, but document on their property page what templates and pages use them. |
||
[[Category:Semantic MediaWiki]] |
Revision as of 06:45, 4 August 2008
Motivation
There's a lot of information in wiki.laptop.org. wikipedia:Semantic MediaWiki is an extension that lets you annotate existing wiki text and templates so that you can query and redisplay this information. Done right we get less duplication, more standardization, and easy information reuse.
Here's a simple example: this queries test case pages and displays the stream to which they apply:
{{#ask:
Objective::+ | ?Objective | ?Stream | limit=5 | default=No articles found with Property:Objective ?
}}
You can get a similar list of pages by browsing Category:Test cases, but then you would have to read each page to find the streams to which it applies.
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
- Ignore semantics in a specific name space
- Alt text not working in templates
- Feature part of Tests/Sugar_Control_Panel/About_Me/Color_Change
- 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
- 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"
Using semantics on wiki.laptop.org
Here are some ideas for using semantics. The key is not to do this for its own sake but to make life better for wiki users — explain the benefits before doing the work.
For tests
Many tests are using semantic annotations, so we can query for them. See Test cases 8.2.0 for an example.
To display query results so that they look like the test case (green badge), use format=embedded. To display in some other format, someone has to create Template:Display_query_row_in_a_gray_box and use format=template | template=Display query row in a gray box
Some test results are also using semantic annotations, see TestResults 8.2.0.
Issues for Test cases
- Compare Tests/Sugar Control Panel/About Me/Color Change and Eben's Tests/Home view, latter uses different terminology: Justification (like Feature?), Actions (like Procedure?, Verify (like Expected results and pass criteria?
- Should Property:Build be in the test case? Seems like it only belongs in results.
- Property:Stream could usefully have service links to builds, diffs, packages, etc., but that requires lowercase names. See Property:Stream for a discussion. skierpage changed the names to lowercase but that doubled checkboxes in the Test case form.
Structuring Test cases
Use subcategories of Category:Test cases 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/Sugar_Control_Panel/About_Me/Color_Change is organized on Test cases 8.2.0 under
- Sugar Control Panel
- About Me
Maybe there should be subcategories for these (with "TC" in them to disambiguate from other hierarchies). The editor would enter a subcategory when editing a page, surrounded with <noinclude> so pages that include it don't get re-categorized, e.g. <noinclude>[[Category:TC Sugar control panel]]</noinclude>.
Or should the tests continue to have detailed article names Tests/Sugar Control Panel/About me that when you query for things in Category:Test cases, you get all the names? Putting the organization in the name ensures test cases will appear in the right order in generic queries. But it makes for a long name.
Issues for test results
Test cases 8.2.0 is one page with many test results on it; so the page winds up having two values for Property:PassFail, "Pass" and "Fail". But to isolate each result, you would have to create a separate page for each combination of test case and build, e.g. TR_Build2230/Sugar Control Panel/Date & Time. That's a lot of pages to name, although Semantic Forms can automatically generate a unique page as you fill in a form]. Is there any reason to have semantics for each test result, when you can simply visit a page with the test results?
- TODO: figure out a generic way to have a link _Log a test result_ that when clicked goes to Form:Test_result and the wiki editor fills in a form that creates a test result linked to the original page. Then any page with a test on it can be "filled out" with test results that anyone can enter!
- Property:PassFail perhaps should be Type:boolean, just Pass true/false.
- Property:Trac bug number perhaps should be Type:URL, see discussion above.
For projects
(from seth?) Very generally, any thing with tasks that can be tracked and assigned.
For deployments
See pages in [[:Category:Deployment]
- add semantics to some of the fields in Template:Country_info so a query can show the status of deployments.
- Note: a page transcluded into other pages like this will generate semantic annotations in them. Surrounding the transclusion with [[SMW::off]] ... [[SMW::on]] will prevent this.
- add Property:Coordinates so each can display on a map
For activities
Adapting activities and their templates to use Semantic Forms would make it easier to
- maintain the Activities page
- show the status of activities in various activity packs
- query for things like activities that don't have a translation status.
However first need to address, High-priority problem: The activities page, has info for 656 but may nor run on 8.2.0 We need to show status information for multiple streams for the activity.
Maybe activity can link to show the tests and test results for it. To do this need to have well-known names that can be inserted into page and category names.
For releases
Put the information in Releases into separate sub-pages. Then Releases page can just be a query for the information. Then each ECO can query this information instead of repeating it.
Greg's concern: identify and separate past (definite) releases from future (indefinite, in-planning) releases.
Seems straightforward, unlike test cases there aren't hundreds of release pages.
wiki.laptop.org issues
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.
Generic names
Should Property:Objective be a generic name, or specialize it to Property:Test case objective ? skierpage's bias is to use generic names, but document on their property page what templates and pages use them.