Extension talk:Semantic Internal Objects

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)

Link to pagename in query results
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)


 * 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)


 * 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)

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)


 * 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)

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)


 * Yeah - usually within a day or so. Yaron Koren 04:46, 11 January 2010 (UTC)


 * Ah I see. Well thank you very much for your help. --128.54.162.143 05:27, 11 January 2010 (UTC)


 * 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)

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)


 * 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)


 * Wow, that was fast. Great work, thanks! --Thai 20:56, 10 February 2010 (UTC)

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)
 * thanks. After I define Property page, it works.

Incorrect link to pagename in query results
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'

Create another page with the following query.

which yields the following

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)

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)

internal object is inserted repeatedly
I have a query in a page to display the internal object like this 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:

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)
 * I think I found the problem. I have an section in semantic form like this

Gender: my VariableGender template is like this

When the semantic form is submitted, the page contains

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)


 * 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)
 * 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)
 * 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)

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)

Extension credits
Please change the Extension credits to thanks ;) --DaSch


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

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:

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


 * 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)


 * I am using version 0.4. Is there a log I may turn on? --Even Thorbergsen 11:22, 11 March 2010 (UTC)
 * The problem seems to be related to the "filter part" of the #ask statement.--Even Thorbergsen 11:32, 11 March 2010 (UTC)

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

Page 1:

Page 2:

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

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)


 * 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)

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:

Has cooking method::Baking

And my gravy recipe would include:

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)


 * 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:

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)


 * 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)

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)


 * No change is necessary for SMW 1.5+ - I just changed the wording to reflect that. Yaron Koren 20:18, 13 April 2010 (UTC)


 * I knew it. At least that was what I had wished for. Thank you and Cheers --kgh 20:41, 13 April 2010 (UTC)

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:

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


 * 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)

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:

I can employ an arraymap:

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)
 * I can fix this by forcing the property:


 * 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)


 * 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)

Semantic Internal Objects joined with normal attributes
I use Semantic Internal Objects to store some information just like

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

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)


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

|GENDER=

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

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

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

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)

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)
 * 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)
 * 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)
 * I am using SMW 1.5.1.1


 * Ah - I think that's it, then. Yaron Koren 10:08, 19 September 2010 (UTC)

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:

... ...

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
 * A list of all packages (potentially from different distributions) that provide a specific version of a specific component

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)


 * 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)


 * 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)


 * 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)

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)


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

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)


 * 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)