>
> On May 29, 2013, at 7:02 AM, zehetner wrote:
>
>> Hi,
>>
>> in a wiki which runs
>> MediaWiki1.19.1
>> PHP 5.4.4 (apache2handler)
>> MySQL5.5.0-m2-log
>> Semantic MediaWiki (Version 1.8)
>> SMW Store 2
>>
Hi,
in a wiki which runs
MediaWiki 1.19.1
PHP 5.4.4 (apache2handler)
MySQL 5.5.0-m2-log
Semantic MediaWiki (Version 1.8)
SMW Store 2
I get a list of the pages in category Maps when I use the query:
{{#ask: [[Category:Maps]]}}
and format=debug shows as SQL somethin like
SELECT DISTINC
ere. :)
>
>
> On Thu, Apr 18, 2013 at 5:28 PM, zehetner
wrote:
>
>> Hi,
>> does anyone know if there is somewhere a description how record type
>> property values are stored in the new SMWSQLSto
Hi,
does anyone know if there is somewhere a description how record type
property values are stored in the new SMWSQLStore3 (or a general
description of the table structure)?
Thanks!
Gu
--
Precog is a next-generation anal
Hi,
I get an error when executing the query
{{#ask:[[Category:MainArticle]][[Chromosome
Name::2L]][[Anopheles:+||Plasmodium:+]]|format=count}}
(by using just one of the two namespaces alone the query returns 3054 and
0 resp. as result without error;
using '[[Category:MainArticle]][[Chromosome N
Hi,
Executing a query with format=debug and a property of type record where at
least one field has a value e.g.
{{#ask: [[GOslim:membrane;?;?]] | format=debug}}
gives the error
Fatal error: Call to a member function findPropertyTypeID() on a
non-object in
/w/extensions/SemanticMediaWiki/include
It seems to be ok. I did a 'svn update' and the special page appears
without error.
Cheers,
Gu
On Tue, 3 Jan 2012 09:02:08 -0500, Yaron Koren
wrote:
> Oh - it's worse than I thought, then. :) Hopefully the fix I added will
> still work.
>
> On Tue, Jan 3, 2012
elow
1.16
> (which was the plan), but support was accidentally removed for MW 1.16
as
> well - which is I assume the version that you're using. I just fixed
that
> in SVN.
>
> -Yaron
>
> On Tue, Jan 3, 2012 at 7:14 AM, zehetner wrote:
>
>> It's the li
2:36:20 -0800 (PST), Günther Zehetner
wrote:
> Hi,
>
> I just checked out 'Replace Text' via svn and when I try to go to the
page
> Special:ReplaceText I get the error:
> Fatal error: Call to a member function getGroup() on a
> non-object in .../w/includes/
Hi,
I just checked out 'Replace Text' via svn and when I try to go to the page
Special:ReplaceText I get the error:
Fatal error: Call to a member function getGroup() on a
non-object in .../w/includes/OutputPage.php
on line 2707
Did I miss something?
Using
MediaWiki
Would these subobjects interfere at some stage with the support of
multi-value properties or replace them? Or will they remain an additional
feature like the SIOs?
Gu
On Mon, 03 Oct 2011 10:02:32 +0100, Markus Krötzsch
wrote:
> Following up the discussions we had at SMWCon in Berlin, we have now
iaWiki developers"
> , "Semediawiki-user"
>
> Date: Wednesday, July 13, 2011, 11:06 PM
> On 13/07/11 20:23, Günther Zehetner
> wrote:
> > Hi,
> >
> > Does this mean for a record property like
> [[Item::Name;Source]] where Name and Source are defin
Hi,
Does this mean for a record property like [[Item::Name;Source]] where Name and
Source are defined as property String it is in SMW 1.6 not possible anymore to
see in the database which value is used for Name and which for Source? So
either Name;Source or Source;Name is returned and no way to
Hi,
using SMW 1.6 alpha (r91069)
I have the property [[NameId::Name2;Source2]] defined for the record
property NameId
Using an #ask query I get a result which looks like this: Source2
(Source2) instead of the correct result: Name2 (Source2)
The reason is, as far as I can see, the following:
i
Hi,
does somebody know if SMW 1.6 still keeps for multivalue (record type)
properties the information about the order of the single values somewhere
in the database or if that got lost?
Up to now in table atts2 the field p_id allowed to identify (with the help
of the smw_iw=':smw-intprop' values
Hi,
I use
MediaWiki 1.16.0
PHP 5.2.1 (apache2handler)
MySQL 5.5.0-m2
Semantic MediaWiki (Version 1.6 alpha)(r90660)
Property:NameId
[[has type::Record| ]][[has fields::string;string| ]]
Property:String
[[has type::string]]
On page Test7 I have
[[NameId::Name1;Source1| ]]
[[NameId::Name2;S
,
Gu
On Wed, 01 Jun 2011 17:14:26 +0100, Markus Krötzsch
wrote:
> On 01/06/11 10:05, zehetner wrote:
>> Hi,
>>
>> for record properties I get from $property->getPropertyTypeID() the
type
>> __err back
>
> That should not happen. I suppose that your type declaration
sValid() ) {
Gu
On Tue, 31 May 2011 16:02:37 +0100, Markus Krötzsch
wrote:
> On 30/05/11 11:48, zehetner wrote:
>> Hi,
>>
>> I'm trying to change my php code to work with SMW 1.6. (MW 1.16.0, SMW
>> 1.6
>> alpha r89160)
>> I updated the DB and data
Thanks Markus, this problem has disappeared now!
Cheers,
Gu
On Tue, 31 May 2011 16:02:37 +0100, Markus Krötzsch
wrote:
> On 30/05/11 11:48, zehetner wrote:
>> Hi,
>>
>> I'm trying to change my php code to work with SMW 1.6. (MW 1.16.0, SMW
>> 1.6
>> alph
6
internal functions, I don't know what I can do to avoid this problem.
Anything on the wiki level?
Thanks,
Gu
On Thu, 26 May 2011 07:40:32 +0100, Markus Krötzsch
wrote:
> On 25/05/11 11:20, zehetner wrote:
>> Hi,
>>
>> regarding
>>> * Type:Record decl
;
>> Using SMWParseData::storeData at the end of my parserhook solves the
>> problem with the data that I generate, but now any other semantic data
>> contained in the rest of the article is discarded... I guess it's
>> because of what the documentation for storeData sa
I use
SMWParseData::addProperty( $property, $prop_val, false, $wgParser, true
);
SMWParseData::storeData( $wgParser->getOutput(), $title, false );
which seems to work so far ok to store properties generated within an
extension (although it might not be the correct or official way to do it)
$p
Thanks Markus that's really good news.
I'll keep those restrictions in mind. Really large n-ary properties would anyway
be very much the exception.
Thanks again for your great SMW effort.
Cheers,
Gu
Quoting Markus Krötzsch :
> On Donnerstag, 4. März 2010, zehet...@molgen.mpg.de wrote:
> > Hi,
Hi,
well the number of possible fields in n-ary properties is a make or break
criteria for me to be able to use MW/SMW, so it's a point I don't dare to lose
out of sight.
Right now the largest properties I added to the wiki have 15 to 20 fields (but
there are potential data with 60+).
'Unlimited'
Hi Markus,
http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.5.0
doesn't mention any restriction in the number of 'fields' of an n-ary property
as it was mentioned in earlier announcements.
Has this new limitation been implemented in 1.5 and if so, what is the limit and
any advice how to c
Hi Markus,
> The change will also introduce some fixed
> limit on how many values a
> multi- valued property can at most have. It
> is currently set to 5.
can you please tell me what has now been implemented regarding the number of
values for multi-valued properties in SMW 1.5?
Thanks,
Gu
--
Hi,
anyone knows where the method unionQueries() is implemented?
When I try to go to Special:Properties I get the error
Fatal error: Call to undefined method DatabaseMysql::unionQueries() in
/mediawiki/extensions/SemanticMediaWiki/includes/storage/SMW_SQLStore2.php on
line 874
MW 1.15.1
SMW 1.5
Upps silly me, somehow I must have misread that installations with SMWSQLStore2
do the update automatically.
Sorry,
Gu
Quoting Markus Krötzsch :
> On Mittwoch, 10. Februar 2010, zehet...@molgen.mpg.de wrote:
> > Hi,
> >
> > I'm not sure if I see this correctly but it looks to me that SMW 1.5 do
Hi,
I'm not sure if I see this correctly but it looks to me that SMW 1.5 does some
modifications to the MySQL database (like creating new tables) which are
necessary for its 'internal part changes'.
What exactly does trigger those modifications?
When I simply replace the SMW 1.4 extension folder
Hi,
I would also look into the ArrayExtension
(http://www.mediawiki.org/wiki/Extension:ArrayExtension)
If you have something like
[[HeightLength::1;4]]
[[HeightLength::2;5]]
you can extract and assign a HeightArray and a LengthArray by queries (see
examples on extension page).
Unfortunately th
> > Related to this is the notion of named fields. Please give the option
> > to attach meaningful names to the fields for querying purposes, so
> > that the user doesn't have to specify a positional list of values.
> > For instance:
> >
> > [[has fields:: name=String; count=Number; source=Page]
Hi,
wouldn't be [[has type:: List]] most consistent with other types like String,
Number? Or are there other list types than 'Value List' (list of values)
possible (e.g. 'Object List' ...)?
What happens in the case of just one field used?
[[has type:: Value list]]
[[has fields:: String]]
Is it
Hi,
I see, thanks for explaining that. So getting the limit as close as possible
(and as your developing resources allow) to the already existing 'principal
limitation' you mentioned in the other mail is the best one can hope ;).
Although I use my SQFT extension quite satisfactory for my own purpo
Hi,
I'm not sure what the maximum is right now, between 10 and 20 but the point is
that tomorrow a dataset could come along which has 50 or more parts. So having
any fixed value, especially one which can only be changed by modifying the code
itself, is a serious drawback although I assume you have
Hi,
> The change will also introduce some fixed limit on how many values a multi-
> valued property can at most have. It is currently set to 5. If you have any
> such properties with more than 5 values then please let me know.
If I understand correctly you mean the number of value-parts a multi-
Just to add my 0.2 cent - it would be nice if the new Map+Semantic Map
extensions could be used in a similar independent way as the existing Semantic
Google Maps extension (which should be replaced by SM if I see that correctly).
I use an extended version of the Semantic Google Maps extension (whi
No nothing performance related at all, just pure ignorance and laziness on my
part in a quick hack in some extension.
Calling getPrefixedText() gives the proper result (with both SMW versions) and
also sets the mPrefixedText value in the title object (with the new SMW).
You are right, there alway
Hi,
thought first it's a MW 1.11 vs 1.13 issue but I'm using now MediaWiki 1.13.3
(r45906) where I just switch between the 'old XSDValue' SMW and the 'latest
DBkey' SMW version. Nothing else changes so I thought it might be relatet to the
new version. It's not really a problem for me as I can use
Hi,
it seems that the field 'mPrefixedText' in a Title object is now empty with the
new SVN version while previously it contained a value. Is this intentionally?
Thanks,
Gu
Quoting Markus Krötzsch :
> Update:
>
> I have tested the current SVN version successfully in combination with
> Semanti
I think it's objects creating new objects whose memory is than never released
even if the first object is unset.(most likely the php problem as described in
the link you sent me in your original reply). I tried to keep track where which
objects are created but I became quickly rather confused. I co
Thanks for the info.
Actually the MySQL version I mistyped it is 5.0.45 not 6.0.45
I'll see if I can update PHP sometime.
Cheers,
Gu
btw I solved my specific original problem by avoiding any objects and therefore
memory leaks altogether.
Quoting CNIT :
>
> > Hi,
> >
> > I wonder if anyone c
Hi,
I added some memory_get_usage() calls to the code
'before' is the return value before the call to
SMWQueryProcessor::getResultFromQueryString (with different offset values)
'#1' value in getInstanceQueryResult() after
$result = new SMWQueryResult()
'#2' value in getInstanceQueryResult()
Hi,
I wonder if anyone can tell me if the functions used when I call
SMWQueryProcessor::getResultFromQueryString should release all the memory after
they finished?
I thought I could avoid a memory problem by calling getResultFromQueryString
with different 'offset' values to retrieve smaller chunk
Nevermind I found the solution.
$property = SMWPropertyValue::makeUserProperty($prop_name);
$prop_type = $property->getTypeID();
Quoting [EMAIL PROTECTED]:
> Hi, can someone please enlighten me what is the best way to 'translate'
> this code to get the property type from the property name from th
Hi, can someone please enlighten me what is the best way to 'translate'
this code to get the property type from the property name from the 1.3 to the
1.4 syntax:
1.3
// property title and type
$prop_title = Title::newFromText($prop_name, SMW_NS_PROPERTY);
$prop_type = SMWDataValueFactory::getPrope
Hi,
I would like to be so bold and add two feature request suggestions for future
releases. These suggestions are with the old storage engine in mind as I can't
really say I have a clue yet how the new engine handles especially nary
properties (and therefore how to 'translate' my suggestion accord
Hi Markus
that sounds very interesting. As it will take a while before I can move to the
new version I'm wondering if these new features would allow me to combine query
results (e.g. using SMW_CONJUNCTION_QUERY and
SMW_DISJUNCTION_QUERY) as in the example below. I'm not sure because if I
understan
It would be really great to have a way to save results (and queries). As I
already mentioned, I try to set up a system where users can interactively fill
in values into pre-defined #ask queries by using userfriendly forms.
If for example a form allows to select a country and the start and end year
I'm sure the present implementation of the "n-ary" property is only an early
stage of this vital feature but I agree that the present state could be
described more precisely by a different name.
However, I just want to express my graditute that it exists at all because for
my own purpose the whole
Quoting Jon Lang <[EMAIL PROTECTED]>:
> Gu wrote:
> > So it might not be for general use (although it doesn't do any harm, it
> just
> > doesn't work if the class 'collapsible' is added and the JS isn't
> installed.
> > If installed it would of course be nicer to control that by using
> somethi
Upps sorry,
I completely forgot that this is an addition to Common.js. As it is used on
Wikipedia (http://en.wikipedia.org/wiki/Wikipedia:Collapsible_tables) and I must
have installed it quite long ago on my wiki I thought the 'collapsible' class
comes with the standard Mediawiki installation like
Thanks Markus - although I must admit I also like to exchange in my installation
the line
SMWFactbox::printProperties($text);
with
SMWFactbox::printProperties($text =
str_replace('class="smwfacttable">','class="smwfacttable collapsible
collapsed">',$text));
to be able to toggle between showing
Although I also wished there would be an easy solution to let only specific user
groups view certain parts of a page there doesn't seem to exist an extention or
other solution which addresses all the related problems according to
http://www.mediawiki.org/wiki/Security_issues_with_authorization_exte
Quoting S Page <[EMAIL PROTECTED]>:
> Add another consequence:
>
> 4) MediaWiki 1.10 or higher is now required.
>
> When I updated to latest SMW code in SVN while running MediaWiki 1.9.2,
> * errors because OutputPage.php doesn't have addHeadItem()
I got that error also still with MediaWiki: 1.
Maybe of interest for a specific SMW development project as Wikimedia Foundation
is also a mentoring organization? See http://code.google.com/soc/
Cheers,
Gu
-
Take Surveys. Earn Cash. Influence the Future of IT
Join Sourc
55 matches
Mail list logo
