[04:07:45] Hi all. Does anybody have experience using the new RDFIO extension? It looks like it implements its own triple store + SPARQL interface. Does anybody know what happens if you are already using 4store or virtuoso? [04:13:27] I've got to go to a meeting in a sec, but I'll be back in an hour or so if anybody responds. [04:26:15] robsyme: I missed the question [06:25:36] For the log: RDFIO hijacks the SPARQL connection, so no easy solution: twitter.com/robsyme/status/324010683832348672 [14:46:59] Hi! Someone here for semantic Mediawiki support? [14:47:17] !ask [14:47:27] Oh well. [14:47:34] Great! [14:49:02] We have a embedded query construction [14:49:36] {{#ask: [[Kategorie:Termin]] | ?Termin=Datum | ?=Projekt | mainlabel=- | limit=3 }} [14:50:13] We want to sort by Attribute, not by Category. [14:50:39] Which attribute? [14:50:59] and the Attributes shold displayes as single per line. [14:51:10] Termin is the attribute [14:51:34] It is a Name of a catergory an da attribute [14:51:35] Alright - add "|sort=Termin" to the query. [14:53:04] Yes, this is correct, but we have more than on dates per category. [14:53:39] Oh, now I get it. [14:53:58] You might want to use #subobject or #set_internal to set the the dates, then. [14:54:29] In other words, each date is the property of some "object", not of the page itself. [14:56:31] Where I have to set #subobject? in the #ask ... [14:59:24] No, in each page. [14:59:40] How are you setting the properties? Through a template, or directly? [15:00:07] directly [15:00:27] Ah - that makes things a little trickier. :) [15:00:44] like this [[Termin::2009-10-20]] [15:00:54] Right. Given that, I don't know if it's worth it to make the change. [15:01:31] do you mean its too much afford? [15:01:50] I mean, it's a lot of work to change around all the pages, just to make that one query nicer. [15:02:15] we dont have many sites and cheep student workers :) [15:03:42] Alright. Well, you should replace calls like that with "{{#subobject:-|Termin=2009-10-20|Page={{PAGENAME}} }} 2009-10-20". [15:04:31] Actually, better yet, you should put all of that in a template, maybe called "Termin", so you can just call "{{Termin|2009-10-20}}". [15:07:21] OK, we try this and we come back and tell you the result. [15:07:28] thanks! [15:28:37] yaron, still here? [15:28:45] Hello! Yes. [15:30:05] We added lines like {{#subobject:-|Termin=2011-10-30|Page={{BVL}} }} 2011-10-30 and {{#subobject:-|Termin=2011-10-20|Page={{BVL}} }} 2011-10-20 [15:30:26] No, that won't work... [15:30:50] but we don't get results with {{#ask: [[Kategorie:Termin]] | ?Termin=Datum | ?=Projekt | sort=Termin | mainlabel=- | limit=20 }} [15:30:52] OK [15:31:16] You should create a page called "Template:Termin" containing the following text: {{#subobject:-|Termin={{{1}}}|Page={{PAGENAME}} }} {{{1}}} [15:31:34] Literally that text. [15:32:07] Then have calls in the main page like "{{Termin|2009-10-20}}". [15:35:47] Then, the query should look like "{{#ask: [[Termin::+]] | ?Termin=Datum | mainlabel=- | limit=3 }}". [15:46:25] It seems to work! [15:46:43] Cool. [15:48:28] Yes it works! Thanks! [15:50:44] Please give us your E-Mail Address, we send you an 3$ Amazon gift. [15:57:29] ipri: if I may offer a suggestion: visit http://workingwithmediawiki.com/ [16:07:42] Thanks a lot! [17:40:36] Time for the easiest question of the day [17:41:21] Where is the database configuration file stored? [17:45:27] gadams: "the" database? [17:45:53] do you mean MediaWiki's database? [17:46:12] AHHA! LocalSettings.php [17:47:15] ah, you're relatively new, I guess? [17:48:14] gadams: check out http://workingwithmediawiki.com/ [17:48:47] thanks Saruman [17:49:24] I'm suppose to update smw+ 1.16.4 to the latest version [17:50:51] argh! [17:51:07] you're in for a treat then [17:51:09] Yeah? [17:51:19] you'll be learning a LOT about mediawiki, semantic mediawiki etc [17:51:42] Lay it on me. Tell me the road that lays ahead of me. I know about 20-30 of the HALO extensions don't exist anymore. [17:52:12] because semafora-systems bought out some company that we're using their version of SMW for [17:52:38] http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_Plus [17:53:40] you can upgrade most of the parts of your setup, but you'll have to check if you're using something from the SMW+ offering that's unique to SMW+ [17:54:14] and then you'll have to decide: get the last release of SMW+ that's out there and stick with it, or migrate to SMW vanilla, losing SMW+ functionality [17:54:28] or at least that's my take [17:54:38] That's what I saw [17:54:47] I'm more just move to SMW and loose some of the functionality. [17:55:17] that'd be my advice [17:55:54] prolly need to upgrade MW to 1.20.4 vanilla [17:56:43] then SMW 1.8.0.4 with the store set to $smwgDefaultStore = 'SMWSQLStore2'; [17:57:02] (add Validator before enabling SMW1.8) [17:57:27] then the other extensions [17:57:40] then upgrade SMW to SLQstore 3 [17:57:56] then find all stuff that's now broken, and fix it or create workarounds [17:58:12] is there much content in the wiki? [17:58:17] many pages, many uploaded files? [17:59:22] gadams: you might consider an alternative route [17:59:46] export all pages from your wiki as XML, and import them in a freshly created and configured wiki [18:00:04] only there's no nice export of all files in a wiki [18:02:59] Yeah [18:03:03] there's abour 38k pages [18:03:40] but many files? [18:03:50] gotta find the ifles dir now [18:03:58] $IP/images [18:04:41] but easier is visiting Special:Statistics [18:04:42] 273 [18:05:08] mmh [18:05:19] still worth a try to go the XML route [18:06:00] if you import the File:* pages and cp -pR the files from $IP/images, and then php rebuildAll,php, then your files may be all there [18:06:12] hrm hrm... [18:06:33] on the other hand, you also want your user accounts... blergh... [18:06:55] well like I said, you're going to learn a lot [18:07:03] Should I look at writing custom sql migration script? [18:07:26] well, that's another tool you can consider using [18:07:39] let's start off by making a good backup of your current wiki [18:08:10] SQL database dump, XML dump, copy of LocalSettings.php... [18:08:50] It's getting migrated to a new server too [18:09:27] Hey now, here's a smaller site I could migrate. [18:09:57] 49 content pages, 500 pages, 256 uploads, 42 users [18:13:01] gadams: i'd consider restoring the backup as a second, independent wiki, and upgrade that one. [18:26:16] Yeah. [21:35:04] Has anyone here ever tried representing a "current" date? [21:36:02] For instance, I have a page that is like a person's resume. Their most recent job runs from July 2009 to present, because they still have that job. [21:36:55] I have tried setting the date with magic words for the current date, like this: {{CURRENTYEAR}}/{{CURRENTMONTH}}/{{CURRENTDAY2}} [21:37:41] If I did this it would show 2013/04/16 as the date. Which is great! [21:38:31] Problem is that tomorrow it will show the same date. It never updates again, so I guess the semantic representation of the value evaluates {{CURRENTYEAR}}/{{CURRENTMONTH}}/{{CURRENTDAY2}} ans stores the current value. [21:39:22] If I edit the page and save it, it updates to the current date. But I can't just edit and save all the pages every day. [21:40:07] Frank_____: you could always store the date instead as "2080/1/1" or something... it's a hack, but it'll work for querying purposes. [21:42:23] That's a possibility, yeah. The wiki might have future dates in it, but nothing anywhere near that far ahead. That may work. [21:42:48] Is my assumption about how properties are stored correct? [21:45:04] Yes. Although you can run the refreshData.php script to update such values. [21:48:26] Thank you Yaron, your help is always appreciated.