Jump to content

Extension talk:Semantic Internal Objects/Archive 2009 to 2010

From mediawiki.org

Internal objects and redirects

If you have an article with internal object definitions and a redirect onto that article, then internal objects are created for both the article and the redirect. Hence querying the internal object will then produce hits for the article and for the redirect. (Makes for magic doubling of project manpower. :-) ) --F.trott 14:34, 7 September 2009 (UTC)Reply

I use #ask with mainlabel=- to query internal objects and suppress the meaningless main column. The column with the name of the semantic relation contains page names (in my case with a namespace prefix), but without links to the pages. Can this be activated somehow? --AndreasMangold 16:51, 9 January 2010 (UTC)Reply

My guess is that the property that points to those page names is of type "String", instead of "Page"; and thus that the property's type just needs to be changed - is that right? Yaron Koren 18:39, 10 January 2010 (UTC)Reply
Yes, it is right. Thank you very much for answering my question and for helping me to solve this problem. --AndreasMangold 19:33, 10 January 2010 (UTC)Reply

Need to resave for internal objects to appear

I'm having a problem where a query for the internal objects of a certain property doesn't show objects that have been created after the query or that have been modified. I have to manually resave the page where I am using #ask for the new internal objects or modifications to appear. Any help or insight would be appreciated. Thanks. --128.54.162.143 00:21, 11 January 2010 (UTC)Reply

This is probably just an issue of MediaWiki caching. If you "refresh" the page (i.e., by hitting the "refresh" tab that goes to "action=purge"), you should be able to refresh the query results, without needing to resave anything. Yaron Koren 01:03, 11 January 2010 (UTC)Reply

Ah, you're right. Hitting the refresh tab did make the results appear. If I did not use the refresh tab, would the results eventually show up? --128.54.162.143 04:24, 11 January 2010 (UTC)Reply

Yeah - usually within a day or so. Yaron Koren 04:46, 11 January 2010 (UTC)Reply
Ah I see. Well thank you very much for your help. --128.54.162.143 05:27, 11 January 2010 (UTC)Reply
I had the same problem in my Wiki, its a MW cache problem. I solved it with Extension:MagicNoCache. After installing it, the only modification I had to do is adding __NOCACHE__ to the template. -- 194.140.58.43 14:15, 30 March 2010 (UTC)Reply

Support for text data type?

Properties with data type "text" seem not to work with Semantic Internal Objects (and SMW 1.4.3). The problem disappeared after having changed the data type to "string". Will the "text" data type be supported in the future or are there any mistakes I could have made? --Thai 13:37, 9 February 2010 (UTC)Reply

Ooh, I never thought to test that one... that's a pretty big deal. I just fixed it now, in a new version, 0.3 (which also has a fix for working with SMW 1.5). Thanks for the bug report. Yaron Koren 17:53, 10 February 2010 (UTC)Reply
Wow, that was fast. Great work, thanks! --Thai 20:56, 10 February 2010 (UTC)Reply

data type for property

I query internal object. The value for a property of internal property shows as a red link. It seems that the data type is assumed to be page. How can I set the data type to String?

You should define a page for that property, at "Property:page-name", adding "Has type::String"; just as with SMW. Yaron Koren 14:15, 16 February 2010 (UTC)Reply
thanks. After I define Property page, it works.

I'm having a problem where the link to pagenames in query results is always Object. My test is as follows:

Create a test page with the following wiki text.

This page contains the parser function '#set_internal'
{{#set_internal:Is part of recipe
|Has quantity=1
|Has unit=cup
|Has ingredient=flour
}}

Create another page with the following query.

{{#ask:[[Is part of recipe::+]]
 |mainlabel=-
 |?Is part of recipe
 |?Has quantity
 |?Has unit
}}

which yields the following

Is part of recipe Has quantity Has unit
Object 1 cup

My wiki is using

  • Mediawiki version 1.15.1
  • Semantic Mediawiki 1.5g-SVN (which I believe is the same as 1.4.3.1)
  • Semantic Internal Objects 0.3

Any help would be greatly appreciated.

This was fixed after an email discussion; the problem was solved by upgrading from PHP 5.1.6 to 5.2.10, as strange as that sounds. Yaron Koren 16:05, 17 February 2010 (UTC)Reply

