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)

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.

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)