You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(2) |
Dec
(19) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(9) |
Feb
(9) |
Mar
(14) |
Apr
(23) |
May
(76) |
Jun
(20) |
Jul
(25) |
Aug
(22) |
Sep
(15) |
Oct
(24) |
Nov
(12) |
Dec
(15) |
2007 |
Jan
(2) |
Feb
(17) |
Mar
(32) |
Apr
(39) |
May
(38) |
Jun
(11) |
Jul
(19) |
Aug
(39) |
Sep
(33) |
Oct
(61) |
Nov
(67) |
Dec
(90) |
2008 |
Jan
(47) |
Feb
(67) |
Mar
(112) |
Apr
(39) |
May
(22) |
Jun
(107) |
Jul
(85) |
Aug
(103) |
Sep
(63) |
Oct
(58) |
Nov
(28) |
Dec
(15) |
2009 |
Jan
(103) |
Feb
(35) |
Mar
(66) |
Apr
(38) |
May
(26) |
Jun
(16) |
Jul
(128) |
Aug
(97) |
Sep
(39) |
Oct
(16) |
Nov
(33) |
Dec
(26) |
2010 |
Jan
(50) |
Feb
(73) |
Mar
(95) |
Apr
(28) |
May
(60) |
Jun
(76) |
Jul
(78) |
Aug
(54) |
Sep
(55) |
Oct
(25) |
Nov
(74) |
Dec
(36) |
2011 |
Jan
(25) |
Feb
(57) |
Mar
(109) |
Apr
(68) |
May
(51) |
Jun
(41) |
Jul
(47) |
Aug
(50) |
Sep
(50) |
Oct
(89) |
Nov
(85) |
Dec
(31) |
2012 |
Jan
(30) |
Feb
(42) |
Mar
(29) |
Apr
(27) |
May
(92) |
Jun
(57) |
Jul
(113) |
Aug
(33) |
Sep
(45) |
Oct
(100) |
Nov
(74) |
Dec
(45) |
2013 |
Jan
(24) |
Feb
(93) |
Mar
(65) |
Apr
(62) |
May
(100) |
Jun
(64) |
Jul
(25) |
Aug
(44) |
Sep
(24) |
Oct
(50) |
Nov
(173) |
Dec
(32) |
2014 |
Jan
(42) |
Feb
(13) |
Mar
(26) |
Apr
(3) |
May
(35) |
Jun
(16) |
Jul
(54) |
Aug
(23) |
Sep
(25) |
Oct
(35) |
Nov
(31) |
Dec
(7) |
2015 |
Jan
(11) |
Feb
(6) |
Mar
(28) |
Apr
(16) |
May
(10) |
Jun
(15) |
Jul
(20) |
Aug
(3) |
Sep
(8) |
Oct
(19) |
Nov
(17) |
Dec
(5) |
2016 |
Jan
(14) |
Feb
(4) |
Mar
|
Apr
(7) |
May
(3) |
Jun
(5) |
Jul
(5) |
Aug
(6) |
Sep
(9) |
Oct
(10) |
Nov
(3) |
Dec
(12) |
2017 |
Jan
(7) |
Feb
(3) |
Mar
(12) |
Apr
(2) |
May
(1) |
Jun
(8) |
Jul
(27) |
Aug
(19) |
Sep
(8) |
Oct
(2) |
Nov
(3) |
Dec
(3) |
2018 |
Jan
(5) |
Feb
(3) |
Mar
(1) |
Apr
(6) |
May
|
Jun
(3) |
Jul
(3) |
Aug
(2) |
Sep
(13) |
Oct
(13) |
Nov
|
Dec
|
2019 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(4) |
Oct
(11) |
Nov
(2) |
Dec
(3) |
2020 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(4) |
Oct
|
Nov
(2) |
Dec
(2) |
2021 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(1) |
2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(6) |
2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Sergey C. <sem...@an...> - 2007-11-07 19:12:06
|
> > Anyway, if you want to disable them, just set $smwgInlineErrors =3D false= ; > in > your LocalSettings (after including SMW). > OK, will do, this might be a good idea for production site. Although warnings are useful and maybe moving them to Factbox instead of completely disabling is better - I'd vote for this functionality along with configurable display of Factobox discussed before. Sergey On Nov 7, 2007 1:20 PM, Markus Kr=F6tzsch <ma...@ai...> wrote= : > The warnings are embedded in a way that allows clients without JavaScript > browsers to read them. This of course involves Google's crawlers. I also > wonder why the warnings are really a problem in Google, since they should > be > rare in general (their very purpose is to help people to spot errors > quickly > and fix them right away). If you write something erroneous into your wiki= , > there is always a chance of Google indexing it without you being able to > propagate the fix to Google's caches right after spotting it. > > Anyway, if you want to disable them, just set $smwgInlineErrors =3D false= ; > in > your LocalSettings (after including SMW). > > -- Markus > > On Mittwoch, 7. November 2007, Sergey Chernyshev wrote: > > Yes, it's possible to change a skin to output some description, but I > > really want it to output page's content, not some generic words > therefore > > it's not that easy to achieve in wiki. > > > > When I was talking about JS, I meant that page will contain empty span > tags > > like: > > > > <span id=3D"warning1"></span> > > > > and some JS code next to factbox will contain actual warnings so they > could > > be enabled/disabled with a button or with user preferences. It'll also > > allow showing warnings in factbox itself. > > > > Sergey > > > > On Nov 7, 2007 1:42 AM, S Page <in...@sk...> wrote: > > > Sergey Chernyshev wrote: > > > > It seems that inline warnings are being crawled and indexed by > Google > > > > which is quite bad. > > > > > > > > Here's home Google listing for one of my pages looks: > > > > > > > > *JavaScript: The Good Parts* - Technical Presentations > > > > <http://www.techpresentations.org/JavaScript:_The_Good_Part= s > > > > > > > > > > warning.pngSorry, URIs from the range > > > > > > > > "http://www.techpresentations.org{{#mediapath:*JavaScript*<http://w= ww.techpresentations.org%7B%7B#mediapath:*JavaScript*> > <http://www.t > > > >echpresentations.org%7B%7B#mediapath:*JavaScript*>*The Good > > > > Parts*.jpg}}" are not available in this place. *...* > > > > www.techpresentations.org/ > > > > <http://www.techpresentations.org/ > >*JavaScript*:_The_*Good*_*Parts* > > > > - 18k - > > > > > > > > > > > > I fixed the error and google is probably going to update it > eventualy, > > > > but still, it's not very good idea to have embedded HTML in there - > > > > maybe it's better to have them inserted using JS instead... it migh= t > > > > help with enabling/disabling it on per-user basis as well. > > > > > > You might be able to use the googleoff/on comment tags. You want to > > > turn off snippet and index, but you can probably just turn off > > > everything with > > > <!--googleoff: all--> > > > warning HTML stuff > > > <!--googleon: all --> > > > > > > Details at > > > < > > > > http://code.google.com/apis/searchappliance/documentation/46/admin_crawl/ > > >Preparing.html#pagepart > > > > > > This definitely works for the Google Search Appliance, but I can't > find > > > conclusive evidence whether Google's own Web crawler respects these > tags. > > > > > > Google tries to be smart about what to display in snippets, I'm not > sure > > > what heuristics work these days to discourage it. Try looking at > > > Google's cached version of your page for clues. With JavaScript > > > enabled, the SMW warnings are surrounded by <span style=3D"display: > > > none">, but the Google crawler sees the page with the warning in a > > > regular <div>. > > > > > > < > > > > http://googlewebmastercentral.blogspot.com/2007/09/improve-snippets-with- > > >meta-description.html > > > > > > suggests you can control the snippet using a > > > <META NAME=3D"Description" CONTENT =3D "blah blah" /> tag, you might= be > > > able to change your skin to output something here. > > > > > > You can turn off the snippet altogether with > > > <META NAME=3D"GOOGLEBOT" CONTENT=3D"NOSNIPPET"> , > > > see < > http://www.google.com/support/webmasters/bin/answer.py?answer=3D35304> > > > > > > -- > > > =3DS Page > > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a > browser. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > _______________________________________________ > > > Semediawiki-devel mailing list > > > Sem...@li... > > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > -- > Markus Kr=F6tzsch > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... www http://korrekt.org > --=20 Sergey Chernyshev http://www.sergeychernyshev.com/ |
From: Markus <ma...@ai...> - 2007-11-07 18:44:05
|
Yes, this appears to be a bug. For a quick workaround, consider using the=20 formats "list", "ul" or "ol", all of which also support the=20 template-parameter for formatting (and this one certainly works with SMW1.0= ).=20 Note that with list, you can also choose the separator between items=20 (parameter sep), so as to simulate "template" quite well. Markus On Mittwoch, 7. November 2007, cnit wrote: > Hi! > After adding additional priviledges to database (CREATE TEMPORARILY > TABLES and DROP), my upgrade seems to work. I wonder, whether these > additional priviledges are mentioned in INSTALL file, because older > SMW's were happy with just ALTER. > > But there's some disappointment, my query templates don't work > anymore. I've used to display custom HTML layout with such query: > > <div class=3D"tbl-yarsu"> > <!-- {{newshead}} --> > <ask sort=3D"Date" order=3D"descending" limit=3D"20" format=3D"template" > template=3D"newsrow" default=3D"There is no news" searchlabel=3D"Browse a= ll news > ..."> [[Date:=3D*]] > [[Category:News]] > </ask></div> > > and a such simple Template:newsrow > > <div class=3D"tr-yarsu"> > <div class=3D"td-yarsu yarsu-date">{{{2}}}</div> > <div class=3D"td-yarsu yarsu-article">{{{1}}}</div> > <div class=3D"space-line-yarsu"></div> > </div> > > > The query works, yet the value of {{{2}}} is omitted. it's empty, > none.. :-( > > {{{1}}} expands just fine.. > > Dmitriy > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: Markus <ma...@ai...> - 2007-11-07 18:20:55
|
The warnings are embedded in a way that allows clients without JavaScript=20 browsers to read them. This of course involves Google's crawlers. I also=20 wonder why the warnings are really a problem in Google, since they should b= e=20 rare in general (their very purpose is to help people to spot errors quickl= y=20 and fix them right away). If you write something erroneous into your wiki,= =20 there is always a chance of Google indexing it without you being able to=20 propagate the fix to Google's caches right after spotting it. Anyway, if you want to disable them, just set $smwgInlineErrors =3D false; = in=20 your LocalSettings (after including SMW). =2D- Markus On Mittwoch, 7. November 2007, Sergey Chernyshev wrote: > Yes, it's possible to change a skin to output some description, but I > really want it to output page's content, not some generic words therefore > it's not that easy to achieve in wiki. > > When I was talking about JS, I meant that page will contain empty span ta= gs > like: > > <span id=3D"warning1"></span> > > and some JS code next to factbox will contain actual warnings so they cou= ld > be enabled/disabled with a button or with user preferences. It'll also > allow showing warnings in factbox itself. > > Sergey > > On Nov 7, 2007 1:42 AM, S Page <in...@sk...> wrote: > > Sergey Chernyshev wrote: > > > It seems that inline warnings are being crawled and indexed by Google > > > which is quite bad. > > > > > > Here's home Google listing for one of my pages looks: > > > > > > *JavaScript: The Good Parts* - Technical Presentations > > > <http://www.techpresentations.org/JavaScript:_The_Good_Parts> > > > > > > warning.pngSorry, URIs from the range > > > =20 > > > "http://www.techpresentations.org{{#mediapath:*JavaScript*<http://www= =2Et > > >echpresentations.org%7B%7B#mediapath:*JavaScript*>*The Good > > > Parts*.jpg}}" are not available in this place. *...* > > > www.techpresentations.org/ > > > <http://www.techpresentations.org/>*JavaScript*:_The_*Good*_*Part= s* > > > - 18k - > > > > > > > > > I fixed the error and google is probably going to update it eventualy, > > > but still, it's not very good idea to have embedded HTML in there - > > > maybe it's better to have them inserted using JS instead... it might > > > help with enabling/disabling it on per-user basis as well. > > > > You might be able to use the googleoff/on comment tags. You want to > > turn off snippet and index, but you can probably just turn off > > everything with > > <!--googleoff: all--> > > warning HTML stuff > > <!--googleon: all --> > > > > Details at > > < > > http://code.google.com/apis/searchappliance/documentation/46/admin_craw= l/ > >Preparing.html#pagepart > > > > This definitely works for the Google Search Appliance, but I can't find > > conclusive evidence whether Google's own Web crawler respects these tag= s. > > > > Google tries to be smart about what to display in snippets, I'm not sure > > what heuristics work these days to discourage it. Try looking at > > Google's cached version of your page for clues. With JavaScript > > enabled, the SMW warnings are surrounded by <span style=3D"display: > > none">, but the Google crawler sees the page with the warning in a > > regular <div>. > > > > < > > http://googlewebmastercentral.blogspot.com/2007/09/improve-snippets-wit= h- > >meta-description.html > > > > suggests you can control the snippet using a > > <META NAME=3D"Description" CONTENT =3D "blah blah" /> tag, you might be > > able to change your skin to output something here. > > > > You can turn off the snippet altogether with > > <META NAME=3D"GOOGLEBOT" CONTENT=3D"NOSNIPPET"> , > > see <http://www.google.com/support/webmasters/bin/answer.py?answer=3D35= 304> > > > > -- > > =3DS Page > > > > -----------------------------------------------------------------------= =2D- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: Sergey C. <sem...@an...> - 2007-11-07 14:44:19
|
Yes, it's possible to change a skin to output some description, but I really want it to output page's content, not some generic words therefore it's not that easy to achieve in wiki. When I was talking about JS, I meant that page will contain empty span tags like: <span id="warning1"></span> and some JS code next to factbox will contain actual warnings so they could be enabled/disabled with a button or with user preferences. It'll also allow showing warnings in factbox itself. Sergey On Nov 7, 2007 1:42 AM, S Page <in...@sk...> wrote: > Sergey Chernyshev wrote: > > > It seems that inline warnings are being crawled and indexed by Google > > which is quite bad. > > > > Here's home Google listing for one of my pages looks: > > > > *JavaScript: The Good Parts* - Technical Presentations > > <http://www.techpresentations.org/JavaScript:_The_Good_Parts> > > > > warning.pngSorry, URIs from the range > > "http://www.techpresentations.org{{#mediapath:*JavaScript*<http://www.techpresentations.org%7B%7B#mediapath:*JavaScript*>*The Good > > Parts*.jpg}}" are not available in this place. *...* > > www.techpresentations.org/ > > <http://www.techpresentations.org/>*JavaScript*:_The_*Good*_*Parts* > > - 18k - > > > > > > I fixed the error and google is probably going to update it eventualy, > > but still, it's not very good idea to have embedded HTML in there - > > maybe it's better to have them inserted using JS instead... it might > > help with enabling/disabling it on per-user basis as well. > > You might be able to use the googleoff/on comment tags. You want to > turn off snippet and index, but you can probably just turn off > everything with > <!--googleoff: all--> > warning HTML stuff > <!--googleon: all --> > > Details at > < > http://code.google.com/apis/searchappliance/documentation/46/admin_crawl/Preparing.html#pagepart > > > This definitely works for the Google Search Appliance, but I can't find > conclusive evidence whether Google's own Web crawler respects these tags. > > Google tries to be smart about what to display in snippets, I'm not sure > what heuristics work these days to discourage it. Try looking at > Google's cached version of your page for clues. With JavaScript > enabled, the SMW warnings are surrounded by <span style="display: > none">, but the Google crawler sees the page with the warning in a > regular <div>. > > < > http://googlewebmastercentral.blogspot.com/2007/09/improve-snippets-with-meta-description.html > > > suggests you can control the snippet using a > <META NAME="Description" CONTENT = "blah blah" /> tag, you might be > able to change your skin to output something here. > > You can turn off the snippet altogether with > <META NAME="GOOGLEBOT" CONTENT="NOSNIPPET"> , > see <http://www.google.com/support/webmasters/bin/answer.py?answer=35304> > > -- > =S Page > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > -- Sergey Chernyshev http://www.sergeychernyshev.com/ |
From: cnit <cn...@un...> - 2007-11-07 14:24:26
|
Hi! After adding additional priviledges to database (CREATE TEMPORARILY TABLES and DROP), my upgrade seems to work. I wonder, whether these additional priviledges are mentioned in INSTALL file, because older SMW's were happy with just ALTER. But there's some disappointment, my query templates don't work anymore. I've used to display custom HTML layout with such query: <div class="tbl-yarsu"> <!-- {{newshead}} --> <ask sort="Date" order="descending" limit="20" format="template" template="newsrow" default="There is no news" searchlabel="Browse all news ..."> [[Date:=*]] [[Category:News]] </ask></div> and a such simple Template:newsrow <div class="tr-yarsu"> <div class="td-yarsu yarsu-date">{{{2}}}</div> <div class="td-yarsu yarsu-article">{{{1}}}</div> <div class="space-line-yarsu"></div> </div> The query works, yet the value of {{{2}}} is omitted. it's empty, none.. :-( {{{1}}} expands just fine.. Dmitriy |
From: S P. <in...@sk...> - 2007-11-07 06:46:12
|
Sergey Chernyshev wrote: > It seems that inline warnings are being crawled and indexed by Google > which is quite bad. > > Here's home Google listing for one of my pages looks: > > *JavaScript: The Good Parts* - Technical Presentations > <http://www.techpresentations.org/JavaScript:_The_Good_Parts> > > warning.pngSorry, URIs from the range > "http://www.techpresentations.org{{#mediapath:*JavaScript* *The Good > Parts*.jpg}}" are not available in this place. *...* > www.techpresentations.org/ > <http://www.techpresentations.org/>*JavaScript*:_The_*Good*_*Parts* > - 18k - > > > I fixed the error and google is probably going to update it eventualy, > but still, it's not very good idea to have embedded HTML in there - > maybe it's better to have them inserted using JS instead... it might > help with enabling/disabling it on per-user basis as well. You might be able to use the googleoff/on comment tags. You want to turn off snippet and index, but you can probably just turn off everything with <!--googleoff: all--> warning HTML stuff <!--googleon: all --> Details at <http://code.google.com/apis/searchappliance/documentation/46/admin_crawl/Preparing.html#pagepart> This definitely works for the Google Search Appliance, but I can't find conclusive evidence whether Google's own Web crawler respects these tags. Google tries to be smart about what to display in snippets, I'm not sure what heuristics work these days to discourage it. Try looking at Google's cached version of your page for clues. With JavaScript enabled, the SMW warnings are surrounded by <span style="display: none">, but the Google crawler sees the page with the warning in a regular <div>. <http://googlewebmastercentral.blogspot.com/2007/09/improve-snippets-with-meta-description.html> suggests you can control the snippet using a <META NAME="Description" CONTENT = "blah blah" /> tag, you might be able to change your skin to output something here. You can turn off the snippet altogether with <META NAME="GOOGLEBOT" CONTENT="NOSNIPPET"> , see <http://www.google.com/support/webmasters/bin/answer.py?answer=35304> -- =S Page |
From: Sergey C. <sem...@an...> - 2007-11-07 03:06:06
|
It seems that inline warnings are being crawled and indexed by Google which is quite bad. Here's home Google listing for one of my pages looks: > *JavaScript: The Good Parts* - Technical Presentations<http://www.techpresentations.org/JavaScript:_The_Good_Parts> > warning.pngSorry, URIs from the range > "http://www.techpresentations.org{{#mediapath:*JavaScript* *The Good Parts > *.jpg}}" are not available in this place. *...* > www.techpresentations.org/*JavaScript*:_The_*Good*_*Parts* - 18k - > I fixed the error and google is probably going to update it eventualy, but still, it's not very good idea to have embedded HTML in there - maybe it's better to have them inserted using JS instead... it might help with enabling/disabling it on per-user basis as well. Sergey |
From: Sergey C. <sem...@an...> - 2007-11-06 18:28:12
|
It seems that SMW_refreshData gets slower with growing size of the dataset. I didn't do much of troubleshooting of the issue, but first 50000 pages from my dataset were processed faster then second 50000 pages. I'm going to start upgrade over for RC2 and will try to look at it in terms of speed of the process, but I think there might be a reason for it in some indexes getting bigger with more data (which can be avoided by dropping indexes prior to refresh and rebuilding them right after) or MySQL not liking that many temporary tables created so rapidly. Also, I'm wondering if parts of the dataset can be processed in parallel? it seems that single run of the script doesn't load CPU that much and alternates between PHP and MySQL processes which is not optimal for multi-processor boxes where these loads can be spread across all the CPUs. Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ |
From: Sergey C. <sem...@an...> - 2007-11-06 18:11:52
|
Markus, thank you for the follow-up! It's great to know that {{#ask}} is scheduled for 1.0 release! I'm happy to participate in architectural discussion. Here're some thoughts on the subject: 1. it seems to be to restricting on query language to remove pipes and equal signs from it - who knows, maybe you'll want to have '|' character= s in OR-like statements or '=3D' in filtering statements. 2. I'm not sure if it makes a lot of sense to change the format of query language from old version to new one I can propose, if not very elegant, but a solution - make a query to be a last parameter and let's have a name for it, e.g. 'query' - all parameters after the one that start with ~/^query\s+=3D/ will get joined to it using a pipe. In your example: <ask format=3D"table" limit=3D"12"> [[Category:Person]] [[lives in::Europe]] [[lives in::*]] [[birthday::*|day of birth]] [[height::*m=B2|size]] </ask> will get converted to: {{#ask:format=3Dtable|limit=3D12|query=3D [[Category:Person]] [[lives in::Europe]] [[lives in::*]] [[birthday::*|day of birth]] [[height::*m=B2|size]] }} Here's the pseudo-code for this: function askParserFunc (&$parser) { $params =3D func_get_args(); array_shift($params); # first one is parser - we don't need it $query =3D ''; $queryfound =3D false; foreach ($params as $param) { if (!$queryfound) { if (preg_match('/^query\s+=3D/', $param)) { $query =3D preg_replace('/^query\s+=3D/', '', $param); // all params after this one will get appended to $query $queryfound =3D true; continue; } ... process all the rest of params ... } else { $query.=3D'|'.$param; } } ... do actual inline query work ... } I didn't test the code, but I used func_get_args approach and it worked for me. This can be used if you keep current syntax or introduce new one. What do you think of this approach. Sergey On Nov 6, 2007 11:20 AM, Markus Kr=F6tzsch <ma...@ai...> wrot= e: > On Dienstag, 6. November 2007, cnit wrote: > > > The other issue that I'm having is {{#ask}} parser function - not > > > having it stops almost all of my development. It's probably the most > > > anticipated feature right now. Do you have any timeline or at least > > > defined approach to it? > > > > I guess that "RC" thing means - "The development of major features is > > temporarily frozen. Only small bugfixes are accepted". That approach > > is used to make the code more stable. > > No, not quite. Two more features are scheduled for SMW1.0 final: one (as > you > know) is {{#ask}}, and the other is the listing of subproperties on > property > pages. We know that traditionally one would do RCs together with a featur= e > freeze, but in a wiki one can certainly have optional features released > also > if they are less well-tested. > > The reasons why we have started releasing RCs are: > > * Some people started asking us whether the project was still alive ;-) > * The developers of the Halo extension asked for an early release, so tha= t > they could release some code compatible with a fixed version of SMW. > * More testing cannot hurt. > > The RC-process does not slow down our work on the aforementioned features > -- > it would have been slow anyway. > > > > > I am myself missing parser function badly, but I guess that > > complaining too often won't speed up the development, rather bore the > > developers.. > > Well, you can always add some further pressure, but our development > activity > still is subject to various constraints that are outside our control > (jobs, > lives, ...) ;-) > > But maybe, since we are over it, we can start some design discussions > about > {{#ask...}}. In particular, parser functions have a slightly different > style > of parameters than parser hooks (<ask>). Our current <ask> has three > parts: > > (1) the query conditions, > (2) multiple print statements, > (3) a variable set of parameters. > > Currently (1) and (2) can be mixed, although the position of print > statements > relative to the query conditions has no effect. Moving to a parser > function > seems to be a good opportunity to revise some of this design, e.g. by > simply > making the print statements a separate parameter. In {{#ask..}}, > everything > must be passed as a parameter anyway, so separating (1) and (2) is no > complication. How should an example query look like? Her is a suggested > example transformation: > > <ask format=3D"table" limit=3D"12"> > [[Category:Person]] [[lives in::Europe]] > [[lives in::*]] > [[birthday::*|day of birth]] > [[height::*m=B2|size]] > </ask> > > becomes > > {{#ask| > format=3Dtable| > limit =3D 12| > ?lives in| > ?birthday =3D day of birth| > ?height#m=B2 =3D size| > [[Category:Person]] [[lives in::Europe]] > }} > > Basic points: > * The query is always the last parameter. > * No | appear unless they are used as separators between parameters. > * Printouts start with "?" > * All the known printout modifications somehow work, but in different > syntax. > * We implicitly block "=3D" in property names (should we care?) > > Some of this syntax is not essential, but one must be careful not to > collide > with MediaWiki syntax. <ask> would of course continue to work in any case= , > but {{#ask}} would become the suggested method in the future. > > I guess the main point of discussion would be the printout-parameters. > Many > variations are possible, and comments are welcome. > > > > > I am investigating my own upgrade, too. My temporarily solution for > > dynanical queries will be small patch I plan to make unpublished - > > just simply %FUNCTION_NAME% inside query param will be replaced > > with result of the call to according PHP function, instead of template. > > Should be easy to implement (with some security restrictions, of course > > - though my wiki is not public). > > > > When the function will be available, I'll switch to these. > > Yes, that would be a very versatile mechanism indeed. > > Cheers, > > Markus > > > Dmitriy > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > -- > Markus Kr=F6tzsch > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... www http://korrekt.org > |
From: Yaron K. <ya...@gm...> - 2007-11-06 18:05:58
|
I think that's a great format for the {{ask}} parser function - it nicely separates data from presentation; which are somewhat mixed together in current inline queries. Also, this is unrelated, but I discovered yesterday that inline queries in SMW 1.0 can handle redirected pages (pages for which a property links to a page that redirects to them now show up in query results), which is a great feature. Thanks! -Yaron On Nov 6, 2007 11:20 AM, Markus Kr=F6tzsch <ma...@ai...> wrot= e: > On Dienstag, 6. November 2007, cnit wrote: > > > The other issue that I'm having is {{#ask}} parser function - not > > > having it stops almost all of my development. It's probably the most > > > anticipated feature right now. Do you have any timeline or at least > > > defined approach to it? > > > > I guess that "RC" thing means - "The development of major features is > > temporarily frozen. Only small bugfixes are accepted". That approach > > is used to make the code more stable. > > No, not quite. Two more features are scheduled for SMW1.0 final: one (as > you > know) is {{#ask}}, and the other is the listing of subproperties on > property > pages. We know that traditionally one would do RCs together with a featur= e > freeze, but in a wiki one can certainly have optional features released > also > if they are less well-tested. > > The reasons why we have started releasing RCs are: > > * Some people started asking us whether the project was still alive ;-) > * The developers of the Halo extension asked for an early release, so tha= t > they could release some code compatible with a fixed version of SMW. > * More testing cannot hurt. > > The RC-process does not slow down our work on the aforementioned features > -- > it would have been slow anyway. > > > > > I am myself missing parser function badly, but I guess that > > complaining too often won't speed up the development, rather bore the > > developers.. > > Well, you can always add some further pressure, but our development > activity > still is subject to various constraints that are outside our control > (jobs, > lives, ...) ;-) > > But maybe, since we are over it, we can start some design discussions > about > {{#ask...}}. In particular, parser functions have a slightly different > style > of parameters than parser hooks (<ask>). Our current <ask> has three > parts: > > (1) the query conditions, > (2) multiple print statements, > (3) a variable set of parameters. > > Currently (1) and (2) can be mixed, although the position of print > statements > relative to the query conditions has no effect. Moving to a parser > function > seems to be a good opportunity to revise some of this design, e.g. by > simply > making the print statements a separate parameter. In {{#ask..}}, > everything > must be passed as a parameter anyway, so separating (1) and (2) is no > complication. How should an example query look like? Her is a suggested > example transformation: > > <ask format=3D"table" limit=3D"12"> > [[Category:Person]] [[lives in::Europe]] > [[lives in::*]] > [[birthday::*|day of birth]] > [[height::*m=B2|size]] > </ask> > > becomes > > {{#ask| > format=3Dtable| > limit =3D 12| > ?lives in| > ?birthday =3D day of birth| > ?height#m=B2 =3D size| > [[Category:Person]] [[lives in::Europe]] > }} > > Basic points: > * The query is always the last parameter. > * No | appear unless they are used as separators between parameters. > * Printouts start with "?" > * All the known printout modifications somehow work, but in different > syntax. > * We implicitly block "=3D" in property names (should we care?) > > Some of this syntax is not essential, but one must be careful not to > collide > with MediaWiki syntax. <ask> would of course continue to work in any case= , > but {{#ask}} would become the suggested method in the future. > > I guess the main point of discussion would be the printout-parameters. > Many > variations are possible, and comments are welcome. > > > > > I am investigating my own upgrade, too. My temporarily solution for > > dynanical queries will be small patch I plan to make unpublished - > > just simply %FUNCTION_NAME% inside query param will be replaced > > with result of the call to according PHP function, instead of template. > > Should be easy to implement (with some security restrictions, of course > > - though my wiki is not public). > > > > When the function will be available, I'll switch to these. > > Yes, that would be a very versatile mechanism indeed. > > Cheers, > > Markus > > > Dmitriy > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Semediawiki-devel mailing list > > Sem...@li... > > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > > > -- > Markus Kr=F6tzsch > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... www http://korrekt.org > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > |
From: Sergey C. <sem...@an...> - 2007-11-06 17:35:43
|
My "complaint" was not about the availability of the feature itself, but about not knowing if I should expect it in SMW 1.0 release or not - your email is first message about any timeline that is available to me. And it seems that the answer is 'no'. I'm not sure if having hardcoded workarounds works for me because I'm planning to have quite a few parser functions within templates and adding custom PHP functions for all of the cases is just impossible. It'll be greate if there was some place on ontoworld.org that described plans and timelines - this page: http://ontoworld.org/wiki/Semantic_MediaWiki_development_activities is not updated to often, unfortunately. Sergey On Nov 6, 2007 10:01 AM, cnit <cn...@un...> wrote: > > The other issue that I'm having is {{#ask}} parser function - not > > having it stops almost all of my development. It's probably the most > > anticipated feature right now. Do you have any timeline or at least > > defined approach to it? > I guess that "RC" thing means - "The development of major features is > temporarily frozen. Only small bugfixes are accepted". That approach > is used to make the code more stable. > > I am myself missing parser function badly, but I guess that > complaining too often won't speed up the development, rather bore the > developers.. > > I am investigating my own upgrade, too. My temporarily solution for > dynanical queries will be small patch I plan to make unpublished - > just simply %FUNCTION_NAME% inside query param will be replaced > with result of the call to according PHP function, instead of template. > Should be easy to implement (with some security restrictions, of course > - though my wiki is not public). > > When the function will be available, I'll switch to these. > Dmitriy > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > |
From: Markus <ma...@ai...> - 2007-11-06 17:21:13
|
On Montag, 5. November 2007, Dan Bolser wrote: > Hi, I recently installed Semantic MediaWiki (version 1.0-RC1) from > tar. Hopefully I didn't make a mistake during install, because I have > been having difficulty getting some of the documented features working > correctly. > > I was following the instructions given on this manual page; > > http://ontoworld.org/wiki/Help:Service_links To make long things short: service links are currently disabled in SMW1.0RC= 1=20 and RC2. They will reappear for the final release, but right now just do no= t=20 work since I did not reimplement them yet. Specifying them already does not= =20 hurt either, but has no effect for display. Cheers, Markus > > > (Sorry for the ugly banner at the top of that page, I created that to > try and keep track of pages that look like they need to be updated or > split in the light of SMW-1.0 syntax wrt. SMW-0.7 syntax). > > The upshot is that I can't get 'service links' to work on my install. > I created a page called [[Urease]] with the following properties, > > [[Is a::protein]] > [[Has pdb entry::1ura]] > > > Then on the page [[Property:Has pdb entry]] I added the following > assertions; > > [[has type::string]] > [[provides service::rscb entry]] > > > Both of those properties show up as 'special property in this wiki' in > the fact box, however, the text 'rscb_entry' in the fact box is not > clickable. I edited the page [[MediaWiki:Smw_service_rscb_entry]] to > add the following; > > rscb|http://www.rcsb.org/pdb/explore/explore.do?structureId=3D$1 > > > But no joy. FYI, the following is the link that I want to get > (somewhere) on the wiki; > > http://www.rcsb.org/pdb/explore/explore.do?structureId=3D1ura > > > Has this feature been dropped in 1.0? Is there a replacement? > > Thanks for any information, > > Dan. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: Markus <ma...@ai...> - 2007-11-06 16:23:54
|
On Dienstag, 6. November 2007, cnit wrote: > > The other issue that I'm having is {{#ask}} parser function - not > > having it stops almost all of my development. It's probably the most > > anticipated feature right now. Do you have any timeline or at least > > defined approach to it? > > I guess that "RC" thing means - "The development of major features is > temporarily frozen. Only small bugfixes are accepted". That approach > is used to make the code more stable. No, not quite. Two more features are scheduled for SMW1.0 final: one (as yo= u=20 know) is {{#ask}}, and the other is the listing of subproperties on propert= y=20 pages. We know that traditionally one would do RCs together with a feature= =20 freeze, but in a wiki one can certainly have optional features released als= o=20 if they are less well-tested. The reasons why we have started releasing RCs are: * Some people started asking us whether the project was still alive ;-) * The developers of the Halo extension asked for an early release, so that= =20 they could release some code compatible with a fixed version of SMW. * More testing cannot hurt. The RC-process does not slow down our work on the aforementioned features -= =2D=20 it would have been slow anyway. > > I am myself missing parser function badly, but I guess that > complaining too often won't speed up the development, rather bore the > developers.. Well, you can always add some further pressure, but our development activit= y=20 still is subject to various constraints that are outside our control (jobs,= =20 lives, ...) ;-) But maybe, since we are over it, we can start some design discussions about= =20 {{#ask...}}. In particular, parser functions have a slightly different styl= e=20 of parameters than parser hooks (<ask>). Our current <ask> has three parts: (1) the query conditions, (2) multiple print statements, (3) a variable set of parameters. Currently (1) and (2) can be mixed, although the position of print statemen= ts=20 relative to the query conditions has no effect. Moving to a parser function= =20 seems to be a good opportunity to revise some of this design, e.g. by simpl= y=20 making the print statements a separate parameter. In {{#ask..}}, everything= =20 must be passed as a parameter anyway, so separating (1) and (2) is no=20 complication. How should an example query look like? Her is a suggested=20 example transformation: <ask format=3D"table" limit=3D"12"> [[Category:Person]] [[lives in::Europe]]=20 [[lives in::*]] [[birthday::*|day of birth]]=20 [[height::*m=B2|size]] </ask> becomes {{#ask| format=3Dtable| limit =3D 12| ?lives in| ?birthday =3D day of birth| ?height#m=B2 =3D size| [[Category:Person]] [[lives in::Europe]] }} Basic points: * The query is always the last parameter. * No | appear unless they are used as separators between parameters. * Printouts start with "?" * All the known printout modifications somehow work, but in different synta= x. * We implicitly block "=3D" in property names (should we care?) Some of this syntax is not essential, but one must be careful not to collid= e=20 with MediaWiki syntax. <ask> would of course continue to work in any case,= =20 but {{#ask}} would become the suggested method in the future. I guess the main point of discussion would be the printout-parameters. Many= =20 variations are possible, and comments are welcome. > > I am investigating my own upgrade, too. My temporarily solution for > dynanical queries will be small patch I plan to make unpublished - > just simply %FUNCTION_NAME% inside query param will be replaced > with result of the call to according PHP function, instead of template. > Should be easy to implement (with some security restrictions, of course > - though my wiki is not public). > > When the function will be available, I'll switch to these. Yes, that would be a very versatile mechanism indeed. Cheers, Markus > Dmitriy > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: cnit <cn...@un...> - 2007-11-06 16:18:11
|
> Whoa, slow down. Does your new installation work? When you follow the > exact instructions in the INSTALL file under "Testing your > Installation", do you get the expected results? Actually I am not so fast, as you see.. All the steps mentioned above are passed successfully. No wonder, because I've used to install SMW0.6 and SMW0.7 previousely, and the later one runs fine on my site. > Since you're having problems with categories (see later), try making a > few nested subcategories and doing queries on them. > I don't know if the old backups are compatible. With each SMW and > MediaWiki update I made a backup but I made the upgrade in-place and ran > the updates scripts and SMWAdmin with no incident, so I never had to try > the backups. Yes, I've executed SMWAdmin before the XML restore. It worked fine. I do not trust upgrade scripts, I feel they are more vulnerable to bugs comparing to XML backups. > Error in fetchObject(): Table 'yarsu.cats4' doesn't exist (127.0.0.1) > I think "catNNN" are temporary tables that SMW creates in > getCategoryTable() when it makes "a (temporary) table that contains the > lower closure of the given category wrt. the category table." I'm not > sure why it's failing. It could be a database-level problem, such as a > permissions issue. Database permissions are SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, LOCK TABLES These were enough for SMW 0.7. And yes, I've restored the XML backups with older versions. Though, I realize that the difference between 0.7 and 1.0 is much wider. > What PHP and MySQL versions are you running? PHP 5.2.4 and MySQL 5.0.45, accordingly. Works with MW 1.10/SMW 0.7 just fine. When I've used to install 1.93/SMW 0.6 some time ago, I've had a major screwup with mysql RPM, which installed by default with charset settings ISOsomething instead of unicode. Since then, I implicitely specify UTF8 as default charset. > In the failures you attached, the MediaWiki import script is parsing the > XML of a page that apparently has an <ask> inline query in it, so it's > calling smwfProcessInlineQuery() > Can you try making a simple query for a category from Special:Ask? E.g. > [[Help:+]] Can't right now, see below the explanation why.. > I guess you could try removing the inline query (search for ask) from > the XML file and try reimporting. > It's the inline queries for category that seem to be causing grief, so I > think you should focus on removing those first. Yes, I've removed all the ask queries and it imported just fine. > I think you can and should run the SMW_unifyProperties.php maintenance > script after import. I've changed the namespace names to <page>Property:Propertyname</page> manually inside the dump... Another advantage of using the dump :-) > I think that must be a table produced by something. SMW doesn't use > class="tbl...". So maybe you have some other extension or template > that's generating tables. I've not realized that tags were quoted so <div was encoded as <div. So it was my div, but I was unable to find it :-) It was used inside the template, used by <ask format="template" ...> > I hope these guesses help. > -- Thanks for the help. I guess there are more permissions needed by SMW 1.0RC2 comparing to SMW 0.7. I've added CREATE TEMPORARY TABLES to mysql priviledges and now it imported the rest of the dump just fine, too. But, I wasn't happy for a long time. An attemnt of executing Special:Ask page results with httpd consuming 99% of CPU infinitely, until I shutdown it and restart :-( Will investigate further tomorrow... Dmitriy |
From: cnit <cn...@un...> - 2007-11-06 15:06:23
|
> The other issue that I'm having is {{#ask}} parser function - not > having it stops almost all of my development. It's probably the most > anticipated feature right now. Do you have any timeline or at least > defined approach to it? I guess that "RC" thing means - "The development of major features is temporarily frozen. Only small bugfixes are accepted". That approach is used to make the code more stable. I am myself missing parser function badly, but I guess that complaining too often won't speed up the development, rather bore the developers.. I am investigating my own upgrade, too. My temporarily solution for dynanical queries will be small patch I plan to make unpublished - just simply %FUNCTION_NAME% inside query param will be replaced with result of the call to according PHP function, instead of template. Should be easy to implement (with some security restrictions, of course - though my wiki is not public). When the function will be available, I'll switch to these. Dmitriy |
From: Sergey C. <sem...@an...> - 2007-11-06 14:52:00
|
Markus, First of all, great job! I can't wait to have less bugs and going to upgrad= e right away! The other issue that I'm having is {{#ask}} parser function - not having it stops almost all of my development. It's probably the most anticipated feature right now. Do you have any timeline or at least defined approach to it? Thank you, Sergey On Nov 6, 2007 5:47 AM, Markus Kr=F6tzsch <ma...@ai...> wrote= : > Hi all, > > the next release candidate for SMW1.0 is now available for download. It > brings > mostly bugfixes to problems encountered with RC1, but also has some new > features. The major changes are: > > * More liberal parsing for geographic coordinates, most user inputs > accepted > now. > * Improved URL datatype: better linking behaviour, tolerant towards > Unicode-URLs. > * Significantly improved performance for RDF export. > * Complete translations for Fr, Zh-tw, and Zh-ch added (thanks to > Pierre Matringe and Roc Michael). > > Cheers, > > Markus > > -- > Markus Kr=F6tzsch > Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe > phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 > ma...@ai... www http://korrekt.org > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Semediawiki-user mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-user > |
From: Markus <ma...@ai...> - 2007-11-06 10:47:38
|
Hi all, the next release candidate for SMW1.0 is now available for download. It bri= ngs=20 mostly bugfixes to problems encountered with RC1, but also has some new=20 features. The major changes are: * More liberal parsing for geographic coordinates, most user inputs accepte= d=20 now. * Improved URL datatype: better linking behaviour, tolerant towards=20 Unicode-URLs. * Significantly improved performance for RDF export. * Complete translations for Fr, Zh-tw, and Zh-ch added (thanks to =20 Pierre Matringe and Roc Michael). Cheers, Markus =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: Markus <ma...@ai...> - 2007-11-05 17:18:49
|
On Freitag, 2. November 2007, Asheesh Laroia wrote: > On a wiki I maintain, I find that people enter "spam hardened" > (supposedly) email addresses, like asheesh AT creativecommons DOT org. I > figured it would be nice to show those, even if they're not really email > addresses. > > It was easy to comment out the validator, but that's not what this email > is about: I propose (with a patch, attached) that SMW always urlencode() > email addresses when generating their URIs and URLs. > > This is always a safe thing to do, and it may in some cases (as for me) be > a crucial correctness issue. Hopefully you'll apply this. Good point. I did this now in SVN (and RC2 might come out tomorrow). In fac= t,=20 I also did something similar to all URLs/URIs. Now we do no longer check fo= r=20 problematic characters in URLs but just encode them. On the other side, the= =20 protocol part is now extracted and checked, and only allowed protocols will= =20 get linked in the wiki (e.g. "file://" will normally not get linked). Should we also simplify the checks in the case of emails? Note that the=20 string "mailto:john%20doe%20AT%20example.org" is technically valid as a URL= ,=20 but does not conform to the mailto-scheme. (Also note that we use=20 rawurlencode() that uses '%20' instead of '+' to encode spaces, as required= =20 by RFC 3986 [1].) =2D- Markus [1] http://www.ietf.org/rfc/rfc3986.txt > > -- Asheesh. > > -- > A penny saved kills your career in government. =2D-=20 Markus Kr=F6tzsch Institut AIFB, Univers=E4t Karlsruhe (TH), 76128 Karlsruhe phone +49 (0)721 608 7362 fax +49 (0)721 608 5998 ma...@ai... www http://korrekt.org |
From: Dan B. <dan...@gm...> - 2007-11-05 14:51:46
|
Hi, I recently installed Semantic MediaWiki (version 1.0-RC1) from tar. Hopefully I didn't make a mistake during install, because I have been having difficulty getting some of the documented features working correctly. I was following the instructions given on this manual page; http://ontoworld.org/wiki/Help:Service_links (Sorry for the ugly banner at the top of that page, I created that to try and keep track of pages that look like they need to be updated or split in the light of SMW-1.0 syntax wrt. SMW-0.7 syntax). The upshot is that I can't get 'service links' to work on my install. I created a page called [[Urease]] with the following properties, [[Is a::protein]] [[Has pdb entry::1ura]] Then on the page [[Property:Has pdb entry]] I added the following assertions; [[has type::string]] [[provides service::rscb entry]] Both of those properties show up as 'special property in this wiki' in the fact box, however, the text 'rscb_entry' in the fact box is not clickable. I edited the page [[MediaWiki:Smw_service_rscb_entry]] to add the following; rscb|http://www.rcsb.org/pdb/explore/explore.do?structureId=$1 But no joy. FYI, the following is the link that I want to get (somewhere) on the wiki; http://www.rcsb.org/pdb/explore/explore.do?structureId=1ura Has this feature been dropped in 1.0? Is there a replacement? Thanks for any information, Dan. |
From: Asheesh L. <as...@cr...> - 2007-11-02 23:02:40
|
On Fri, 2 Nov 2007, S Page wrote: > cnit wrote: > >> Are the old MW 1.10/SMW 0.7 XML backups compatible with >> MW 1.11/SMW 1.0RC1? > > Whoa, slow down. Does your new installation work? When you follow the > exact instructions in the INSTALL file under "Testing your > Installation", do you get the expected results? > > Since you're having problems with categories (see later), try making a > few nested subcategories and doing queries on them. > >> I am trying to import my backup into the new >> installation, but it throws such error (smw_error1.txt). > > I don't know if the old backups are compatible. With each SMW and > MediaWiki update I made a backup but I made the upgrade in-place and ran > the updates scripts and SMWAdmin with no incident, so I never had to try > the backups. As someone with no backup to speak of nor a SMW lead developer, it sounds like the best thing to do is to restore the backup into the version it was taken from, and then use the built-in upgrade system to live upgrade between point releases of SMW/MW to upgrade your data format. -- Asheesh. -- A diplomatic husband said to his wife, "How do you expect me to remember your birthday when you never look any older?" |
From: S P. <in...@sk...> - 2007-11-02 22:42:35
|
cnit wrote: > Are the old MW 1.10/SMW 0.7 XML backups compatible with > MW 1.11/SMW 1.0RC1? Whoa, slow down. Does your new installation work? When you follow the exact instructions in the INSTALL file under "Testing your Installation", do you get the expected results? Since you're having problems with categories (see later), try making a few nested subcategories and doing queries on them. > I am trying to import my backup into the new > installation, but it throws such error (smw_error1.txt). I don't know if the old backups are compatible. With each SMW and MediaWiki update I made a backup but I made the upgrade in-place and ran the updates scripts and SMWAdmin with no incident, so I never had to try the backups. So everything I write is guessing 8-/ Error in fetchObject(): Table 'yarsu.cats4' doesn't exist (127.0.0.1) I think "catNNN" are temporary tables that SMW creates in getCategoryTable() when it makes "a (temporary) table that contains the lower closure of the given category wrt. the category table." I'm not sure why it's failing. It could be a database-level problem, such as a permissions issue. What PHP and MySQL versions are you running? If you can make a smaller XML file that fails to import, you can modify MediaWiki's LocalSettings.php to turn on extra SQL logging, for example: ## === from http://meta.wikimedia.org/wiki/How_to_debug_MediaWiki === /** * The debug log file should be not be publicly accessible if it is used, as it * may contain private data. */ $wgDebugLogFile = 'mediawiki_debug_log.txt'; # Override DefaultSettings.php $wgShowSQLErrors = true; ## === from http://www.mediawiki.org/wiki/Manual:%24wgDebugDumpSql $wgDebugDumpSql = true; and send part of the log file. In the failures you attached, the MediaWiki import script is parsing the XML of a page that apparently has an <ask> inline query in it, so it's calling smwfProcessInlineQuery() Can you try making a simple query for a category from Special:Ask? E.g. [[Help:+]] I guess you could try removing the inline query (search for ask) from the XML file and try reimporting. > > After that, I've decided to remove all the Attribute: > namespace pages from the dump. It's the inline queries for category that seem to be causing grief, so I think you should focus on removing those first. I think you can and should run the SMW_unifyProperties.php maintenance script after import. > Drop all the tables, > recreate the /config, do Special:SMWAdmin, now it throws another > error (smw_error2.txt) Almost the same error but now Error in fetchObject(): Table 'yarsu.cats1' doesn't exist (127.0.0.1) so again, the temporary queries of category tables don't work. > Next, I've removed Relation: namespace pages from the dump. > Now it produces the following error (smw_error3.txt) > > One of the functions parameter is '<div class="tbl...' > what's strange, there's no such string in the dump file. I think that must be a table produced by something. SMW doesn't use class="tbl...". So maybe you have some other extension or template that's generating tables. > Maybe someone can give me an advice which other pages shall I > remove from the dump, to do not interfere with SMW 1.0RC1? I can > recreate Attribute pages manually to the Property namespace, > just a few pages - not much of work... I would remove anything that has an <ask> query in it, and/or anything that has the mysterious extension or template that's generating the class="tbl stuff. I hope these guesses help. -- =S Page |
From: cnit <cn...@un...> - 2007-11-02 15:41:11
|
Hi! Are the old MW 1.10/SMW 0.7 XML backups compatible with MW 1.11/SMW 1.0RC1? I am trying to import my backup into the new installation, but it throws such error (smw_error1.txt). After that, I've decided to remove all the Attribute: namespace pages from the dump. Drop all the tables, recreate the /config, do Special:SMWAdmin, now it throws another error (smw_error2.txt) Next, I've removed Relation: namespace pages from the dump. Now it produces the following error (smw_error3.txt) One of the functions parameter is '<div class="tbl...' what's strange, there's no such string in the dump file. Maybe someone can give me an advice which other pages shall I remove from the dump, to do not interfere with SMW 1.0RC1? I can recreate Attribute pages manually to the Property namespace, just a few pages - not much of work... Dmitriy |
From: Asheesh L. <as...@cr...> - 2007-11-02 04:31:56
|
On a wiki I maintain, I find that people enter "spam hardened" (supposedly) email addresses, like asheesh AT creativecommons DOT org. I figured it would be nice to show those, even if they're not really email addresses. It was easy to comment out the validator, but that's not what this email is about: I propose (with a patch, attached) that SMW always urlencode() email addresses when generating their URIs and URLs. This is always a safe thing to do, and it may in some cases (as for me) be a crucial correctness issue. Hopefully you'll apply this. -- Asheesh. -- A penny saved kills your career in government. |
From: S P. <in...@sk...> - 2007-10-30 23:01:05
|
Yaron Koren wrote: > First of all, I don't know whether I should send bug reports to this > list, or put them on Bugzilla, or both... is there a recommended protocol? This is fine. The gold standard would be: * Create a page on http://ontoworld.org in Category:Testpage showing the bug and using [[Template:Bugged]] * Enter a bug in http://bugzilla.wikimedia.org whose URL field references back to the page on ontoworld.org * Attach a patch to the bug (I use Eclipse with PHPEclipse, it has a Team > Create patch... command) * Send an e-mail here. but "half a loaf is better than nothing" (and nothing is better than RDF, ergo half a loaf is better than RDF ?-) I reproduced your bug at http://ontoworld.org/wiki/Test_allows_value_wikipage and filed bug 11820. Your analysis below looks right to me. I wonder whether, in that loop, $value->setUserValue(); should also/instead reset member variables in subclasses, such as m_title in SMWWikiPageValue. I think error paths can leave other member variables like m_id and m_textform set to old values, and it's unclear to me which functions are responsible for resetting. Anyway, I checked in your fix, hoping I don't trash Subversion! Thanks, -- =S Page > Anyway, there's a bug in the handling of properties of type "Page" that > are enumerations - fields that have this property get a "not on the list > of possible values" error on the screen if they have a value other than > the very first one on the list. I traced this problem, and found the > issue: a variable is created, in "SMW_DataValue.php", to loop through > the list of allowed values, checking each one against the current value. > In the case of a wiki page, however, that variable keeps a cached > version of its title, that is set the very first time and then is never > reset. There are are various ways to solve this problem, but the easiest > might be to change the function parseUserValue() in the file > "/includes/SMW_DV_WikiPage.php". You can add a new line after line 26, > so inste ad of > > $this->m_value = $value; > > ...it now reads > > $this->m_value = $value; > $this->m_title = null; > > This will prevent the old value of "m_title" from getting read and used > in place of the actual value. > > -Yaron |
From: Yaron K. <ya...@gm...> - 2007-10-30 13:57:04
|
Hi, First of all, I don't know whether I should send bug reports to this list, or put them on Bugzilla, or both... is there a recommended protocol? Anyway, there's a bug in the handling of properties of type "Page" that are enumerations - fields that have this property get a "not on the list of possible values" error on the screen if they have a value other than the very first one on the list. I traced this problem, and found the issue: a variable is created, in "SMW_DataValue.php", to loop through the list of allowed values, checking each one against the current value. In the case of a wiki page, however, that variable keeps a cached version of its title, that is set the very first time and then is never reset. There are are various ways to solve this problem, but the easiest might be to change the function parseUserValue() in the file "/includes/SMW_DV_WikiPage.php". You can add a new line after line 26, so instead of $this->m_value = $value; ...it now reads $this->m_value = $value; $this->m_title = null; This will prevent the old value of "m_title" from getting read and used in place of the actual value. -Yaron |