Extension talk:Semantic Internal Objects

Handling of multiple SIOs in #ask template-format

Dear all,

I'm using Semantic Forms and SIO to build a SMW about cultural transfer in 18th century literary journals. A common case is a journal article that refers to foreign books, e.g. an article in a german journal that reviews an english book. Usually, one article refers to several works, so each reference to a work is a SIO in the articles wiki page. The Transfer-template is called multiple times, like this:

{{Transfer
|Page=12
|Work=Hāfez: Dīvān
|Type=Quotation
}}
{{Transfer
|Page=13
|Work=Sir John Shore, European Magazine, Mai 1794.
|Type=Reference
}}

The template is defined as following:

{{#set_internal:transfers
|Page={{{Page|}}}
|Work={{{Work|}}}
|Type={{{Type|}}}
}}

The information about the article itself (author, title, etc.) are stored as semantic properties on the article page. Data about the books the article is referring to are saved in the respective wiki page of the book. The SIO attribute Work is defined as datatype Page.

Article -- Attribute:transfers --> #SIO1 -- Attribute:Work --> Hāfez: Dīvān
        -- Attribute:transfers --> #SIO2 -- Attribute:Work --> European Magazine, Mai 1794.

My aim was to create a query with the result format template that lists both the information about the article and some details about the referred works. To query a property chain, my approach is to use a template including #show-calls which extract the information. Here you see the template call via #ask (for example all articles published between 1796 and 1797):

{{#ask: [[published::>01.01.1796]] [[published::<31.12.1797]]
| ? Author
| ? Title
| ?- Transfers
| format=template
| template=Graph(Work)
| link=none
}}

And the corresponding template Graph(Work) which gets the following parameters: {{{1}}} = page title, {{{2}}}= author of the article, {{{3}}} = title of the article, {{{4}}} = all page title of the SIOs the article refers to via the property Transfers.

{| class="wikitable sortable"
! Autor !! Titel !! Transfer
|-
|[[{{{1}}}|¶]]{{{2}}}
|{{{3}}}
|{{#arraymap:{{{4}}}|,|x|
''Publisher'' {{#show: {{#show:x|?Transfers|link=none}} | ?Publisher}}
''Language'' {{#show: {{#show:x|?Transfers|link=none}} | ?Language}} 
}}
|}

The first column of the table links to the article {{{1}}} via the ¶-sign and list the author {{{2}}}. The second column shows the title {{{3}}}. The third column contains a list of all SIOs {{{4}}}, i.e. works being referred, with the following information: Publisher and Language. This is done via an #arraymap-call that splits the SIO-listing and spreads it on nested #show-queries. The result is a list of small tables with the mentioned informations. So far, so fine. It works very well.

The problem is that it cannot be done with articles whose page titles contains commas, like "Edinburg, d 26 Nov 1796". The list of SIOs then looks like

Edinburg, d 26 Nov 1796#_16596386ac8b7d078a1b3113abbe2b07, 
Edinburg, d 26 Nov 1796#_68e8b29e81b77ccbe5e50b9482934e69

It should be clear that #arraymap will not work anymore like intended. The question now is: Is there a way to set the separator between the SIOs? Can I change it from , to ! or whatever? Furthermore, I can imagine that my approach is not the right way to get the aimed results.

I would appreciate an opinion about this a lot! Sorry for the long topic and thanks in advance, Michael

That is a hack, of course... so let me suggest a smaller hack. When dealing with internal objects (or subobjects - same thing), it's almost always better to query on the internal objects themselves, rather than on the pages. So that's what I would recommend doing. The downside on that is that you unfortunately can't display the pages' own properties (Author, Title, etc.), due to a limitation in #ask. But you can get around that by storing that information in each internal object. You can do that by adding things like "|Article author={{#show:{{PAGENAME}}|?Author}}" to the #set_internal call, and then you can additionally display "? Article author" or whatever you call that property. Would that work for you? Yaron Koren (talk) 13:11, 9 October 2014 (UTC)

Cool! Thanks so much for your quick response, Yaron. Your small hack works very fine for me!

Unique ID of Internal Objects

It seems that an internal object's random number is changed every time the value of an internal object's property has been modified. Thus you can not use the automatically-generated name as an unique identifier over time. Is there a way to create a unique ID like with the old numbering mechanism? --Planetenxin (talk) 11:14, 3 December 2014 (UTC)

That's true, although a simple numbering system won't always work as a unique identifier either, because it won't handle things correctly if the items get rearranged. Anyway, I think you can use the NumerAlpha extension for that, storing the value with a hidden property. Yaron Koren (talk) 16:36, 3 December 2014 (UTC)

Compatibility with SMW 4.0

I have the following install on a private wiki:

MediaWiki 1.37.1 Semantic MediaWiki 4.0.0 PHP 7.4.27 (fpm-fcgi)

Whenever I add the following install code for Semantic Internal Objects into my localsettings (I have checked the extension has been added to my extensions folder):

include_once "$IP/extensions/SemanticInternalObjects/SemanticInternalObjects.php" ;

it blanks my site (as in, nothing loads, it just brings up a blank white page on any page in my wiki).

Am I missing something? Thank you

you need to debug https://www.mediawiki.org/wiki/Manual:How_to_debug

I'm having the same issue

https://www.mediawiki.org/wiki/Manual:How_to_debug

Notice: Undefined variable: smwgDefaultStore in D:\Bitnami\wampstack\apps\mediawiki\extensions\SemanticInternalObjects\SemanticInternalObjects.php on line 34

Fatal error: Uncaught Exception: Not an actual source file in D:\Bitnami\wampstack\apps\mediawiki\extensions\SemanticMediaWiki\includes\IdeAliases.php:15 Stack trace: #0 D:\Bitnami\wampstack\apps\mediawiki\vendor\composer\ClassLoader.php(571): include() #1 D:\Bitnami\wampstack\apps\mediawiki\vendor\composer\ClassLoader.php(428): Composer\Autoload\includeFile() #2 [internal function]: Composer\Autoload\ClassLoader->loadClass() #3 [internal function]: spl_autoload_call() #4 D:\Bitnami\wampstack\apps\mediawiki\extensions\SemanticInternalObjects\SemanticInternalObjects.php(46): class_exists() #5 D:\Bitnami\wampstack\apps\mediawiki\LocalSettings.php(331): include_once('D:\\Bitnami\\wamp...') #6 D:\Bitnami\wampstack\apps\mediawiki\includes\Setup.php(143): require_once('D:\\Bitnami\\wamp...') #7 D:\Bitnami\wampstack\apps\mediawiki\includes\WebStart.php(89): require_once('D:\\Bitnami\\wamp...') #8 D:\Bitnami\wampstack\apps\mediawiki\index.php(44): require('D:\\Bitnami\\wamp...') #9 {main} thrown in D:\Bitnami\wampstack\apps\mediawiki\extensions\SemanticMediaWiki\includes\IdeAliases.php on line 15

Plegault3397 (talk) 12:54, 8 February 2022 (UTC)

I got the same error 72.68.49.235 21:24, 17 February 2022 (UTC)

Same here. Redheadkelly (talk) 20:14, 28 April 2022 (UTC)

If you are using SMW, the functionality of Semantic Internal Objects is included in SMW, there is no real need to use SIO anymore.

See:

- https://www.semantic-mediawiki.org/wiki/Help:Adding_subobjects

- https://www.semantic-mediawiki.org/wiki/Help:Subobjects_and_queries

- https://www.semantic-mediawiki.org/wiki/Help:Recurring_events

Felipe (talk) 05:39, 29 April 2022 (UTC)