A possible bug

I have an installation which works in one machine, but fails in another machine. In the failing machine, the semantic data is not saved to database. I traced it to this line:

  line 115:$internal_object->addPropertyAndValue( $obj_to_page_prop_name, $parser->getTitle() );

The $parser->getTitle() returns a Title object. The title object is passed to SemanticMediawiki. In the line 78 of SemanticMediawiki/includes/SM_DV_WikiPage.php and line 101 of SemanticMediawiki/includes/SM_DataValue.php, a string instead of an object is expected. PHP throws error in one of machines and works in another machine. If I change "$parser->getTitle()" to "$parser->getTitle()->getText()", it works in all cases.

Ah - that might be the cause of the bug above this one! Great catch, thanks - I'll fix this in the next version of SIO. Yaron Koren 14:44, 18 February 2010 (UTC)Reply

internal object is inserted repeatedly

I have a query in a page to display the internal object like this

 {{#ask: [[is one of study phase::{{PAGENAME}}]]|mainlabel=-|?Study phase name=Name|?Study phase order=Order|?Has a duration unit=Duration}}

I found the internal object is reinserted in database each time I reload the page. So the first time, the query returns one result. If I reload the page one more time, the query returns two identical results. I checked the database. It is indeed inserted two times.

If I have the query in a separate page like this:

 {{#ask: [[is one of study phase::XXX]]|mainlabel=-|?Study phase name=Name|?Study phase order=Order|?Has a duration unit=Duration}}

the object is not re-inserted.

I couldn't reproduce that - what versions of SIO and SMW are you using? Yaron Koren 16:27, 19 February 2010 (UTC)Reply
I think I found the problem. I have an section in semantic form like this

 {{{for template|VariableGender}}}
  {{{field|Varname|default=gender|hidden}}}{{{field|Varunit|default=none|hidden}}}
   Gender: {{{field|Varvalue|input type=listbox|property=Gender is|list}}}
  {{{end template}}}

my VariableGender template is like this


<includeonly>{{#set_internal:is one of study variable
|Study variable name={{{Varname|}}}
|Study variable value={{{Varvalue|}}}
|Study variable unit={{{Varunit|}}}
}}</includeonly>

When the semantic form is submitted, the page contains


{{VariableGender
|Varname=gender
|Varvalue=M
|Varunit=none
}}

So each time, the page is loaded, the template is called and the internal object is reinserted into database. Apparently, this is not a bug in Semantic Internal Object, but how can I use Semantic Internal Object together with Semantic Form to store values?

thanks

You seem to be using SIO and Semantic Forms in the standard way. It should work fine, as far as I can tell... what versions of SIO and SMW are you using? Yaron Koren 19:28, 19 February 2010 (UTC)Reply
I use semantic bundle 0.3.1.20100203. By the way, it seems to me that the set_internal is called when the page including a template with this set_internal? How can you distinguish this is regular display action instead of a save action?
I made a workaround for this. I add a hook to ArticleSave which set SIOHandler::$update=true. SIOHandler::Updatedata only do update when this value is true. At least, it eliminates the reinsertion problem. Is this approach ok? Does it have other implication?
I'm sorry, I simply don't understand the issue. Is there any way you can reproduce it on, say, http://scratchpad.referata.com ? Yaron Koren 17:47, 24 February 2010 (UTC)Reply
I could not reproduce it in the scratchpad. Try it at a later time.

I'm having a similar as above. When I save a page with the set_intervals. The page that is calling it has multiple entries. I can't quite tell if you solved it above. Any help would be much appreciation. Thanks! Update: So it happens on every save but occasionally if I immediately re-save it and refresh the page with the dupe values, it disappears. That's all I have so far.

Does that happen to you with version 0.4 of SIO? (Assuming you can upgrade.) Yaron Koren 16:41, 9 March 2010 (UTC)Reply
Let me try it. Thanks.
I upgraded to 0.4 and so far it hasn't happened. I'll keep you posted and thanks for your help.
Even with 0.4, I still have this problem. Here is the patch I applied to 0.4 to solve the issue
diff SemanticInternalObjects/SemanticInternalObjects_body.php tmp1/SemanticInternalObjects/SemanticInternalObjects_body.php
113d112
<       static $update=false;
154,158d152
<               if (!self::$update)
<               {
<                       //self::$internal_objects = array();
<                       return true;
<               }
diff SemanticInternalObjects/SemanticInternalObjects.php tmp1/SemanticInternalObjects/SemanticInternalObjects.php
27d26
< $wgHooks['ArticleSave'][] = 'setUpdateMark';
33,40d31
<
< function setUpdateMark( &$article, &$sectionanchor, &$extraq )
< {
<
<       SIOHandler::$update=true;
<       return true;
<
< }

Same problem here

Same problem for me. The items are inserted repeatedly into the query which gets gradually longer with time. Then even if the #set_internal entries are deleted completely, most of the query results remain (even after a purge of both the query page and the pages queried). To deal with some of the possibilities already addressed, I have no forms, and have a vanilla version of current MW 1.15 with monobook and the current Semantic Bundle. I now have a long list of about 30 rows in query output even after all three of the #set-internal entries are deleted.

Adding a new ask query in a new page generates the same table.

Removing SOI addin retains the table

- AB

Followup: I tried to uninstall each of my extensions in turn and also tried to update SIO. The replicating of the SIO entries in the database (and #ask queries) seems on my wiki at least to be related to the presence of the [Cite] extension with version 0.2 of SIO. Upgrading to 0.4 seems so far to have solved the problem. Retracted - the problem is still there with SOI 0.4 and without any extensions apart from Semantic Bundle.

I see from the link below (vectorbase wiki) and does have the problem and also uses version 0.4.

Me too

I also have this problem. It has stopped me from using this otherwise fantastic extension, so I hope there is a fix soon. Also as above, the long list of entries remains even after removing the #set_internals.

JG, 9 April 2010

Here is an example of this type of replication (albeit not the infinitely extending variety): http://wiki.vectorbase.org/index.php/Scratch_pad

Another One

Yeah, I was just flumoxed when this started happening. It's sporadic. Sometimes my queries result with two identical results, as if there are two identical lines in the database. Is the above fix going to be added to a new version?

Douglas, 19 July 2010
This was fixed in version 0.6, so if you upgrade to that one you should be flummoxed no more. Yaron Koren 18:08, 19 July 2010 (UTC)Reply

Well, with the new version, saving the page fixes the repeat entries, but every time I refresh the page causes another copy to be saved to the database up to, I imagine, infinity. Navigating my website has become a little... scary. Any ideas?

That sounds bad. Please send me a private email with the full list of extensions (and their versions) that you're using, plus your version of MediaWiki - my guess is that it's due to the interplay of SIO and something else. Yaron Koren 13:44, 2 August 2010 (UTC)Reply

I take it this is still broken? I saw some duplication fixes listed for 0.6.1, which I was running, but I still saw duplicate data. I'm now using SIO 0.6.3, along with MW 1.16.0, PHP 5.3.2-1, MySQL 5.1.41-3, SF 2.0.1, and SM 1.5.2, and still have the duplicates. --Trueskew 00:20, 11 December 2010 (UTC)Reply

Upgrading unfortunately won't remove duplicates - it will just (hopefully) prevent new duplicates from being formed. You'll have to get ride of the duplicates manually, sadly. Yaron Koren 03:56, 12 December 2010 (UTC)Reply

Extension credits

Please change the Extension credits to

$wgExtensionCredits['parserhook'][] = array(
	'path' => __FILE__,
	'name'	=> 'Semantic Internal Objects',
	'version'	=> SIO_VERSION,
	'author'	=> 'Yaron Koren',
	'url'	=> 'http://www.mediawiki.org/wiki/Extension:Semantic_Internal_Objects',
	'descriptionmsg' => 'semanticinternalobjects-desc',
);

thanks ;) --DaSch

That 'path' line has been added in version 0.4. Yaron Koren 16:42, 9 March 2010 (UTC)Reply

Two-word property names required?

I have tested this extension using single- and two-word property names, but only two-word names seem to work. All examples I have seen use the English Has as the first word, but any first word seems to function as well:

{{#set_internal:noe
|H mengde=1
|Tar enhet=Kopp
|Has ingrediens=Mel
}}

{{#ask:[[noe::+]][[Has ingrediens::Mel]][[Tar enhet::Kopp]][[H mengde::>.5]]
|mainlabel=-
|? noe
|? H Mengde
|? Tar enhet
|? Has ingrediens
}}

Why can't we use single-word property names?--Even Thorbergsen 23:10, 9 March 2010 (UTC)Reply

This problem doesn't happen for me - I just tested it. What version of SIO are you using? Yaron Koren 23:17, 9 March 2010 (UTC)Reply
I am using version 0.4. Is there a log I may turn on? --Even Thorbergsen 11:22, 11 March 2010 (UTC)Reply
The problem seems to be related to the "filter part" of the #ask statement.--Even Thorbergsen 11:32, 11 March 2010 (UTC)Reply

Follow-up: Shouldn't this generate an output? It does not so for me:

Page 1:
{{#set_internal:noe
|enhet=kopp
}}

Page 2:
{{#ask:[[noe::+]][[enhet::kopp]]
|mainlabel=-
|? enhet
}}

--Even Thorbergsen 23:05, 18 March 2010 (UTC)Reply

RDF Export

Hi, I was wondering if there has been any progress on getting RDF Export functionality working. If not, I'm wondering if you could provide me with more information as to what needs to be udpated in SemanticMediaWiki to allow for this functionality, as maybe I might be able to help in writing a patch. --Joshuagay 11:50, 24 March 2010 (UTC)Reply

Hi, unfortunately no progress. Unfortunately, it's not as easy as adding a hook - see here. But it's probably worth bringing this up again on the mailing list. Yaron Koren 15:17, 24 March 2010 (UTC)Reply

Is this sort of query possible?

And if so, how would you write it?

Continuing the recipe example, say each recipe page contains one or more instances of the internal object "Is part of recipe," and a simple property for the recipe "Has cooking method."

So my carrot cake recipe would include:

{{#set_internal:Is part of recipe
|Has quantity=1
|Has unit=cup
|Has ingredient=flour
}}

[[Has cooking method::Baking]]

And my gravy recipe would include:

{{#set_internal:Is part of recipe
|Has quantity=2
|Has unit=tablespoon
|Has ingredient=flour
}}

[[Has cooking method::Sautee]]

Is there a way to query for all recipe pages that both the following, and thus return the Gravy recipe?

[[Has ingredient::flour]]
[[Has cooking method::!Baking]]

Or to just return all recipe pages that [[Has ingredient::flour]] and show the value of those pages' "Has cooking method" property in the results?

I can't figure out if I'm completely missing something simple or this just isn't possible.

Thanks!

Yes, it's possible - the basic query you should be using is "[[Has ingredient::flour]] [[Is part of recipe.Has cooking method::!Baking]]". Yaron Koren 13:52, 28 March 2010 (UTC)Reply
Is it possible to use this sort of query with a category? In this case there would by a category called "Baking". So i tried:
[[Category:Baking]] [[Has ingredient::flour]]
and got no result. I also tried
[[Has ingredient::flour]] [[Is part of recipe.Category:Baking]] 
without any results. --217.194.34.103 11:44, 8 June 2010 (UTC)Reply
I don't think you can do linked queries with categories, unfortunately - you'll have to use just semantic properties. Yaron Koren 15:07, 8 June 2010 (UTC)Reply

Adjustments to SMW_SQLStore2.php

Hi Yaron, the section to be changed has vanished in SMW 1.5.0. Is this good or bad? Cheers --kgh 18:58, 13 April 2010 (UTC)Reply

No change is necessary for SMW 1.5+ - I just changed the wording to reflect that. Yaron Koren 20:18, 13 April 2010 (UTC)Reply
I knew it. At least that was what I had wished for. Thank you and Cheers --kgh 20:41, 13 April 2010 (UTC)Reply

Semantic internal objects in templates

Despite not having seen any examples of it, I have tried to put semantic internal objects inside templates, using parameters, both numbered and named, to give values to the properties:

{{#set_internal:object_to_page_property
|property1={{{1}}}
|property2={{{2}}}
}}

It seems I cannot make this behave consistently. Can I expect this to work as intended? --Even Thorbergsen 22:27, 26 April 2010 (UTC)Reply

Yes, that should work; and that's usually how semantic internal objects are defined (i.e., within templates). Yaron Koren 12:10, 27 April 2010 (UTC)Reply

property#list and checkboxes

I use a property with a domain limited to 5 values. In the previous solution without SIO Semantic Forms would display 5 checkboxes for this property. With the SIO solution now I cannot get the same behaviour to work easily. Instead by default I get a input field. See http://img230.imageshack.us/img230/148/internalobject.png as a reference. I would like to have "Locale" use checkboxes, similar to "CharacterDomain".

Definition is as follows:

 {{#set_internal:Glyph
 [...]
 |Locale#list={{{Locale|}}}
 }}

I can employ an arraymap:

 {{#arraymap:{{{Locale|}}}|,|x|[[Locale::x]]}}

This shows checkboxes but attaches the property to the main page object and also messes up the system as that this internal object isn't found on queries. Is there a proper way to go? --Christoph Burgmer 10:53, 13 May 2010 (UTC)Reply

I can fix this by forcing the property:
 {{{field|Locale|list|property=Locale}}}
Is that a bug in SF, or does SIO not map the property with "#list" to the correct property? --Christoph Burgmer 13:57, 13 May 2010 (UTC)Reply
Great - yes, that's the right solution. Yes, you could call it a bug in SF - there's no way SF will always be able to associate a template field with the right property, but hopefully it'll be able to parse #set_internal at some point. Yaron Koren 15:54, 13 May 2010 (UTC)Reply

Semantic Internal Objects joined with normal attributes

I use Semantic Internal Objects to store some information just like

{{#set_internal:guild_member
|GUILDNAME=The Example Guild
|GUILDMEMBER=John Doe
|GUILDRANKING=Ensign
}}

I also have a Wikipage for John Doe with some information like

{{#set:sex=male}}

Now i'd like to join these information: show all members of the guild and show their sex.

GUILDNAME          | GUILDMEMBER | GUILDRANKING | SEX 
--------------------------------------------------------
The Example Guild  | John Doe    | Ensign       | male
The Example Guild  | Jane Doe    | Ensign       | female

Is it possible to make an ask-query of this kind?

--217.194.34.103 07:46, 5 July 2010 (UTC)Reply

Not directly - queries can't display chained/linked properties. However you could probably do it by adding a line to #set_internal like:

|GENDER={{#show:John Doe|?sex}}

Yaron Koren 20:56, 5 July 2010 (UTC)Reply

Hi, It'd be really great if SIO queries could support chained properties. Is there any possibility this could be put onto the schedule? I guess the above could be coded as

{{#ask:[[GUILDMEMBER::+]]|mainlabel=-|format=table
 |?GUILDNAME |?GUILDMEMBER |?GUILDRANKING |?GUILDMEMBER.GENDER=GENDER}}

and to chain from the 'subject' of the internal object, a special property could be used, eg

{{#ask:[[GUILDMEMBER::+]]|mainlabel=-|format=table
 |?GUILDNAME |?SIO Subject |?SIO Subject.SOMEATTRIBUTE=Some attribute}}

Thanks.

Hi - there's no such thing as "SIO queries"; SIO just sets data. Those are regular SMW queries, so this would be an SMW feature request. Yaron Koren 04:11, 29 September 2010 (UTC)Reply

Version 0.6 does not store internal property

I use the most recent semantic bundle. MW:1.15.1, SMW:1.5.1.1, SIO:0.6. set_internal does not save any internal property. I add error_log. I found the set_internal actually save the properties, but it deleted them immediately. Here is a log after a form with semantic internal object is saved.

[23-Jul-2010 15:46:34] execution comes to updateData                                                                                        
[23-Jul-2010 15:46:34] SIO deleting Array                                                                                                   
(                                                                                                                                           
    [0] => 108                                                                                                                              
    [1] => 109                                                                                                                              
    [2] => 110                                                                                                                              
)

[23-Jul-2010 15:46:34] insert rel
[23-Jul-2010 15:46:34] insert atts Array
(
    [0] => Array
        (
            [s_id] => 108
            [p_id] => 54
            [value_unit] =>
            [value_xsd] => aaaaaa
            [value_num] => aaaaaa
        )

    [1] => Array
        (
            [s_id] => 108
            [p_id] => 56
            [value_unit] =>
            [value_xsd] => 80
            [value_num] => 80
        )

    [2] => Array
        (
            [s_id] => 108
            [p_id] => 59
            [value_unit] =>
            [value_xsd] => 1
            [value_num] => 1
        )

)

[23-Jul-2010 15:46:34] execution comes to updateData
[23-Jul-2010 15:46:34] SIO deleting Array
(
    [0] => 108
    [1] => 109
    [2] => 110
)

You see here the updateData is called two times. The first time, old internal objects are deleted and internal object 108 are saved. The second time, it was deleted again.

I've never heard of that happening... is this a public wiki? If not, could you possibly list all the extensions you're using? I suspect that one of the other extensions is interfering with SIO's normal operations. Yaron Koren 01:40, 25 July 2010 (UTC)Reply
Sorry, I removed my installation and used an old one. I just downloaded and used the most recent semantic bundle:http://semantic-mediawiki-bundle.googlecode.com/files/SemanticBundle-20100719.zip
...and? Yaron Koren 03:07, 28 July 2010 (UTC)Reply
My old installation(SIO 0.4) has the "repeated insertion" problem. I applied the patch in section 8. It had some problem. But it worked.
Saw this one more time. Reinstalled the whole mediawiki +Semantic bundle 20100719, but can not repeat this problem anymore.

Semantic Internal Object are not saved when the page is first created

I have a form which will create the page and its associated semantic internal objects. When I use the form to create page, semantic internal object is not saved in the very first time. That is the first time when the page is created. I verified this by looking into database. After the page is created, update/deletion/insertion work well. I use SIO 0.6

This is a known bug for versions of SMW before 1.5.2 - what version of SMW are you using? Yaron Koren 14:58, 16 September 2010 (UTC)Reply
I am using SMW 1.5.1.1
Ah - I think that's it, then. Yaron Koren 10:08, 19 September 2010 (UTC)Reply

SIO with properties of type Record

Is it possible to use properties of type Record with SIO? I tried (see below), but it didn't work.

Use case:

Pages representing a distribution each define multiple packages using SIO:

...
 {{#set_internal:is part of
 |is a=package
 |has name=Package1
 |provides component#list=ComponentA;0.8, ComponentB;2.0.1, ComponentC;1.5.0
 }}
 ...

ComponentA, ComponentB and ComponentC are existing pages. The Property:Provides component page includes:

 [[has type::record]]
 [[has fields::Page; String]]

Two lists are of interest:

  • A list of all packages (potentially from different distributions) that provide a specific component
{{#ask:[[is a::package]][[provides component::ComponentA;?]] |? provided by |? has name |mainlabel=-}}
  • A list of all packages (potentially from different distributions) that provide a specific version of a specific component
{{#ask:[[is a::package]][[provides component::ComponentA;0.8]] |? provided by |? has name |mainlabel=-}}

However, this does not work - MediaWiki refuses to save the distribution pages if set_internal calls like the one above are added.

Hi - it's true that SIO doesn't support properties of type Record, though it could in theory. I didn't think there was a need for it, though I hadn't thought of a case like yours - you're essentially trying to store a three-dimensional array of data in a single page. Perhaps there's some convenient way to split this into a more manageable format, which would also make editing easier? One obvious possibility is to make a separate page for each package... Yaron Koren 22:46, 26 September 2010 (UTC)Reply
Hi, thanks for the reply. Yes, I have thought about alternatives, but "one page per package" would not be manageable at all in this case. Multiple packages might have the same name - but be part of different distributions, or different repositories within the same distribution, or even just differ by their version number or build architecture (I omitted these and other additional properties from the #set_internal snippet above for readability). So this is definitely a use-case where anonymous objects such as provided by SIO make a lot of sense.
Also, this whole distribution packages thing is only supposed to be a peripheral feature of the wiki (the component pages are the actual "main" content), so even without the naming complications, having a separate page for each package would just be overkill. All in all, having a user-friendly template that - using a #set_internal call like the one above - can specify packages from within the distribution pages they belong to, really would be the ideal, most manageable solution here.
If there are no plans of supporting Record properties in SIO, I'd rather find a work-around that doesn't need records, rather than abandoning SIO... :-)
(Since the work-around would be hidden away inside a template anyways, it wouldn't be a problem if it's messy or complicated... Suggestions are welcome... :-)
--Zas 16:14, 28 September 2010 (UTC)Reply
Well, if naming of packages is a problem, and if you're using Semantic Forms, you could have the forms themselves give each package a guaranteed unique name, using a page-name formula - it's another option.... Yaron Koren 19:35, 28 September 2010 (UTC)Reply
Ok, I'll look into that. One other issue with this approach I can think of, though, is that removing packages will require admin intervention.
Well, not entirely: regular users could just blank the page, which achieves basically the same result as deleting it. Yaron Koren 13:23, 29 September 2010 (UTC)Reply

Comma separated list values

Hi I am having trouble storing a list of values that do contain a comma. Is there any workaround for this? Thanks --Hypergrove 16:40, 14 October 2010 (UTC)Reply

Do you mean, "do not"? Yaron Koren 17:39, 14 October 2010 (UTC)Reply

Internal objects that won't disappear

I've got some internal objects that still appear in queries even though the page that they were on has been deleted. I've tried recreating and redeleting the page, running refreshLinks and refreshData, but the objects are still there. I'm happy to delete them manually from the mysql tables -- any tips on which records to delete? - Borofkin 04:38, 21 October 2010 (UTC)Reply

That sounds bad - I hope those records were created by a version of SIO older than the current one. Anyway, you should be able to get rid of them by going into the "smw_ids" table, looking for any row whose value of 'smw_title' contains a #, and deleting the offending rows. Yaron Koren 19:48, 21 October 2010 (UTC)Reply
I'm using Semantic Bundle 0.4.2.20101001, installed two days ago. I'll have a crack at deleting the offending records, then see if I can reproduce the problem. - Borofkin 22:01, 21 October 2010 (UTC)Reply
I haven't pinned this one down yet, but it seems to be caused by renaming articles that contain templates that contain internal objects. What is the expected behaviour when an article is renamed? - Borofkin 00:30, 1 November 2010 (UTC)Reply
Oh, that's interesting. The expected behavior, of course, is that it works correctly. :) I'll try that one out. Yaron Koren 02:12, 1 November 2010 (UTC)Reply
Well, I just tried it out, and it works fine for me, alas. Yaron Koren 02:33, 1 November 2010 (UTC)Reply
This was indeed a bug - I think it's fixed now in the new version, 0.6.2. If you get the new version, and then resave all the relevant pages (the old redirect pages and the new ones), I think everything should work... Yaron Koren 13:34, 5 November 2010 (UTC)Reply

Success and Advice

I had tons of problems with this extension until I upgraded all the associated software to the newest release and updated the tables. Then it worked splendidly. I just want to say that, considering what this software achieves, I should have expected there to be version issues. It really is a remarkable achievement!

Thanks Yaron!

That's really great to hear. I'm not completely convinced that SIO is bug-free yet (see above), but I think it's definitely getting better from version to version. Yaron Koren 16:21, 26 October 2010 (UTC)Reply

SIO and Semantic Tasks

There is a (short) discussion at Extension talk:Semantic Tasks about using Semantic Tasks with SIO's. Is there any possibility of Semantic Tasks being changed to support SIO's in the future? - Borofkin 04:34, 12 November 2010 (UTC)Reply

Thanks for letting me know - I responded there. Yaron Koren 00:31, 13 November 2010 (UTC)Reply

Combining Categories with Properties

Finally managed to create a form with a list of Authors (Users) that is chained to the corresponding page with a SIO and displaying correctly in my template. This brings up the next task: Chaining SIO queries together with specific Categories to narrow searches down with ease. The following questions arise:

  • What would be the best way to generate a property list of existing Wiki content categories?
  • How can i make sure that the a Property "Category::" is linked correctly to the corresponding "Wiki-Category"?

My first thought would be:

  1. Create a property "HasCategory" (for SIO) and a property "Category" (for use in Forms, Templates)
  2. Chain my Pages together with a SIO definition in the page template.
Sorry, I don't really understand - but this might be the sort of free-form question that's better suited for the SMW mailing list. Yaron Koren 15:19, 26 November 2010 (UTC)Reply