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

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)

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)