Menu
▾
▴
Re: [Semediawiki-user] Best practices wanted...
|
From: Philipp Z. <zal...@on...> - 2009-08-27 09:40:04
|
Hi, apart from http://smw.referata.com/wiki/Category:Tips there is another repository for best practices and tips. It is located at http://smwforum.ontoprise.com/smwforum/index.php/Example:All_libraries and rather deals with technical wrinkles than with abstract best practices like "use Semantic Forms" or "provide initial base ontology". Regards, Philipp Temlakos schrieb: > 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. > > Temlakos > > Jack D. Pond wrote: > >> Temlakos, >> >> This should be posted somewhere - Either >> http://semantic-mediawiki.org/wiki/Semantic_MediaWiki (preferred) or >> http://smw.referata.com/wiki/Category:Tips. >> >> Nice writeup! >> >> Jack >> >> >> >>> -----Original Message----- >>> From: Temlakos [mailto:tem...@gm...] >>> Sent: Friday, August 21, 2009 9:40 AM >>> To: Mike Axelrod >>> Cc: sem...@li... >>> 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 >>> properties. >>> 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 >>> properties. >>> >>> 3. Demonstrating the utility of SMW to the site's founding >>> Bureaucrat, >>> 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 >>> >>> and >>> >>> php SMW_refreshData.php -v [-s xxxx] >>> >>> anyway. >>> >>> 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. >>> >>> Temlakos >>> >>> 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 >>>> >>>> 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. >>>> http://p.sf.net/sfu/bobj-july >>>> >>>> >>>> >>> ---------------------------------------------------------------------- >>> >>> >>>> -- >>>> >>>> _______________________________________________ >>>> Semediawiki-user mailing list >>>> Sem...@li... >>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >>>> >>>> >>>> >>> -------------------------------------------------------------- >>> ---------------- >>> 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 >>> Sem...@li... >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >>> >>> >>> >> >> > > > ------------------------------------------------------------------------------ > 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 > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > -- Philipp Zaltenbach Professional Services ontoprise GmbH - know how to use Know-how --- ontoprise presents the new SemanticMiner for SharePoint: http://www.ontoprise.de/en/home/news/news-en/cebit-2009-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:zal...@on..., 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 |