apart from http://smw.referata.com/wiki/Category:Tips there is another
repository for best practices and tips.
It is located at
and rather deals with technical wrinkles than with abstract best
practices like "use Semantic Forms" or "provide initial base ontology".
> Thanks for the good review.
> But if you want this review published to the Semantic MediaWiki site,
> I'm not the one to do it. Automatic account creation seems to be closed.
> The Semantic MediaWiki Community Wiki seems to be open to new
> registrants, so perhaps I can try to publish my tips there.
> Jack D. Pond wrote:
>> This should be posted somewhere - Either
>> http://semantic-mediawiki.org/wiki/Semantic_MediaWiki (preferred) or
>> Nice writeup!
>>> -----Original Message-----
>>> From: Temlakos [mailto:temlakos@...]
>>> Sent: Friday, August 21, 2009 9:40 AM
>>> To: Mike Axelrod
>>> Cc: semediawiki-user@...
>>> Subject: Re: [Semediawiki-user] Best practices wanted...
>>> Here is another practice that I would like to contribute.
>>> It's been awhile since I took over the administration of SMW
>>> from a prior developer, and sometimes I have to refresh my
>>> own memory of what I did.
>>> Declare all properties. I say again: declare all properties. Yes, I
>>> know: by default, an undeclared property is assumed to be of
>>> type Page.
>>> (The old Relations were all of that type.) But I still adhere
>>> rigorously to that practice.
>>> Decide ahead of time what are the most common custom types
>>> and properties that you will need, and implement those right
>>> away. It's a lot easier to create a bunch of types and
>>> properties in advance than it is to reannotate a bunch of
>>> articles after the fact.
>>> As I said before: Whenever possible, develop templates that
>>> handle semantic annotation within their own code. Make those
>>> templates easy to use; otherwise, users won't use them. It's
>>> that simple. In this
>>> connection: Absolutely any sort of data that is repeatedly
>>> mentioned in multiple articles is a candidate for semantic
>>> annotation. (And don't be afraid to use Type:String as a
>>> datatype; not all annotated text needs to be a separate page.)
>>> The best time to implement SMW is when the wiki is just
>>> getting started.
>>> Failing that: Make sure that you have the full involvement of
>>> the user community and your colleagues and superiors in
>>> administration! Different people have different ideas on what
>>> sort of data is proper to annotate, and also on the new
>>> theory of semantic concepts: some administrators prefer to
>>> assign articles directly to MediaWiki's categories, while
>>> others, with a little persuasion and a demonstration project,
>>> might let you create a semantic Concept and watch as it acts
>>> like a "dynamic category."
>>> If you /do/ use concepts, then try to invent some way of
>>> referring people to your concepts so that they can browse
>>> them whenever they need to. (I haven't yet used Semantic
>>> Drilldown; that sounds very much as though it would provide a
>>> "concept tree" or something similar.)
>>> Expand on the definitions of all standard types and special
>>> This serves two purposes:
>>> 1. In many cases it constitutes encyclopedic knowledge and is
>>> therefore valuable in that context alone.
>>> 2. It lets your users know what those types and special
>>> properties are
>>> good for and how they work. As such it is part of the help
>>> system. Good help, like good security, is redundant.
>>> Similarly, you should expand on your custom-type definitions.
>>> A good custom type definition must contain more than several
>>> [[Corresponds to::x number of units]] declarations. It should
>>> also have a clear statement of its intent.
>>> Expand on property declarations for the same reason. I always
>>> try to work my [[has type::x]] declaration (and, where
>>> applicable, my [[units of measure::x,y,z]] declaration) into
>>> a paragraph describing the property and its applicability. On
>>> my wiki, I have Length defined as a type. My base unit is the
>>> meter, but I support all reasonable divisions (and multiples)
>>> of the meter, and also US Customary units, some ancient
>>> units, and even the classical Astronomical Unit, the
>>> light-year, and the parsec. I then can declare multiple
>>> properties of this type, each of which has its own places to
>>> apply it. I already have separate properties for the
>>> semi-major axis and peri- and apo- apsides of an orbiting
>>> body, and also the length, breadth, and height of a building,
>>> or the standing height of a man. Now obviously I am not going
>>> to describe a man's standing height in fractions of an AU, or
>>> the semi-major axis of the dwarf planet Eris or the (alleged)
>>> companion star Nemesis in meters!
>>> That's what the selective units-of-measure special property
>>> is for--but this requires a bit more explanation than the
>>> minimum code required.
>>> This is actually analogous to the difference between code and
>>> comment in a program (or a PHP script). Comments are the
>>> means by which we remind our users, or our successors and
>>> assistants in SMW management, why we declared our properties
>>> and custom types as we did, and how we understand the proper
>>> uses of standard types and special properties.
>>> I do have one special situation: I built a nonlinear custom
>>> type, and until SMW 1.4.3 I had to alter the DataValueFactory
>>> script file to recognize a "new standard type." Now that I
>>> have enhanced the actual standard type, I simply redeclared
>>> all my properties that used the custom type, to be properties
>>> of the standard type. But now I have an "article" in the Type
>>> namespace for a non-standard type that lacks any definition
>>> code appropriate to custom types. For that reason, this
>>> "type" shows up in Special:Types with an error flag. But I
>>> don't want to discard the text completely. So I shall
>>> probably move that text to another namespace that I have
>>> created for "essays," or simply to the Help namespace. I'm
>>> not prepared at this point to create a special namespace for
>>> obsolete custom types!
>>> But one way that I could leave the article where it is, and
>>> make the error flag go away, would be if I could explicitly
>>> /define/ the old custom type as an /alias/ of the standard
>>> type that now subsumes it. If I have one criticism of the
>>> initial development of SMW, it is this: the only way to get
>>> SMW to recognize a non-standard alias is to hack the language
>>> script file to support that alias. I think we should be
>>> allowed to declare aliases within our wiki, and would propose
>>> an additional special property [[alias of::x]] or [[alternate
>>> name for::x]] to perform that function. Either that, or a
>>> special page, available only to sysops, that permits direct
>>> access to the language file involved.
>>> One more thing: Back up, back up, back up. On our wiki, we
>>> have installed a script that performs daily backups at an
>>> hour of the day in which most of our users are fast asleep.
>>> Then I try to do my upgrades and enhancements early in the
>>> morning, because I am three hours ahead of most of my other
>>> users and can probably get the upgrade done before I end up
>>> interfering with anyone else. And if something goes wrong, I
>>> can always restore.
>>> And when I say "back up," I also mean to back up your
>>> existing SMW code. Run
>>> tar -czf semediawiki-lng.tar.gz SemanticMediaWiki
>>> where "lng" stands for "Last Known Good." Then if you install
>>> a new version of SMW, and the code hangs up or otherwise
>>> gives an indication of being unsafe, you can revert it easily:
>>> rm -Rf SemanticMediaWiki
>>> tar -xzf semediawiki-lng.tar.gz
>>> You might in fact wish to automate these commands in shell
>>> scripts that you can invoke when you need to. But: make sure
>>> that you keep those shell scripts in "600" mode (that is,
>>> user has read and write, but not execute, privileges, and
>>> "group" and "everyone" have no privileges) until you need to
>>> use them. Then change the mode to "700", execute the script,
>>> and change the mode back to "600" when you're done with it.
>>> And now a more definitive "war story," to explain how and why
>>> I developed these practices:
>>> Our wiki, <http://creationwiki.org/>, is a multinational
>>> wiki. On our server we have one primary directory having our
>>> wiki in English, plus several subsidiary wikis, each in a
>>> different language, and finally a "pool" wiki containing
>>> images that are available for all articles in all our wikis.
>>> When I joined as an editor, and then as an administrator, my
>>> predecessor as the chief developer had installed SMW 0.6.
>>> That, if anyone still remembers it, had the old Relation and
>>> Attribute namespaces. For reasons that I never investigated,
>>> no one /ever/ declared any "attributes" or even paid
>>> attention to any /types/ that SMW had available to it in
>>> those days. The only thing we used, in short, were relations.
>>> On the day that I took over as chief developer, SMW 1.0 came
>>> out. That's when I found out how much richer it was than
>>> something to use to track relationships among articles. But
>>> in installing it (actually migrating form SMW 0.7 to 1.0), I
>>> had to migrate all of my Relation declarations to Property
>>> declarations of type Page. Once I had done that, a lot of
>>> frankly weird Factbox entries vanished.
>>> Then I also plunged myself into two parallel efforts:
>>> 1. Writing Help pages for semantic usage and development.
>>> 2. Extending the development of SMW to go beyond simply page-type
>>> 3. Demonstrating the utility of SMW to the site's founding
>>> so that he would authorize its installation in the other languages.
>>> The third part turned out to be easy; once I showed him what
>>> SMW could do with queries (especially the building of dynamic
>>> tables), he approved the extensions. That, of course,
>>> required me to write my own language script for Korean, find
>>> an appropriate language script for Chinese, and eventually
>>> (though this came much later) to collaborate with a Brazilian
>>> native to create language support for Portuguese.
>>> But soon I had a problem. SMW had a means by which to annotate dates.
>>> But those dates used Unix-derived date-and-time-parsing
>>> functions, and stored the date as the number of seconds on
>>> either side of the Unix Epoch, which was one second shy of
>>> midnight on New Year's Eve in 1969.
>>> At a minimum, this date would be unsuitable for annotating,
>>> say, the dates of birth and death of men like Galileo Galilei
>>> and Sir Isaac Newton. For dates before the common era--well,
>>> as we say in American English, forget it! About all that I'd
>>> be able to annotate were launch and flyby dates for rocket
>>> probes to various celestial bodies--and I would be completely
>>> at a loss to annotate the date of discovery of any celestial
>>> body discovered earlier than the dwarf planet Pluto (1930).
>>> Worse yet, in 2038, I would run out of time.
>>> So I developed a custom datatype to handle dates in the
>>> far-distant past. In retrospect, it was a bad solution.
>>> Getting SMW to recognize that custom type required
>>> modifications in at least two different other files--and
>>> every time SMW came out with a new version, the story would
>>> be the same! Finally, with SMW 1.4.2, the situation became
>>> untenable, with the abandonment of the old getXSDValue() and
>>> parseXSDValue($value,$unit) functions in favor of getDBkeys()
>>> and parseDBkeys($args). Recently I've done what I should have
>>> done earlier:
>>> enhanced the standard Date datatype with my own modification.
>>> Happily, I had already suggested to the developers that they
>>> ought to scrap their implementation of dates in favor of a
>>> different base model--the Julian Day--that would be precise
>>> enough to store a time down to the second, yet broad enough
>>> to support any date in recorded history.
>>> Beginning with SMW 1.4.0, Fabian Howahl came out with his new
>>> date. This summer, I began systematically to enhance that
>>> date to support the different calendar models that I
>>> routinely used, and also to achieve certain goals that they
>>> had set out for themselves.
>>> Now this has required redeclaring many properties, and in
>>> some cases reannotating certain dates that were in a format
>>> that I no longer cared to support. That created a different
>>> problem: if I changed the format before changing the type,
>>> then dates that were not recognized before would be
>>> recognized after the change--but would not be stored in the
>>> database. That I installed this new version of the type
>>> concurrent with an upgrade of SMW to version 1.4.3 gave me
>>> the perfect opportunity to do the one thing that would solve
>>> that problem: rebuild the SMW database.
>>> So here's another memo: if you're going to make a major
>>> custom change (assuming that you want to hack the PHP code
>>> for that), try to time it with a major upgrade--because
>>> you're going to have to run
>>> php SMW_refreshData.php -ftpv
>>> php SMW_refreshData.php -v [-s xxxx]
>>> Since taking over as developer, I have had to upgrade SMW
>>> many times, and MediaWiki itself almost as often. Naturally I
>>> have developed some rather elaborate shell scripts to
>>> accomplish this. One other thing I have learned: simply
>>> creating "soft links" to SMW in the other directories will
>>> not work. The maintenance scripts do not resolve properly
>>> when invoked through the soft link. What happens is that
>>> SMW_refreshData.php, for example, operates on the database
>>> relative to the location of the /target file/ and /not/ to
>>> the location of the soft link. I have, therefore, had no
>>> choice but to install actual copies of SMW in every
>>> extensions subdirectory of every second-language site.
>>> Without shell scripts, this would be far too cumbersome.
>>> I have also developed many templates that accomplish semantic
>>> annotation by themselves. I have noticed, in passing, that
>>> many of my users have taken upon themselves to "annotate"
>>> certain "properties" without declaring them. So now I have to
>>> make a regular "sweep" of the Properties list, and
>>> retroactively declare certain properties according to what I
>>> find that they are actually trying to annotate.
>>> If I could sum up one thing that any semantic developer needs, it is:
>>> Dedication. Semantic annotation is something new, and that
>>> Wikipedia has taken so long even to /consider/ it for their
>>> own project speaks volumes about user attitudes. Those of us
>>> who understand what semantic annotation can do, and how to do
>>> it, have to teach others, and do most of the "heavy lifting"
>>> to realize the full value of the technique.
>>> Mike Axelrod wrote:
>>>> I am putting together a presentation on best practices for
>>> SMW. I'd
>>>> like to focus this work on pragmatic methods of developing
>>> a semantic
>>>> wiki, this would include planning, design, leading to early
>>>> implementation/prototyping etc.. I'd also like to include
>>>> social/community aspect if I can.
>>>> Any contributions in the form of links, tid bits of knowledge, war
>>>> stories, etc.. would be welcome. In exchange I volunteer
>>> to post some
>>>> of my work and/or contribute to a best practices area on
>>> whichever SMW
>>>> website is appropriate.
>>>> Mike Axelrod
>>>> blog: http://www.mikeaxelrod.com/
>>>> -------- Let Crystal Reports handle the reporting - Free Crystal
>>>> Reports 2008 30-Day trial. Simplify your report design, integration
>>>> and deployment - and focus on what you do best, core application
>>>> coding. Discover what's new with Crystal Reports now.
>>>> Semediawiki-user mailing list
>>> Let Crystal Reports handle the reporting - Free Crystal
>>> Reports 2008 30-Day trial. Simplify your report design,
>>> integration and deployment - and focus on what you do best,
>>> core application coding. Discover what's new with Crystal
>>> Reports now. http://p.sf.net/sfu/bobj-july
>>> Semediawiki-user mailing list
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> Semediawiki-user mailing list
ontoprise GmbH - know how to use Know-how
ontoprise presents the new SemanticMiner for SharePoint:
An der RaumFabrik 29; 76227 Karlsruhe; Germany
phone: +49 721 509809-0; fax: +49 721 509809-11
mailto:zaltenbach@..., www: http://www.ontoprise.de
Registered office: Karlsruhe, Germany; Register court: Mannheim, HRB 109540
Managing directors: Prof. Dr. Juergen Angele, Dipl.Wi.-Ing. Hans-Peter Schnurr