Wikispooks talk:Semantic Mediawiki
Cleaning SMW Data
There must be ways to remove these unused properites - if needs be, using SQL queries. A higher level way is preferable of course, so possibly from Special:SMWAdmin. If that doesn't do it, it might be worth reading http://semantic-mediawiki.org/wiki/Help:Repairing_SMW%27s_data. Robin (talk) 12:23, 13 December 2013 (GMT)
- That was my initial reaction on seeing them too, but inquiries to the SMW mailing list brought several replies from people with the same problem and none from the SMW admins/gurus with a possible solution - other than direct SQL querying with phpMyAdmin. I will have a good look at the 'repairing data' pages again though because site SMW functionality is bound to be compromised to some degree by still using 'Data Store 1'. What I have learned from the SMW list and site posts to date is that the SMW user-base is much smaller than I previously thought. That does not bother me too much because the developers are keen as mustard. Down side is have little time for non-geeks with what they probably see as elementary problems outside genuine and obvious bugs - of which there are many - but usually promptly fixed. --Peter P (talk) 13:12, 13 December 2013 (GMT)
- Looks like the SMW underlying DB data can be rebuilt from scratch. Not just the SMW admin update script, but a delete the lot and rebuild approach. It's server intensive with potential for screw-ups too so I want to be quite sure before embarking on it. Also, if you have SMW on UG it is probably worth announcing it and joining the SMW list. With no obvious connection between us separate posts on issues may get more attention from the geeks who have the answers - Not that I wish to hide connections but let others make tham - something like that. --Peter P (talk) 17:10, 13 December 2013 (GMT)
Namespaces
How about using more namespaces to differentiate page subjects?
| Namespace | Mandatory Template | Semantic Form | Use |
|---|---|---|---|
| document: | Template:DocProv | Form:Document | 3rd Party Publications |
| book: | Template:Book | Form:Book | Articles about books |
| person: | Template:Person | Form:Person | Articles about people |
| event: | Template:Event | Form:Event | Articles about events |
I like the semantic forms - a good help to people to create semantic data.
Robin (talk) 12:36, 13 December 2013 (GMT)
- What's wrong with disciplined use of top-level categories to do the same thing - plus radical pruning of the category tree by replacing most sub-categories with properties - but better thought through? A category can be assigned a default form too. I confess to still struggling a little with the best/optimal way to differentiate Name-space, Category and Property usage though. For example, I was going to put timeline events in a separate namespace; even created it and put all the necessary stuff in LocalSettings.php. In the event I didn't use it (yet) and currently don't plan to. Beyond a certain clarity, all that user-defined namespaces do is place an additional word (with hidden number for DB usage) and colon before the page title which can also be a bit of a pain. And there are a lot of both 'Person' and 'Event' pages already in 'Main' - though most are assigned to sub-categories of Category:People and Category:Events. --Peter P (talk) 13:35, 13 December 2013 (GMT)
- Oh, I hadn't noted that forms can be assigned to categories - so namespaces are not actually needed to do this. I think the clarity they afford may make them worthwhile in the end (today I edited [[Document:The Franklin Scandal], an introduction to Book - The Franklin Scandal about The Franklin Scandal). Though I made the Template:Doctypes categories today, this is a bit of a transitional step/use of legacy technology - the actual 'meaning' of category (~"is associated with") is a bit fuzzy, so longer term I think we're better off replacing them with more precise semantic alternatives. When we know enough about how to fit the bits together. Inspired by the success of SMW here I also added SMW to the UG Wiki today, so I should be getting a bit more experience on how to manage things. Robin (talk) 15:06, 13 December 2013 (GMT)
- Probably best to let things settle down for a bit after all these major changes and upgrades. As you say get a bit more experience managing things. BTW - Your (almost tentative) suggestion of making Document subjects the name(s) of ordinary (Main NS) articles was inspired. It has the potential to tie all 3rd party content to crowd-sourced articles that can further develop, research and explain it. I can't help tinkering every time I see an edit on 'Recent Changes' to a document that takes me back to when I originally put it up. There's a lot of stuff here that would benefit from easy intuitive linking and browsing and SMW looks like an impressive - and fairly easy - way to realise it - to me anyway. --Peter P (talk) 16:59, 13 December 2013 (GMT)
Thoughts on Properties
To Robin: I am a bit clearer about properties now. In choosing a property name it is important to be clear about what EXACTLY it describes - ie what it's subject and object are. For example, present use of "Is author" for Documents is semantically incorrect. A document isn't an author, it HAS an author. A person IS an author. So, I propose to change the 'DocProv' 'FileProv' 'IFrameDoc' templates - and any others that currently use 'Is author' to identify the content author - to Has author, using the standard RDF (Document/content)-subject (Has)-predicate author-(object) model. The 'Is author' property can remain for People who ARE authors - (Person)-subject (is)-predicate (author)-object. A document HAS author x because the Document is the subject and x is the object. If a property has type "Page" then a page (pre-existing or not) is it's object. All this seemed trivial to me until I assigned the property 'Is author' to the name 'William Blum' on the William Blum page and saw that that caused the page to be included in the list of his authored documents displayed by the template 'AuthorDocuments' (could live with it but a niggling inconsistency and probably the first of many if not nipped-in-the-bud). So I went and had a good read about RDF etc. I'd rather be picky close to the outset of SMW development than be faced with unraveling a mess (like the current category tree) later. All this also applies to 'Is publisher', 'Is recipient' and 'Is translator' - it's the document that HAS publisher, recipient and/or translator. The other current big use property ('Is about') is - thankfully - RDF correct.
I'd like to tackle this Sunday pm 15/12 before rebuilding all semantic data and trying to get Datastore 2 operational. However, I'd like your thoughts first - It can be left 'till next week otherwise --Peter P (talk) 19:06, 14 December 2013 (GMT)
- Yes, defining RDF there is no room for ambiguity. 'Is author', 'is recipient' (& probably others) should be 'has author', 'has recipient'. Good work for spotting this. The sooner the better. As long as it's done through templates, it'll be easy to fix. Robin (talk) 01:45, 15 December 2013 (GMT)
Thoughts on namespaces
I think we should stick with the existing namespaces - at last for now and proceed as follows:
Have separate namespace templates and default forms for NS:Document and NS:File - DocProv as is, and FileProv cloned with any minor modifications required, plus Form:Document and a new Form:File. They will clearly be very similar - almost clones in fact. At present we cannot assign a default form (ie show the 'edit with form' option) for Files of category 'Doc' because 'Doc' also includes NS Document pages that already have a default form. The FileProv template and form need not cater for image files because they will only be used for editing pre-existing pages that are created by the regular file upload process.
- I'm going to pitch in a vote for keeping these identical (i.e. with the forward, as currently is) unless I can find a good reason to split them. There is nothing to stop the different namespaces adding separate parameters if needed. But having multiple copies of the same code is asking for trouble - unnecessary work to update etc. Robin (talk) 02:16, 15 December 2013 (GMT)
- OK. I've removed the 'Has default form Document' property from the Document namespace and added it to the 'Doc' category. The 'Edit with form' option now appears for ALL pages of Category:Doc, whatever namespace they are in. There are well over 600 such files. I reckon maybe 150 of their pages currently include even the 'FileProv' template so there's plenty of work for anyone who fancies making semantics available even for the few properties currently defined :-)) --Peter P (talk) 07:49, 15 December 2013 (GMT)
"We can then have as many separate template/form combinations in NS:Main as may be necessary for certain top-level categories (ie Books, Events, People etc) and there would be NO default form for NS:Main itself - just selected categories. Thoughts?" --Peter P (talk) 19:40, 14 December 2013 (GMT)
- Sure - Main shouldn't have a default form, as it's a catch all category. Currently that just means non-documents, but in future, that might be 'everything else' after books, documents, event, people have been removed. I'm still leaning towards namespaces as a way to keep things clear. e.g. If someone makes a link "[[Event:Bay Of Pigs]]", it's clear what they mean, and someone clicking on that link can automatically get the right form to create it. But that's not to say that this is an priority - we can try this out with categories for now, still got some groundwork to do building the appropriate templates and semantic forms. Robin (talk) 02:16, 15 December 2013 (GMT)
