Re: [SMW-devel] #ask for category pages not working in SMW 1.9 with Store 3
Yes I did refresh and other values are returned by ask queries but it seem
the majority of data haven't reached store 3 yet and I forgot that SMW
doesn't use the MW info for categories but it's own. Will take much, much
longer to finish the SMWUpdate jobs.
Thanks.
On Wed, 29 May 2013 08:01:53 -0500, Jamie Thingelstad
ja...@thingelstad.com wrote:
Just to make sure, did you refresh your data after moving to SqlStore3?
You need to do that before any data will show up.
Jamie Thingelstad
ja...@thingelstad.com
mobile: 612-810-3699
find me on AIM Twitter Facebook LinkedIn
On May 29, 2013, at 7:02 AM, zehetner zehet...@molgen.mpg.de 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
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 DISTINCT t2.smw_title AS t,t2.smw_namespace AS ns FROM `smw_ids`
AS
t2 INNER JOIN `smw_inst2` AS t0 ON t2.smw_id=t0.s_id WHERE
(t0.o_id='1597134') ORDER BY t2.smw_sortkey ASC LIMIT 51 OFFSET 0;
however, when I use the same data in a wiki which runs
MediaWiki1.20.0
PHP 5.4.4 (apache2handler)
MySQL5.5.0-m2-log
Semantic MediaWiki (Version 1.9 alpha) (c61b465)
SMW Store 3
I get no result with the same query and format=debug shows: Empty
result,
no SQL query created.
However looking in Special:Categories I see in both wikis the same
number
of pages.
Is this a bug, a changed behaviour or just temporarily not supported?
Or
is it a local problem with Store 3?
Is there maybe any alternative syntax for the #ask query which would
simulate the old behaviour?
Thanks
Guenther
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] #ask for category pages not working in SMW 1.9 with Store 3
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 DISTINCT t2.smw_title AS t,t2.smw_namespace AS ns FROM `smw_ids` AS
t2 INNER JOIN `smw_inst2` AS t0 ON t2.smw_id=t0.s_id WHERE
(t0.o_id='1597134') ORDER BY t2.smw_sortkey ASC LIMIT 51 OFFSET 0;
however, when I use the same data in a wiki which runs
MediaWiki 1.20.0
PHP 5.4.4 (apache2handler)
MySQL 5.5.0-m2-log
Semantic MediaWiki (Version 1.9 alpha) (c61b465)
SMW Store 3
I get no result with the same query and format=debug shows: Empty result,
no SQL query created.
However looking in Special:Categories I see in both wikis the same number
of pages.
Is this a bug, a changed behaviour or just temporarily not supported? Or
is it a local problem with Store 3?
Is there maybe any alternative syntax for the #ask query which would
simulate the old behaviour?
Thanks
Guenther
--
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with 2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Record type property values in SMWSQLStore3
Hi Nischay very helpful to get an idea where to start to look. For my purpose I'm actually not interested to which page a property belongs, just in all values of the single parts of a record property. Thanks Gu On Fri, 19 Apr 2013 11:10:13 +0530, Nischay Nahata nischay...@gmail.com wrote: Hi, A record type is stored in the form of a virtual page having many properties (called container). So a page name is generated using some md4 and then all the property values are stored as if they belonged to this *virtual* page. Which tables? they are distributed over all the property-values tables. To get to these values you have to first look into the wiki page table and find out the generated name of the wiki page and then use that to find values in other tables. Hope that makes sense :) Somebody, please correct me if I am wrong here. :) On Thu, Apr 18, 2013 at 5:28 PM, zehetner zehet...@molgen.mpg.de wrote: 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 analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Record type property values in SMWSQLStore3
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 analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Error with record type properties and format=debug
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/includes/SMW_DataValueFactory.php on line
130
Queries with other format values than 'debug' e.g. 'format=table' are
working ok and give the expected results.
Also {{#ask: [[GOslim:?;?;?]] | format=debug}} (no field values given)
returns the expected result.
It seems the function newDataItemValue is at some point called with the
variable $property having the value '1' causing
if ( !is_null( $property ) ) {
$typeId = $property-findPropertyTypeID();
to throw the error.
Changing the if to if ((is_object($property)) (!is_null($property)))
results in an empty white page instead of the error message.
I created such a record property on sandbox.semantic-mediawiki.org and see
there the same problem, except that with format=debug I don't get an error
message but always a white empty page.
Versions I use:
MediaWiki 1.18.1
Semantic MediaWiki (Version 1.8 alpha) (r115105)
Cheers,
Gu
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Extension 'Replace Text' Error
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 1.17.0 PHP 5.2.1 (apache2handler) MySQL 5.5.0-m2 Semantic MediaWiki (Version 1.7) Cheers, Gu -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Extension 'Replace Text' Error
It's the line $wgOut-addModuleStyles( 'mediawiki.special' ); in SpecialReplaceText.php which causes the error. No idea where 'mediawiki.special' styles should be defined. Commenting the line out makes the special page appear. Cheers, Gu On Tue, 3 Jan 2012 02:36:20 -0800 (PST), Günther Zehetner zehet...@molgen.mpg.de 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/OutputPage.php on line 2707 Did I miss something? Using MediaWiki 1.17.0 PHP 5.2.1 (apache2handler) MySQL 5.5.0-m2 Semantic MediaWiki (Version 1.7) Cheers, Gu -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Extension 'Replace Text' Error
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 ya...@wikiworks.com wrote: Oh - it's worse than I thought, then. :) Hopefully the fix I added will still work. On Tue, Jan 3, 2012 at 8:46 AM, zehetner zehet...@molgen.mpg.de wrote: Thanks Yaron! I'm using MediaWiki 1.17.0 Gu On Tue, 3 Jan 2012 08:40:00 -0500, Yaron Koren ya...@wikiworks.com wrote: Hi Gu, Thanks for pointing that out. There were some changes to the Replace Text extension a few days that removed support for MediaWiki versions below 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 zehet...@molgen.mpg.de wrote: It's the line $wgOut-addModuleStyles( 'mediawiki.special' ); in SpecialReplaceText.php which causes the error. No idea where 'mediawiki.special' styles should be defined. Commenting the line out makes the special page appear. Cheers, Gu On Tue, 3 Jan 2012 02:36:20 -0800 (PST), Günther Zehetner zehet...@molgen.mpg.de 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/OutputPage.php on line 2707 Did I miss something? Using MediaWiki 1.17.0 PHP 5.2.1 (apache2handler) MySQL 5.5.0-m2 Semantic MediaWiki (Version 1.7) Cheers, Gu -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] RFC Subobjects (aka internal objects) in SMW
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
mar...@semantic-mediawiki.org wrote:
Following up the discussions we had at SMWCon in Berlin, we have now
implemented a new feature for internal objects in SMW. This email
explains this feature and starts the discussion on some open questions
for it to become stable.
== Goal ==
Allow SMW annotations to refer to objects that have their own
property-value pairs just like wiki pages, but that do not actually have
an article in the wiki. This can be used to group property-value pairs
given on one page without requiring new auxiliary pages to be created.
It also integrates the main functionality of the Semantic Internal
Objects (SIO) extension into SMW.
== Feature Overview: Current Prototype Implementation ==
SMW now has a new subobject feature. For example, you can use the
parserfunction #subobject on some page Example page as follows:
{{#subobject:street address
| street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
| country=UK
}}
This does the following:
(A) create a new subobject called Example page#_anInternalId,
(B) assign the property values for street name, ..., country to this
subobject,
(C) assign the subobject Example page#_anInternalId as a property
value for street address to Example page.
You could have achieved a similar effect as follows:
(A') create a new page called my auxiliary page,
(B') edit this new page to contain the text:
[[street name::Parks Road]]
[[postcode::OX1 3QD]]
[[city::Oxford]]
[[country::UK]]
(C') edit the page Example page to contain the text:
[[street address::my auxiliary page]]
The difference when using #subobject is that you do not create a new
auxiliary page. Instead, a subobject of Example page is created by
SMW. Also, the function #subobject does not display anything unless an
error occurred that needs to be reported.
Subobjects are named automatically by following the schema Parent page
name#_someInternalId. When subobjects are displayed to users, they thus
appear like links to sections within their parent page. This can happen,
e.g., subobjects might occur in query results (example above: {{#ask:
[[postcode::OX1 3QD]] }}). Likewise, subobjects are also addressed by
this name Parent page name#_someInternalId in all search and export
interfaces in SMW. For example, one can view the data for one particular
subobject in Special:Browse.
In general, subobjects should work like normal pages in most SMW
interfaces. The goal of this naming is to avoid any clashes with real
pages and with real sections in real pages while still allowing the same
methods to be used.
The feature can be tested in the current SVN version but it is still
unstable and might change significantly (read on).
== Relation to Semantic Internal Objects ==
The feature is very similar to the SIO extension. The difference is that
in SIO, the main property (street address above) points from the
subobject to the parent page. In the above example, street address
really means has street address while in SIO it would be used like is
street address of.
The other difference is that subobjects work with both SQL and RDF
stores, are exported in RDF and are compatible with interfaces like
Special:Browse.
== Alternative Proposal ==
Instead of having a parser function that creates a subobject and assigns
it to a property as a value, one could also have a parser function that
only does the first thing and that *returns* a subobject for later use.
This would require some further changes but it might be more elegant.
For example, a call like
{{#subobject: street name=Parks Road | postcode=OX1 3QD| city=Oxford }}
would just create such an object and return its name (e.g.
Example_page#_someId). Then one could use this name as a value to
other properties, e.g.:
[[street address::{{#subobject: street name=Parks Road
| postcode=OX1 3QD
| city=Oxford
}}]]
One advantage of this is that one could arbitrarily nest subobjects,
i.e. use subobjects as property values when declaring other subobjects
(SMW can already do this, just the input syntax does not support it).
Another advantage is that subobjects could (optionally) be named instead
of using the name generated by SMW now. For example, one could have
{{#subobject:department_address
|street name=Parks Road | postcode=OX1 3QD| city=Oxford }}
to create a subobject called Example page#department_address which
could be used in other annotations on *any* page (this is already
possible with subobjects now, but since their names are generated by SMW
they might not be stable over time). In this case, it might be less
desirable to return the name of
Re: [SMW-devel] [Semediawiki-user] [News] New default properties for each type
Thanks for the detailed information. It sounds certainly like a big improvement
although losing the order information of the record fields is quite a big
shock. Using these new default properties is then a bit dangerous because
although it technically works the returned information is, if more than one
default type exists within a record, rather unusable as the fields are randomly
mixed up so one has to be careful as this problem might initially not be
obvious.
Do ask queries like {{#ask: [[RecProp::;;3.5;;]]|?RecProp|format=table}} still
work by the system looking up what property type the third field of the record
has before executing the query?
Thanks,
Günther
--- On Wed, 7/13/11, Markus Krötzsch mar...@semantic-mediawiki.org wrote:
From: Markus Krötzsch mar...@semantic-mediawiki.org
Subject: Re: [Semediawiki-user] [News] New default properties for each type
To: zehet...@molgen.mpg.de
Cc: Semantic MediaWiki developers
semediawiki-devel@lists.sourceforge.net, Semediawiki-user
semediawiki-u...@lists.sourceforge.net
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 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 know which is which???
That depends on the declaration that you use for Item. The
change in
Type:Record is that it now stores values by /property name/
(as
everything else in SMW) and not by /position/. So if you
declare a
Record like
[[has fields::String;String]]
then the two values would both be assigned to the new
builtin
datatype-named Property:String. No order would be stored
and you would
get any order when querying.
However, you can fix this easily: just create new
properties of type
String, e.g. Property:Name and Property:Source, and change
the
declaration of Item to
[[has fields::Name;Source]]
You could also call the properties String1 and String2 if
you have no
better name for them. But the idea is that using
human-readable names
helps to make Records more user-friendly. For example, it
is possible to
query directly for values of property Name while this would
have been
impossible with the old Records. Overall, all browsing,
search, and
query features of SMW will work more smoothly with Records.
(Basically,
Record values behave like internal wiki pages that have the
property
values of the record).
The new system is strictly more powerful than the old one
(since you can
simulate the old one using dummy properties like String1,
Page2, etc.
while you can query these properties in the new system
only). It creates
some inconvenience during transition, but the new
datatype-named builtin
properties should minimize this.
The next step will be to create further datatypes that can
act as
containers for arbitrary property-value pairs. Record only
works with a
fixed list of input properties (main advantage: the
property does not
need to be named when using it). But there is really no
reason in SMW
now to have this restriction. One could as well have
arbitrary
property-value groups that need no prior declaration of
the allowed
properties. SMW already supports this internally -- all
that we need is
a syntax for writing such groups.
Regards
Markus
The new system will help smooth transition for
recent
changes in
Type:Record. Records are no longer declared with a
list of
types but
with a list of properties (which can be any
user-defined
property). With
the new type-named properties, the old
declarations will
still work
(exception: if the same type is used more than
once, the
order among the
associated values is not reliably preserved; you
should use
another more
specific property for avoiding duplicates).
--
AppSumo Presents a FREE Video for the SourceForge Community
by Eric
Ries, the creator of the Lean Startup Methodology on Lean
Startup
Secrets Revealed. This video shows you how to validate
your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Semediawiki-user mailing list
semediawiki-u...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-user
--
AppSumo Presents a FREE Video for the SourceForge Community by Eric
Ries, the creator of the Lean Startup Methodology on Lean Startup
Secrets Revealed. This video shows you how to validate your ideas,
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
Re: [SMW-devel] [Semediawiki-user] [News] New default properties for each type
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 know which is which??? Cheers, Gu The new system will help smooth transition for recent changes in Type:Record. Records are no longer declared with a list of types but with a list of properties (which can be any user-defined property). With the new type-named properties, the old declarations will still work (exception: if the same type is used more than once, the order among the associated values is not reliably preserved; you should use another more specific property for avoiding duplicates). -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Info about the order of fields of record properties still stored in the database?
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 from table ids) the original order of the values of value_xsd withing such a property. +-+--+---++---+ | s_id| p_id | value_xsd | value_unit | value_num | +-+--+---++---+ | 3950215 | 24 | Source1 || 0 | | 3993424 | 23 | Name3 || 0 | | 3950216 | 23 | Name2 || 0 | | 3950216 | 24 | Source2 || 0 | | 3950215 | 23 | Name1 || 0 | | 3993425 | 24 | Source4 || 0 | +-+--+---++---+ So in this case it was e.g. [[Prop::Name1;Source1]] and [[Prop::Name3;?]] and [[Prop::?;Source4]] etc. Now with SMW 1.6 the field p_id contains a smw_id value which points to the property type of the record field in table ids +-+-+---+---+ | s_id| p_id| value_xsd | value_num | +-+-+---+---+ | 3912158 | 3993483 | Source4 | 0 | | 3904473 | 3993483 | Source2 | 0 | | 3904473 | 3993483 | Name2 | 0 | | 3904472 | 3993483 | Name1 | 0 | | 3904472 | 3993483 | Source1 | 0 | | 3904474 | 3993483 | Name3 | 0 | +-+-+---+---+ So from this info one can not see anymore if the property was e.g. [[Prop::Name1;Source1]] or [[Prop::Source1;Name1]] and [[Prop::Name3;?]] or [[Prop::?;Name3]] etc. Is the order now maybe stored somewhere else in the DB tables? Would be most grateful if someone could give me a hint. Thanks Gu -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Strange #sak: results for record properties
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;Source2| ]]
[[NameId::Name3;| ]]
[[NameId::;Source4| ]]
[[Category:Testpages]]
Test queries:
{{#ask: [[Test7]] | ?NameId | format=table}} returns
[] NameId
Source4 (Source4)
Name3 (Name3)
Name2 (Name2)
Source1 (Source1)
{{#ask: [[Test7]] | ?NameId | format=ol}} returns
1. NameId Source4 (Source4) Name3 (Name3) Name2 (Name2) Source1 (Source1)
{{#ask: [[Category:Testpages]] | ?NameId | format=table}} returns
[][] NameId
Test7 Source4 (Source4)
Name3 (Name3)
Source2 (Source2)
Name1 (Name1)
{{#ask: [[Category:Testpages]] | ?NameId | format=ol}} returns
1. Test7 (NameId Source4 (Source4) Name3 (Name3) Source2 (Source2)
Name1 (Name1))
That doesn't look right?
Cheers,
Gu
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense..
http://p.sf.net/sfu/splunk-d2d-c1
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] SMW 1.6 entering testing phase
Thanks Markus!
Sorry if I didn't make it clear, the reason why I got __err back was the
erroneous '!' in the mentioned function (although I'm now not sure why none
record properties seemed to work even with the bug?).
Anyway in the corrected version all work fine.
Cheers,
Gu
On Wed, 01 Jun 2011 17:14:26 +0100, Markus Krötzsch
mar...@semantic-mediawiki.org 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 for such
properties reads [[has type::Record]]. If this is stored correctly,
you should get the ID '_rec' as a result. This type is no longer handled
in a special way in SMW. so I don't know why it would return an error.
and this function in includes/datavalues/SMW_DV_Property.php looks
strange:
...
shouldn't it rather be
if ( $this-isValid() ) {
instead of
if ( !$this-isValid() ) {
Yes! Changed in SVN now.
Markus
On Tue, 31 May 2011 16:02:37 +0100, Markus Krötzsch
mar...@semantic-mediawiki.org 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 with the SMWAdmin functions. #ask queries
seem
to work ok.
I use the calls
$property = SMWPropertyValue::makeUserProperty($propname);
$ptype = $property-getPropertyTypeID();
where $propname is the name of a property.
This seems to be valid in SMW 1.6 as it is used e.g. in file
includes/parserhooks/SMW_Declare.php
$property = SMWPropertyValue::makeUserProperty( $propertystring );
:
$type = $property-getPropertyTypeID();
As far as I can see I run into problems when
function getPropertyTypeID() calls
function getTypesValue() which calls
smwfGetStore()-getPropertyValues( $this-getWikiPageValue(), new
SMWDIProperty( '_TYPE' ) );
$this-getWikiPageValue() returns a 'SMWWikiPageValue Object' which
in
function
getPropertyValues( $subject, SMWDIProperty $property, $requestoptions
=
null ) is than passed as '$subject' argument to
$this-getSemanticData( $subject, array(
$property-findPropertyTypeID()
)
);
Calling getSemanticData with an 'SMWWikiPageValue Object' as $subject
causes an empty page because it seems it expects
a 'SMWDIWikiPage Object' instead in SMW 1.6?
getWikiPageValue(), however, seems to return for type _wpg always a
SMWWikiPageValue Object and doesn't know about SMWDIWikiPage
Object???
As I only submit a property name in my code and the rest are SMW 1.6
internal functions, I don't know what I can do to avoid this problem.
Anything on the wiki level?
Thanks for the report. The code on SVN (r89217) has now been fixed to
avoid this problem.
Note that SMWPropertyValue::makeUserProperty($propname) should only be
used if the input $propname is indeed some (possibly messy) user
input.
If the name of the property comes from a reliable source, then you can
also format it as a DB key (replace ' ' by '_') and use new
SMWDIProeprty($dbkey) to get an SMWDIProperty object right away (in
this case, findPropertyTypeId() is called to get the type id). But for
user input SMWPropertyValue is the right way to go.
Cheers,
Markus
On Thu, 26 May 2011 07:40:32 +0100, Markus Krötzsch
mar...@semantic-mediawiki.org wrote:
On 25/05/11 11:20, zehetner wrote:
Hi,
regarding
* Type:Record declarations change:
Properties of Type:Record no longer take a list of types, but a
list
of
properties as their declaration (has fields). This ensures that
Records
can use all information that is given on Property pages, not just
the
type declarations.
would there be a foreseeable problem to generate properties with
the
name
of the existing field types e.g Property:string, Property:page,
Property:number etc. to keep records functioning in the new SMW
version?
Otherwise having a rather large number of record properties it
would
mean
a lot of typing to change those names in the 'has fields'
declarations.
I think this is a good idea. Would it be useful to have one builtin
property for each registered datatype? This would not be hard to do
but
it would override any existing property declarations for these
labels.
Generating property pages would be a more complex process that would
need to be triggered explicitly (you cannot do this in the
background
on
every request).
Regards,
Markus
On Sun, 22 May 2011 16:10:37 +0100, Markus Krötzsch
mar...@semantic-mediawiki.orgwrote:
Dear SMW users and developers,
work on SMW 1.6 has made tremendous progress in the past few
weeks,
and
the code is stabilizing now. We still have quite some bugs to fix
ahead
of us, but the main changes in architecture and user features are
completed.
If they have not done it yet, extension developers should now
adapt
their code to work with the modified APIs. Audacious users are
invited
to beta
Re: [SMW-devel] SMW 1.6 entering testing phase
Hi,
for record properties I get from $property-getPropertyTypeID() the type
__err back
and this function in includes/datavalues/SMW_DV_Property.php looks
strange:
/**
* Convenience method to find the type id of this property. Most
callers
* should rather use SMWDIProperty::findPropertyTypeId() directly.
Note
* that this is not the same as getTypeID(), which returns the id
of
* this property datavalue.
*
* @return string
*/
public function getPropertyTypeID() {
if ( !$this-isValid() ) {
return $this-m_dataitem-findPropertyTypeId();
} else {
return '__err';
}
}
shouldn't it rather be
if ( $this-isValid() ) {
instead of
if ( !$this-isValid() ) {
Gu
On Tue, 31 May 2011 16:02:37 +0100, Markus Krötzsch
mar...@semantic-mediawiki.org 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 with the SMWAdmin functions. #ask queries
seem
to work ok.
I use the calls
$property = SMWPropertyValue::makeUserProperty($propname);
$ptype = $property-getPropertyTypeID();
where $propname is the name of a property.
This seems to be valid in SMW 1.6 as it is used e.g. in file
includes/parserhooks/SMW_Declare.php
$property = SMWPropertyValue::makeUserProperty( $propertystring );
:
$type = $property-getPropertyTypeID();
As far as I can see I run into problems when
function getPropertyTypeID() calls
function getTypesValue() which calls
smwfGetStore()-getPropertyValues( $this-getWikiPageValue(), new
SMWDIProperty( '_TYPE' ) );
$this-getWikiPageValue() returns a 'SMWWikiPageValue Object' which in
function
getPropertyValues( $subject, SMWDIProperty $property, $requestoptions =
null ) is than passed as '$subject' argument to
$this-getSemanticData( $subject, array(
$property-findPropertyTypeID()
)
);
Calling getSemanticData with an 'SMWWikiPageValue Object' as $subject
causes an empty page because it seems it expects
a 'SMWDIWikiPage Object' instead in SMW 1.6?
getWikiPageValue(), however, seems to return for type _wpg always a
SMWWikiPageValue Object and doesn't know about SMWDIWikiPage Object???
As I only submit a property name in my code and the rest are SMW 1.6
internal functions, I don't know what I can do to avoid this problem.
Anything on the wiki level?
Thanks for the report. The code on SVN (r89217) has now been fixed to
avoid this problem.
Note that SMWPropertyValue::makeUserProperty($propname) should only be
used if the input $propname is indeed some (possibly messy) user input.
If the name of the property comes from a reliable source, then you can
also format it as a DB key (replace ' ' by '_') and use new
SMWDIProeprty($dbkey) to get an SMWDIProperty object right away (in
this case, findPropertyTypeId() is called to get the type id). But for
user input SMWPropertyValue is the right way to go.
Cheers,
Markus
On Thu, 26 May 2011 07:40:32 +0100, Markus Krötzsch
mar...@semantic-mediawiki.org wrote:
On 25/05/11 11:20, zehetner wrote:
Hi,
regarding
* Type:Record declarations change:
Properties of Type:Record no longer take a list of types, but a list
of
properties as their declaration (has fields). This ensures that
Records
can use all information that is given on Property pages, not just
the
type declarations.
would there be a foreseeable problem to generate properties with the
name
of the existing field types e.g Property:string, Property:page,
Property:number etc. to keep records functioning in the new SMW
version?
Otherwise having a rather large number of record properties it would
mean
a lot of typing to change those names in the 'has fields'
declarations.
I think this is a good idea. Would it be useful to have one builtin
property for each registered datatype? This would not be hard to do
but
it would override any existing property declarations for these labels.
Generating property pages would be a more complex process that would
need to be triggered explicitly (you cannot do this in the background
on
every request).
Regards,
Markus
On Sun, 22 May 2011 16:10:37 +0100, Markus Krötzsch
mar...@semantic-mediawiki.org wrote:
Dear SMW users and developers,
work on SMW 1.6 has made tremendous progress in the past few weeks,
and
the code is stabilizing now. We still have quite some bugs to fix
ahead
of us, but the main changes in architecture and user features are
completed.
If they have not done it yet, extension developers should now adapt
their code to work with the modified APIs. Audacious users are
invited
to beta test. Installation instructions are online [1] and the SMW
Sandbox is updated to the most recent version [2].
== Main changes for users ==
* Significantly
Re: [SMW-devel] SMW 1.6 entering testing phase
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 with the SMWAdmin functions. #ask queries seem to work ok. I use the calls $property = SMWPropertyValue::makeUserProperty($propname); $ptype = $property-getPropertyTypeID(); where $propname is the name of a property. This seems to be valid in SMW 1.6 as it is used e.g. in file includes/parserhooks/SMW_Declare.php $property = SMWPropertyValue::makeUserProperty( $propertystring ); : $type = $property-getPropertyTypeID(); As far as I can see I run into problems when function getPropertyTypeID() calls function getTypesValue() which calls smwfGetStore()-getPropertyValues( $this-getWikiPageValue(), new SMWDIProperty( '_TYPE' ) ); $this-getWikiPageValue() returns a 'SMWWikiPageValue Object' which in function getPropertyValues( $subject, SMWDIProperty $property, $requestoptions = null ) is than passed as '$subject' argument to $this-getSemanticData( $subject, array( $property-findPropertyTypeID() ) ); Calling getSemanticData with an 'SMWWikiPageValue Object' as $subject causes an empty page because it seems it expects a 'SMWDIWikiPage Object' instead in SMW 1.6? getWikiPageValue(), however, seems to return for type _wpg always a SMWWikiPageValue Object and doesn't know about SMWDIWikiPage Object??? As I only submit a property name in my code and the rest are SMW 1.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 mar...@semantic-mediawiki.org wrote: On 25/05/11 11:20, zehetner wrote: Hi, regarding * Type:Record declarations change: Properties of Type:Record no longer take a list of types, but a list of properties as their declaration (has fields). This ensures that Records can use all information that is given on Property pages, not just the type declarations. would there be a foreseeable problem to generate properties with the name of the existing field types e.g Property:string, Property:page, Property:number etc. to keep records functioning in the new SMW version? Otherwise having a rather large number of record properties it would mean a lot of typing to change those names in the 'has fields' declarations. I think this is a good idea. Would it be useful to have one builtin property for each registered datatype? This would not be hard to do but it would override any existing property declarations for these labels. Generating property pages would be a more complex process that would need to be triggered explicitly (you cannot do this in the background on every request). Regards, Markus On Sun, 22 May 2011 16:10:37 +0100, Markus Krötzsch mar...@semantic-mediawiki.org wrote: Dear SMW users and developers, work on SMW 1.6 has made tremendous progress in the past few weeks, and the code is stabilizing now. We still have quite some bugs to fix ahead of us, but the main changes in architecture and user features are completed. If they have not done it yet, extension developers should now adapt their code to work with the modified APIs. Audacious users are invited to beta test. Installation instructions are online [1] and the SMW Sandbox is updated to the most recent version [2]. == Main changes for users == * Significantly extended database backend support: SMW now works with PostgreSQL and with any RDF store that supports SPARQL and SPARQL Update. I had sent details about the latter to this list earlier -- testers for Virtuoso and other stores would still be most welcome! Support for using the PHP-based interface of the RAP RDF store is discontinued. The new SPARQL functions change also prepare SMW for loading RDF data from other Web sources (not implemented yet). * Parameter validation for user inputs: The #ask function will now generate more helpful error messages if some input is not suitable, e.g. if limit is set to bogus instead of a number. Query printers may also use this capability for their own parameters, so that even extensions can provide this validation. For doing this, SMW requires the Validator extension to be installed. * No more Type namespace: As discussed on these lists, the Type namespace has been removed. There is a configuration setting that allows users to keep the Type namespace enabled (so that any pages there can still be accessed). The features of Type articles are now provided by Special:Types. * New Delimited-Separated Values format: This is like CSV but with a sane and easy-to-parse escaping of special characters. * Unit of measurement declarations change: With the vanishing of Type pages, users who have used custom types (for unit conversion) must move the text from the Type page to the Property page that uses these custom types. Instead of the custom type page, has type is now set to Quantity for properties that have custom unit conversions
Re: [SMW-devel] Problem with storing semantic attributes in a parserhook
Hi, I used initially also the addProperty/storeData method and run into the same problem. But SMW updates its store and as no property declarations are on the page the stored properties get lost during the update. I therefore switched to using the SMWWriter extension to store property values retrieved by my parser function from an external DB 'permanently' on a 'cache sub-page' of the actual page (which always includes this subpage). If the cache has expired the values are fetched again from the external DB and SMWWriter updates the #set statements on the 'cache sub-page'. Only during the initial creation of the pages (via a script) I initially store the properties via the SMWParseData::addProperty and SMWParseData::storeData method in order to have the property values immediatly available for statistical SMW queries. The page itself contains a call to the parser function (which retrieves the external data) and the also created 'cache subpage' is left empty. (Note as the page also contains some Category declarations I have also to manually update the SMW tables to store the category information as otherwise MW knows about them but not SMW and #ask queries don't work as expected). When the page is actually shown in the wiki the parser function checks the content of the 'cache-subpage' and if it's empty (or the cache time is expired) it fetches the data again from the external DB and now uses SMWWriter to write/update the #set statements on the 'cache sub-page' which keeps the properties 'permanently' stored. This procedure seems to work so far quite well. Gu On Tue, 21 Dec 2010 18:08:19 -0500, Laurent Alquier laur...@alquier.org wrote: I have been playing with ideas from this thread to do the same thing - add predefined properties from an extension. I came down to this basic code to add user defined properties (based on a predefined string $propertyName and a calculated value from my extension $value) $property = SMWPropertyValue::makeUserProperty( $propertyName ); $dv = SMWDataValueFactory::newPropertyObjectValue( $property, $value ); SMWParseData::getSMWData( $parser )-addPropertyObjectValue( $property, $dv ); I am also using the 'ParserAfterTidy' hook since it seems more appropriate to my extension is doing (add semantic annotations for authors of a page). At this point, my problem is this : 1- If I use this code as-is, no value seems to be saved for this page 2- If I use SMWParseData::storeData as indicated above, I lose some properties since storeData assumes parsing has been done when it is called. 3- If I use a direct access to the store by replacing : SMWParseData::getSMWData( $parser ) by : smwfGetStore()-getSemanticData($wgTitle) , values are saved but they get wiped out at the next refresh job. My question (and I assume, the original question as well) : How do I go from this user property code to saved values that will persist after a refresh ? Based on Markus recommendation, I did check the custom properties added by SME_ParseData and it seems that nothing more is needed than what I have above. Any insight ? code sample ? nudge in any direction ? :) - Laurent On Thu, Nov 4, 2010 at 4:51 AM, Harwarth, Stefan (Bundeswehr) stefan.harwa...@cassidian.com wrote: 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 says, that the parsing is assumed to be complete. So this is not the fix for my problem :( Stefan -Original Message- From: zehetner [mailto:zehet...@molgen.mpg.de] Sent: Monday, November 01, 2010 10:24 AM To: Harwarth, Stefan (Bundeswehr) Cc: semediawiki-devel@lists.sourceforge.net Subject: Re: [SMW-devel] Problem with storing semantic attributes in a parserhook 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) $property is a string with the property name, $prop_value the value of the property (in case of multi-valued properties a string like e.g. 'p1;p2;;p3') and $title a title object. Cheers, Gu On Fri, 29 Oct 2010 16:21:03 +0200, Harwarth, Stefan (Bundeswehr) stefan.harwa...@cassidian.com wrote: Hi, I'm working on an Mediawiki extension that uses the SMWData::addProperty function to store semantic data inside a parser hook function, which is working perfectly when saving a page. But when I use the ApprovedRevs extension to approve the revision of an article, my semantic data isn't stored, even though the call to addProperty is executed and a valid DataValue
Re: [SMW-devel] [News] SMW 1.5.0 is near
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 convert larger 1.4 n-ary properties to 1.5? Thanks, Gu Quoting Markus Krötzsch mar...@semantic-mediawiki.org: Hi all, we plan to release SMW 1.5.0 within the next few days. Two or three issues still are on my list for being fixed, but most of the code should be ready now. Moreover, there has just been a new release of Semantic Maps, and there will soon be a release of Semantic Forms. Testers are welcome. I know that many people are running the SVN version anyway, but it may now be a good time to checkout the most recent updates and to confirm that all functions that are important to your wiki are running as expected. Information on how to upgrade can be found on the preliminary release page: http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.5.0 Last minute feedback can be sent to this list, or filed to the bugtracker. Translations to the static translation files are also welcome, but we also will have a 1.5.1 release not too long after SMW 1.5.0 to be able to incorporate such improvements. Cheers, Markus -- Markus Krötzsch mar...@semantic-mediawiki.org * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [News] SMW 1.5.0 is near
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' sounds too good to ask for ;) but a number below 20 would certainly not allow me to update. Cheers, Gu Quoting Markus Krötzsch mar...@semantic-mediawiki.org: On Donnerstag, 4. März 2010, zehet...@molgen.mpg.de wrote: 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 convert larger 1.4 n-ary properties to 1.5? Oh, you are very observant. I have left this away since I am not certain yet if I can provide support for records of unlimited size for 1.5.0 or not. If not, then I can only advice users of larger records to not upgrade until a fix has been found. How large were your records again? -- Markus Quoting Markus Krötzsch mar...@semantic-mediawiki.org: Hi all, we plan to release SMW 1.5.0 within the next few days. Two or three issues still are on my list for being fixed, but most of the code should be ready now. Moreover, there has just been a new release of Semantic Maps, and there will soon be a release of Semantic Forms. Testers are welcome. I know that many people are running the SVN version anyway, but it may now be a good time to checkout the most recent updates and to confirm that all functions that are important to your wiki are running as expected. Information on how to upgrade can be found on the preliminary release page: http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.5.0 Last minute feedback can be sent to this list, or filed to the bugtracker. Translations to the static translation files are also welcome, but we also will have a 1.5.1 release not too long after SMW 1.5.0 to be able to incorporate such improvements. Cheers, Markus -- Markus Krötzsch mar...@semantic-mediawiki.org * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Status SMW, release plans for 1.5.0
Upps silly me, somehow I must have misread that installations with SMWSQLStore2
do the update automatically.
Sorry,
Gu
Quoting Markus Krötzsch mar...@semantic-mediawiki.org:
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 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?
The install/update button on Special:SMWAdmin. It is also possible to trigger
the update from the command line (like when upgrading MediaWiki). See INSTALL
for details on how to upgrade SMW.
I hope that this fixes your problem.
-- Markus
When I simply replace the SMW 1.4 extension folder with a new SMW 1.5
folder and try to go to a page (even a non-existing one) I get an
MediaWiki internal error because in function SMW:getSemanticData a SQL
query is executed which uses a table smw_subp2 which doesn't exist (yet).
Original exception: exception 'DBQueryError' with message 'A database
error
has occurred
Query: SELECT DISTINCT o_id AS id0,o0.smw_title AS v0,o0.smw_namespace AS
v1,o0.smw_iw AS v2,o0.smw_sortkey AS v3 FROM `cmw_smw_subp2` INNER JOIN
`cmw_smw_ids` AS o0 ON o_id=o0.smw_id WHERE s_id='542'
Function: SMW::getSemanticData
Error: 1146 Table 'cancerdb.cmw_smw_subp2' doesn't exist
(localhost:mysql5.sock)
I guess that's one of the newly created tables but how do I force that
update/modification to create it?
The stack trace suggests that the SMW query, even on a non-existing page,
is triggered by SemanticForms
SFFormEditTab::displayTab(Object(SkinMonoBook),Array)
SFLinkUtils::getFormsThatPagePointsTo('Non-Kinase', 14, '_SF_DF',
'_SF_DF_BACKUP', 1)
SMWSQLStore2-getPropertyValues(Object(Title), Object(SMWPropertyValue))
If I disable the inclusion of SF_Settings.php (btw. the latest SVN
version)
the error disappears.
Thanks,
Gu
Quoting Markus Krötzsch mar...@semantic-mediawiki.org:
And another copy for devel list. My first email went to the list owners
only:
email address autocompletion is a dangerous thing. -- Markus
On Montag, 8. Februar 2010, Markus Krötzsch wrote:
Dear SMW users,
this is just to let you know that the main changes to the SVN version
of SMW have been completed, and that the release of SMW 1.5.0 is
planned for February now. Since there have been major changes in some
internal parts, it would be good to get some testing going.
Especially,
extension developers should check that there are no compatibility
problems with the new version -- little has changed in the officially
documented
interfaces,
but you never know.
The main changes in SMW 1.5.0 are internal, cleaning up the rather
complex piece of code use for database access in SMW, and should not
be
visible to the user unless something went wrong. On the user level, a
different declaration of n-ary (multi-valued) properties, and an
extended UI for Special:Ask are the most noticeable changes.
We have heard that some users have reported problems/bugs with the SVN
version on IRC recently, but we do not know what exactly the problems
were. There are no logs of the IRC (and in any case single messages
are easy to overlook). So please, if you find any problems in SMW, be
sure to report them on bugzilla.mediawiki.org, or at least send some
email to one of the lists where it is on archive. Otherwise, your
problem reports have a high chance of going unnoticed.
Cheers,
Markus
--
Markus Krötzsch mar...@semantic-mediawiki.org
* Personal page: http://korrekt.org
* Semantic MediaWiki: http://semantic-mediawiki.org
* Semantic Web textbook: http://semantic-web-book.org
--
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] property defined by function
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 the ArrayExtension doesn't implement the array_map function but it
shouldn't be too difficult to add something like #arraymap which would use PHP's
array_map() function with the given parameters.
And than something along the line
{{#arraydefine:SquareArray|
{{#arraymap:HeightArray|LengthArray|'function($l,$h){return(0.5*$h*$l);}' }}
would return an array of the results.
Cheers,
Gu
Quoting Zeev Pekar z.pe...@gmail.com:
Hi,
I've just added an enhancement request:
https://bugzilla.wikimedia.org/show_bug.cgi?id=22303
Do you think it is interesting enough so that SMW developers will
implement it? If yes, how long might it take? If no, could you please
tell me, whether it is hard to implement such extension and which areas
should I take a look at if I have to implement it myself (I'm new to
SMW)?
thank you in advance,
Zeev
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the
business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Changes for using multi-valued properties
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 equivalent to [[has type:: String]]?
In the query example shouldn't
{{#ask: [[has type::~*;*]] }}
be
{{#ask: [[has fields::~*;*]] }}
?
Cheers,
Gu
P.S.
Just a thought, for backward compatibility, couldn't SMW if it finds a [[has
type::]] value string with a ';' in it silently use it as [[has fields::]] value
and set [[has type::]] to 'Value List' (or whatever name is used)?
Quoting Markus Krötzsch mar...@semantic-mediawiki.org:
The code for n-ary/multivalued has now been changed in SVN, and a new system
is in place. This email describes the changes for users, and asks for
proposals on how to label some things that users will have to enter. This
thread does not discuss the maximal number of fields in a multi-valued
property (there is another thread for this).
== Changes for the user ==
The old way of declaring an n-ary property was to give a type annotation like
the following on its property page:
[[has type:: String; Number; Page]]
This example declares a property that has three fields of the given order and
type. The new code requires a modified declaration that contains two
annotations:
[[has type:: Value list]]
[[has fields:: String; Number; Page]]
So the type is no longer the list but it has a name, and the list of fields
is
given in a new property. This change needs to be done to all property pages
that use a declaration like the old one above (but please read on before
updating from SVN and starting with this change). With the new SMW, you can
actually ask for those properties with the query (~ is now enabled by default
for all sites):
{{#ask: [[has type::~*;*]] }}
(Note that types are not stored with their translated labels internally, so ~
queries are not likely to be of much use for has_type in general; but it
works
well enough for the ; in n-ary types. The fact that this works also
illustrates how the new SMW code consistently supports all features in the
same way for all properties/datatypes that allow it.)
== Call for labels ==
Two new labels are used above: Value list (the name of the type) and has
fields (the name of the property for declaring which fields this property
has). Both labels are just preliminary and may still be changed. We have
already had some history of changing the name of n-ary/multi-valued
properties.
Technically, the new type is not a list (a sequence of arbitrary length
with
a fixed type) but a tuple (like a pair but not specifically with 2
values). But this term will not be meaningful to most users, so maybe list is
not so bad. We can still change it if better proposals are made.
Afterwards, we will need translations for the labels so that non-en wikis can
use their own language right away, but I will call for this in another
email.
Cheers,
Markus
--
Markus Krötzsch mar...@semantic-mediawiki.org
* Personal page: http://korrekt.org
* Semantic MediaWiki: http://semantic-mediawiki.org
* Semantic Web textbook: http://semantic-web-book.org
--
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Changes for using multi-valued properties
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]] This would allow queries for instances of the property by means of a specific value for the name, property, and/or source. As I said, this task can be approached now. It is not going to be an extension of Type:List (the current favourite name of Value list), but another type that allows for these inputs (how could this be called?). Thanks for your syntax proposal; I think this is probably the most straightforward syntax to pick. Another possibility, which I partly use in the SQFT extension, would be to supply the names via other properties on the property page which allows different set of names for different purposes (e.g. as index replacement in ask queries, as table headers etc.): [[has fields:: String; Number; Page]] [[has names:: name; count; source]] [[has long_names:: official id of component; occurences between 2000 and 2007; first publication mentioning component]] [[has headers:: ID by EMBL; 2000-2007 ; Publication]] Gu -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [News] SVN update warning
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-valued property can have. Most of my properties are multivalued and some certainly have more than just 5 parts. I really hope that 'limit' will be a variable set via LocalSettings (for my use of SMW this change sounds rather scary and makes me really kind of nervous). Cheers, Gu Quoting Markus Krötzsch mar...@semantic-mediawiki.org: In preparation of SMW 1.5, I am currently doing some large-scale changes to certain internals of the SMW code. This involves changes in the way in which multi-valued properties (a.k.a. n-ary properties) are handled. Eventually, only very little will change from a user's perspective (only a small change on the property page of each multi-valued properties will be needed), but a lot will change internally. 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. I therefore suggest to not upgrade wikis that use such properties to the development version of SMW until the details on how to modify the pages have been published and everything is known to work again. I will send a separate email to the developers' list regarding changes that might affect developers. Cheers, Markus -- Markus Krötzsch mar...@semantic-mediawiki.org * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org -- -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [News] SVN update warning
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 a reasons why this limitation is necessary. It would, howerver, be great to have at least a global variable so one doesn't have to patch the code after each update. Cheers, Gu Quoting Markus Krötzsch mar...@semantic-mediawiki.org: On Mittwoch, 6. Januar 2010, zehet...@molgen.mpg.de wrote: 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-valued property can have. Most of my properties are multivalued and some certainly have more than just 5 parts. I really hope that 'limit' will be a variable set via LocalSettings (for my use of SMW this change sounds rather scary and makes me really kind of nervous). So far, the limit is not planned to be a variable, but we can set a higher value right away if you need it. How many types do your longest n-ary properties have? Cheers, Markus Cheers, Gu Quoting Markus Krötzsch mar...@semantic-mediawiki.org: In preparation of SMW 1.5, I am currently doing some large-scale changes to certain internals of the SMW code. This involves changes in the way in which multi-valued properties (a.k.a. n-ary properties) are handled. Eventually, only very little will change from a user's perspective (only a small change on the property page of each multi-valued properties will be needed), but a lot will change internally. 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. I therefore suggest to not upgrade wikis that use such properties to the development version of SMW until the details on how to modify the pages have been published and everything is known to work again. I will send a separate email to the developers' list regarding changes that might affect developers. Cheers, Markus -- Markus Krötzsch mar...@semantic-mediawiki.org * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org -- -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] Maps and Semantic Maps
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 (which I need to deal with values in geo-coded multivalue properties) and it would be great if at some stage I could switch over to the new SM extension. Thanks, Gu Quoting jeroen De Dauw jeroen_ded...@yahoo.com: Although the third option is entirely possible, and probably will work just as well as when placing the form inputs to SM or SRF, I really doubt this is good practice. It's kind of just throwing the code into one of the extension's dependencies, which has quite frankly nothing do do with the code, and then not bothering it any further since the code gets loaded where it's needed. So I'd go only for this approach as a last resort. I also wouldn't let the fact that this is ANOTHER extension affect any design decisions. After all, there already are a lot, so one more won't hurt. Furthermore, Maps and Semantic Maps are in themselves bundling quite some functionality (just look at how many map related extensions there are out there), and so actually reducing the number of relevant extensions to choose from. And when ready, I suppose it can be added to Semantic Bundle and replace SGM and GG that are currenly in it. One more point for keeping SM seperate is that in the future functionallity that is not suited to be in SRF might be added. If the code is in SRF, that can hamper the developement of such code, since it'l then be more difficult to get SM seperate again. Cheers, De Dauw '[RTS]BN+VS*' Jeroen Forum: code.bn2vs.com Blog: blog.bn2vs.com Xfire: bn2vs ; Skype: rts.bn.vs Don't panic. Don't be evil. 70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! From: Sergey Chernyshev sergey.chernys...@gmail.com To: Yaron Koren yaro...@gmail.com Cc: mar...@semantic-mediawiki.org; semediawiki-devel@lists.sourceforge.net; jeroen De Dauw jeroen_ded...@yahoo.com Sent: Thursday, July 16, 2009 4:54:40 PM Subject: Re: [SMW-devel] Maps and Semantic Maps Actually, third options is OK - it just tells the system that if SF is enabled, here's additional functionality for it. This way, it can be SRF + Maps and that's it, right? Do you think there will be other feature in the future that can go into Semantic Maps that will go beyond being either part of Maps or SRF? If not, then making it just Maps + SRF might be a good idea - this will definitely will increase distribution. After all, how many Semantic * extensions can we have? ;) Thank you, Sergey -- Sergey Chernyshev http://www.sergeychernyshev.com/ On Thu, Jul 16, 2009 at 10:47 AM, Yaron Koren yaro...@gmail.com wrote: Let me first comment that I don't think translation/internationalization is an issue either way - translatewiki.net already handles dozens of extensions, and more are always being added; for them to add another extension to the set is trivial, and the translators do an excellent job of taking care of new values, regardless of which extension they came from. I think perhaps it comes down to a philosophical issue of whether the Semantic Result Formats extension is meant to contain all formats not defined in SMW; or whether it's just a utility extension. The 'calendar' format in SRF already breaks the rules somewhat by defining new parser functions in addition to just a format; but form inputs seem to go beyond that, in that they're not tied in with querying at all. I should note that there's a third option, which is to move the form inputs into the Maps extension: after all, they're just a hook, and people who aren't using SMW/SF can ignore the code. It's probably not a good idea, but I wanted to throw that out there. -Yaron On Thu, Jul 16, 2009 at 9:31 AM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: On Donnerstag, 16. Juli 2009, jeroen De Dauw wrote: Hey, After my GSoC project ends, I will remain active in the community, continue to support both extensions, and very probably continue on improving them. To what extend will ofcourse depend on how much work I'll have at university. Of course. Free software always requires free time. It's already great if there will be some amount of continued bug fixing and basic maintenance. When released, both extensions will have roughly the same size as they have now. Maps is by far the largest, couse it contains the Open Layers API. Semantic Maps will be pretty small, and should therefore not form any problem when putting the code into SRF. So, as I see it, there are two advantages to ading the SM code to SRF: easier to distribute and a bigger user base. + slightly easier translation/internationalisation since you
Re: [SMW-devel] [News] Attention SVN users: upcoming SMW changes
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 always comes the time where one has to pay for shortcuts. Thanks, Gu Quoting Markus Krötzsch mar...@semantic-mediawiki.org: On Dienstag, 20. Januar 2009, zehet...@molgen.mpg.de wrote: 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 mTextform instead but I was just surprised to find that difference. This may or may not be related to changes in SMW, but it is generally a non- issue since it is based on a problem in your code that could easily be fixed: just use getPrefixedText() for accessing this value. Direct access to Title's members is not a good design, and it is bound to break sooner or later. As the Title documentation states: * @name Private member variables * Please use the accessor functions instead. Or do you believe in performance improvements based on not calling the accessors? It appears to be unlikely that this has any measurable impact on your application. Even if it had, there would probably be much more effective ways for speeding up things. -- Markus if ($object-getTypeID() == '_wpg') $pft = $object-getTitle()-mPrefixedText; If I print_r $object-getTitle() I get: Old SMW: Semantic MediaWiki (Version 1.5a-SVN) (is 1.4 I think but shows in Special:Version as 1.5a) Title Object ( [mTextform] = Entomological inoculation rates [mUrlform] = Entomological_inoculation_rates [mDbkeyform] = Entomological_inoculation_rates [mUserCaseDBKey] = [mNamespace] = 0 [mInterwiki] = [mFragment] = [mArticleID] = -1 [mLatestID] = [mRestrictions] = Array ( ) [mCascadeRestriction] = [mRestrictionsExpiry] = [mHasCascadingRestrictions] = [mCascadeRestrictionSources] = [mRestrictionsLoaded] = [mPrefixedText] = Entomological inoculation rates [mDefaultNamespace] = 0 [mWatched] = [mLength] = -1 [mRedirect] = [mOldRestrictions] = ) New SMW: Semantic MediaWiki (Version 1.5c-SVN) Title Object ( [mTextform] = Entomological inoculation rates [mUrlform] = Entomological_inoculation_rates [mDbkeyform] = Entomological_inoculation_rates [mUserCaseDBKey] = [mNamespace] = 0 [mInterwiki] = [mFragment] = [mArticleID] = -1 [mLatestID] = [mRestrictions] = Array ( ) [mCascadeRestriction] = [mRestrictionsExpiry] = [mHasCascadingRestrictions] = [mCascadeRestrictionSources] = [mRestrictionsLoaded] = [mPrefixedText] = [mDefaultNamespace] = 0 [mWatched] = [mLength] = -1 [mRedirect] = [mOldRestrictions] = ) Cheers, Gu Quoting Markus Krötzsch mar...@semantic-mediawiki.org: On Montag, 19. Januar 2009, zehet...@molgen.mpg.de wrote: 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? I don't quite understand. The class Title is part of MediaWiki and SMW is not changing it at all. To access the prefixed text of some title, use getPrefixedText(). This should work in all version of MediaWiki. In any case, SMW is not responsible if it fails, I hope ;-) Cheers, Markus Thanks, Gu Quoting Markus Krötzsch mar...@semantic-mediawiki.org: Update: I have tested the current SVN version successfully in combination with SemanticForms and SemanticResultFormats, and we now run it on a number of SMW sites. We might have an intermediate release with this update soon -- those who cannot wait may wish to give the current SVN version a try (it can be installed on top of SMW 1.4.* by simply replacing the files). Upgrade is strongly recommended for everybody who experiences blank pages (typical for PHP out-of-memory issues) on certain SMW-related operations. The changes can also speed up page display significantly under certain circumstances, especially if inline queries with many results and printouts are used. Cheers, Markus On Freitag, 16. Januar 2009, Markus Krötzsch wrote: Hi all, I have done some debugging of SMW's memory requirements during parsing and query answering, and I
Re: [SMW-devel] [News] Attention SVN users: upcoming SMW changes
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 mar...@semantic-mediawiki.org: Update: I have tested the current SVN version successfully in combination with SemanticForms and SemanticResultFormats, and we now run it on a number of SMW sites. We might have an intermediate release with this update soon -- those who cannot wait may wish to give the current SVN version a try (it can be installed on top of SMW 1.4.* by simply replacing the files). Upgrade is strongly recommended for everybody who experiences blank pages (typical for PHP out-of-memory issues) on certain SMW-related operations. The changes can also speed up page display significantly under certain circumstances, especially if inline queries with many results and printouts are used. Cheers, Markus On Freitag, 16. Januar 2009, Markus Krötzsch wrote: Hi all, I have done some debugging of SMW's memory requirements during parsing and query answering, and I identified a number of issues that lead to increased memory usage. To fix this, I have modified some parts of the internal architecture, which I will check into SVN soon. In effect, SMW (SVN) is faster and requires less memory, but I also assume that the changed architecture may still have some bugs. Also, there might theoretically be minor incompatibilities with SMW extensions, though I do not expect many such issues since the old interfaces have been kept unchanged. Yet, SVN users are hereby warned that some problems might still appear in places. Of course, feedback is welcome. There will be another mail to the developers' list with details. Cheers, Markus -- Markus Krötzsch Semantic MediaWikihttp://semantic-mediawiki.org http://korrekt.orgmar...@semantic-mediawiki.org -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] [News] Attention SVN users: upcoming SMW changes
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 mTextform instead but I was just surprised to find that difference. if ($object-getTypeID() == '_wpg') $pft = $object-getTitle()-mPrefixedText; If I print_r $object-getTitle() I get: Old SMW: Semantic MediaWiki (Version 1.5a-SVN) (is 1.4 I think but shows in Special:Version as 1.5a) Title Object ( [mTextform] = Entomological inoculation rates [mUrlform] = Entomological_inoculation_rates [mDbkeyform] = Entomological_inoculation_rates [mUserCaseDBKey] = [mNamespace] = 0 [mInterwiki] = [mFragment] = [mArticleID] = -1 [mLatestID] = [mRestrictions] = Array ( ) [mCascadeRestriction] = [mRestrictionsExpiry] = [mHasCascadingRestrictions] = [mCascadeRestrictionSources] = [mRestrictionsLoaded] = [mPrefixedText] = Entomological inoculation rates [mDefaultNamespace] = 0 [mWatched] = [mLength] = -1 [mRedirect] = [mOldRestrictions] = ) New SMW: Semantic MediaWiki (Version 1.5c-SVN) Title Object ( [mTextform] = Entomological inoculation rates [mUrlform] = Entomological_inoculation_rates [mDbkeyform] = Entomological_inoculation_rates [mUserCaseDBKey] = [mNamespace] = 0 [mInterwiki] = [mFragment] = [mArticleID] = -1 [mLatestID] = [mRestrictions] = Array ( ) [mCascadeRestriction] = [mRestrictionsExpiry] = [mHasCascadingRestrictions] = [mCascadeRestrictionSources] = [mRestrictionsLoaded] = [mPrefixedText] = [mDefaultNamespace] = 0 [mWatched] = [mLength] = -1 [mRedirect] = [mOldRestrictions] = ) Cheers, Gu Quoting Markus Krötzsch mar...@semantic-mediawiki.org: On Montag, 19. Januar 2009, zehet...@molgen.mpg.de wrote: 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? I don't quite understand. The class Title is part of MediaWiki and SMW is not changing it at all. To access the prefixed text of some title, use getPrefixedText(). This should work in all version of MediaWiki. In any case, SMW is not responsible if it fails, I hope ;-) Cheers, Markus Thanks, Gu Quoting Markus Krötzsch mar...@semantic-mediawiki.org: Update: I have tested the current SVN version successfully in combination with SemanticForms and SemanticResultFormats, and we now run it on a number of SMW sites. We might have an intermediate release with this update soon -- those who cannot wait may wish to give the current SVN version a try (it can be installed on top of SMW 1.4.* by simply replacing the files). Upgrade is strongly recommended for everybody who experiences blank pages (typical for PHP out-of-memory issues) on certain SMW-related operations. The changes can also speed up page display significantly under certain circumstances, especially if inline queries with many results and printouts are used. Cheers, Markus On Freitag, 16. Januar 2009, Markus Krötzsch wrote: Hi all, I have done some debugging of SMW's memory requirements during parsing and query answering, and I identified a number of issues that lead to increased memory usage. To fix this, I have modified some parts of the internal architecture, which I will check into SVN soon. In effect, SMW (SVN) is faster and requires less memory, but I also assume that the changed architecture may still have some bugs. Also, there might theoretically be minor incompatibilities with SMW extensions, though I do not expect many such issues since the old interfaces have been kept unchanged. Yet, SVN users are hereby warned that some problems might still appear in places. Of course, feedback is welcome. There will be another mail to the developers' list with details. Cheers, Markus -- Markus Krötzsch Semantic MediaWikihttp://semantic-mediawiki.org http://korrekt.orgmar...@semantic-mediawiki.org -- Markus Krötzsch Semantic MediaWikihttp://semantic-mediawiki.org http://korrekt.orgmar...@semantic-mediawiki.org -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net
Re: [SMW-devel] Memory leak?
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 c...@uniyar.ac.ru:
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 chunks of articles.
However,
at some point I still run out of memory during the loop, even if I just
call the
function and ignore the result.
$maxresults = 500;
$limit = $params['limit']; # is 10
for ($ofs = 0; $ofs $maxresults ; $ofs += $limit) {
$params['offset'] = $ofs;
$dummy = SMWQueryProcessor::getResultFromQueryString($querystring,
$params, $printouts, SMW_OUTPUT_WIKI);
}
When $ofs reaches 490 I run out of memory (Fatal error: Allowed memory size
of
134217728 bytes exhausted).
The test query is '[[MyProp::~*;?;?]][[Category:MainArticle]]' with about
19000
articles matching (as using [[MyProp::?;?;?]] gives the error 'The value
of
property MyProp was not understood', I have to replace one '?' with
'~*').
MediaWiki 1.13.1
PHP 5.2.1
MySQL 6.0.45
SMW 1.5a SVN
Thanks,
Gu
Hi!
By the way, from the linux admin point, you have not very stable
versions of PHP and MySQL.
I believe that mediawiki users had generally stayed away from PHP 5.2.x
branch until recent
releases (5.2.6, 5.2.8).
Is MySQL 6.x already stable enough? Some time ago it was still
experimental, probably
also introducing new not throuthly tested DB engine..
(I am doing very different things right now, but still hoping to build
another SMW site in
some time)..
Dmitriy
--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] SMW 1.3 vs 1.4 question
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::getPropertyObjectTypeID($prop_title); 1.4 $prop_title = Title::newFromText($prop_name, SMW_NS_PROPERTY); ??? Thanks, Gu - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
[SMW-devel] Feature request
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 according to the new
storage) but I hope these additions would make it possible for me to use queries
to the new storage engine without having to access the db directly.
1) An optional parameter 'nary' for the function getPropertyValues()
If this parameter is set with a numerical value and the PropertyObjectTypeID of
the specified property is '__nry' only values from the indicated nary
position would be retrieved (adding the condition 'and nary_pos = nary parameter
value' to the SQL query) instead of all values of the multivalue property.
2) Support of the SQL option DISTINCT for SMWRequestOptions objects
One of the SQL options supported in MW's Database.php is DISTINCT, however, the
SMWRequestOptions object in SMW doesn't have a variable for it.
So if the object would get an additional 'distinct' variable besides 'limit' and
'offset', one could in function getSQLOptions($requestoptions, $valuecol = NULL)
simply set the SQL option and the db select function could use it
if ($requestoptions-distinct 0) {
$sql_options['DISTINCT'] = 1;
}
Thanks very much,
Gu
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
Re: [SMW-devel] New feature: Query control and query permissions
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
understand the new features correctly they are more about storing the query
(syntax) itself rather than the actual result?
So could one do something like this theoretical example:
For instance if I have a wiki which stores workshop details.
There are events held in different countries at different times which offer a
possibly overlapping range of workshops. The wiki contains pages for the
workshops with their details stored as semantic data.
Someone is during spring (6.3. to 13.4.) in Paris (France), during summer
(6.6.-21.7.) in Berlin (Germany) and during autumn (1.10.-23.11) anywhere in the
UK. In order to avoid to sit in workshops during the hot summer he wants to find
those workshops offered in Germany during the summer which he doesn't need to
attend because they are also offered during the cooler seasons in the two other
countries.
Right now I would have one simple general form on a query page (called
'workshops') which would allow to select a start and end date, as well as a
place (a city and a country), and a combine method and then searches for
workshops at the indicated time period in the selected place (and save the
result using the specified combine method).
So the query would in principal look like this:
{{#ask: [[Category:Workshop]] | [[start::{{#var:startdate}}]]
[[end::{{#var:enddate}}]] [[place::{{#var:city}};{{#var:country}}]] |
store_as={{PAGENAME}} | combine={{#var:method}} }}
The heat sensitive person would now run the query three times with his three
sets of travel details:
1st query:
startdate = 6 March 2009
enddate = 13 April 2009
city = Paris
country = France
method = replace (default)
executing:
{{#ask: [[Category:Workshop]] | [[start::6 March 2009]] [[end::13 April 2009]]
[[place::Paris;France]] | store_as={{PAGENAME}} | combine=replace }}
this result (= list of workshop page titles) is first saved under the name
'workshops' in the database
2nd query:
startdate = 1 October 2009
enddate = 23 November 2009
city = ?
country = UK
method = union
executing:
{{#ask: [[Category:Workshop]] | [[start::1 October 2009]] [[end::23 November
2009]] [[place::?;UK]] | store_as={{PAGENAME}} | combine=union }}
this result (= list of workshop page titles) is combined by 'union' with the
existing 'workshops' result set and the combined result is saved.
3rd query:
startdate = 9 June 2009
enddate = 21 July 2009
city = Berlin
country = Germany
method = intersect
{{#ask: [[Category:Workshop]] | [[start::9 June 2009]] [[end::21 July 2009]]
[[place::Berlin;Germany]] | store_as={{PAGENAME}} | combine=intersect }}
this result (= list of workshop page titles) is combined by 'intersect' with the
existing 'workshops' result set and the combined result is now the desired list
of workshops which to avoid in Berlin and can be displayed.
(Or alternatively using method 'not_in' to select workshops which are only
offered in Germany).
I'm not sure if e.g. queries using SMW_CONJUNCTION_QUERY and
SMW_DISJUNCTION_QUERY and the new query saving features could be used to achieve
a similar result?
Cheers,
Gu
Quoting Markus Krötzsch [EMAIL PROTECTED]:
SMW 1.2 extends the options for controlling which queries users are allowed
to
ask, and it has a mechanism that can be used to let some users ask more than
others (permissions).
The detailed query control settings are achieved by the new configuration
parameter $smwgQFeatures. This parameter defines which query features are
allowed in #ask. The default is the following:
$smwgQFeatures = SMW_PROPERTY_QUERY | SMW_CATEGORY_QUERY | SMW_CONCEPT_QUERY
|
SMW_NAMESPACE_QUERY | SMW_CONJUNCTION_QUERY |
SMW_DISJUNCTION_QUERY;
This allows all existing features to be used. Other possible settings could
be:
only category intersections:
$smwgQFeatures = SMW_CATEGORY_QUERY | SMW_CONJUNCTION_QUERY;
only single concepts: (see earlier mail on concepts)
$smwgQFeatures = SMW_CONCEPT_QUERY;
anything but disjunctions:
$smwgQFeatures = SMW_ANY_QUERY ~SMW_DISJUNCTION_QUERY;
So you can very clearly customise SMW queries. This affects only the #ask
queries. Queries stored as concepts have their own setting, called
$smwgQConceptFeatures. For example, concepts currently are not allowed to
refer to other concepts (recursion is not handled properly by SMW yet).
This gives you a way to restrict query creation to some user group of the
wiki:
* set $smwgQFeatures = SMW_CONCEPT_QUERY;
* configure MediaWiki to have the Concept: namespace being editable only by
some user groups (there are extensions for that, I have no further details
here, search the web).
Then #ask queries can only use single concepts and not be used to
Re: [SMW-devel] Hiding some information
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_extensions http://www.mediawiki.org/wiki/Category:Page_specific_user_rights_extensions Even if there would be a way to hide certain SMW properties in the factbox (as its easy to hide them on the page itself) I don't see a straightforward method to hide these data in the page source when the page is edited. Hidding all factboxes via $smwgShowFactbox and restricting editing to admins on those pages doesn't seem very desirable. Gu Quoting Jim Wilson [EMAIL PROTECTED]: I guess another total hack is to name all the private properties similarly and therefore detectably - and then at render time, if the user is an admin, print those, and if the user is not, don't. Assuming you had a way to programmatically determine whether the user has privs to see the info, the next problem to address is caching. MediaWiki caches the rendered versions of pages to save processing from visitor to visitor. -- Jim R. Wilson (jimbojw) On 10/25/07, Asheesh Laroia [EMAIL PROTECTED] wrote: On Thu, 25 Oct 2007, S Page wrote: Asheesh Laroia wrote: Is it possible to hide some attributes so that only admins can see them? From what I know of the code, not easily. When a page is saved, SMW parses its annotations and stores the semantic annotations in tables. There's a smw_attributes table with the page ID, the property name, and its value. No access control at the database level. Yes, you could add a special property Only_for_admins and modify the SMW code to check this before it does anything with a property. SMW 1.0 tends to create a DataValue whenever it deals with a property so the change might be well-encapsulated. HOWEVER, Normally the User:Asheesh_Laroia page would form the subject of both the public Property:Email and the private Property:telephone, so both properties have to be specified on the same page. So how are you going to have a partly-private page in MediaWiki? Are you thinking of having a separate private details page that is somehow tied in with the public page? That makes querying much harder. Maybe you could have a separate namespace for Confidential:Asheesh_Laroia and modify SMW to look up in that as well if the user is an admin. I guess another total hack is to name all the private properties similarly and therefore detectably - and then at render time, if the user is an admin, print those, and if the user is not, don't. What do you [guys] make of that approach? Thanks for the quick and thoughtful reply! -- Asheesh. -- Humans are communications junkies. We just can't get enough. -- Alan Kay - 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 Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel - 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 Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel - 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 Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
