Extension talk:Semantic Internal Objects

Property type for the 'first argument'?
The first argument, "a property pointing from the object, to the page", is a property like any other in the wiki. What property type should it be? By default it's page, which means it's values are links to non-existent pages. Should it be changed to string? Does the setting have any effect? It's a bit confusing, so perhaps some recommendation should be made on the page. Cheers, --Dan Bolser 14:06, 14 January 2012 (UTC)
 * Could we even consider a special type for the property? i.e. by default it could be a property of type SIO or something? --Dan Bolser 14:07, 14 January 2012 (UTC)


 * It should just be a property of type "page". The documentation could probably be clearer about that. Yaron Koren 05:30, 15 January 2012 (UTC)

Semantic Mediawiki 1.7
Hello,

I saw that the 1.7 version of Semantic Mediawiki includes SIO natively through the #subobject perser function. Does it have all the same functionalities and query syntax ? Regarding bugs, which version of SIO got into SMW ?


 * Actually, what's included isn't SIO, but similar functionality. That's a good question, though - I just added a section to the documentation that tries to explain this; hopefully it makes sense. Yaron Koren 13:54, 20 January 2012 (UTC)

set_internal_recurring_event, unit=year
I want to do

but all instances are on the same date. The same behaviour for unit=month, but unit=day and unit=week behave as expected. What is wrong? I use Semantic Internal Objects (Versie 0.6.8), Semantic MediaWiki (Versie 1.7.1) and MediaWiki (Versie 1.18.1) --Egel (talk) 22:40, 23 March 2012 (UTC)


 * That's pretty bad - this turned out to be a bug in Semantic MediaWiki itself, since January. I just fixed it in SVN. If you don't have SVN, you can duplicate the fix yourself, here. Yaron Koren (talk) 15:02, 25 March 2012 (UTC)


 * Hello, I still have problems setting recurring events with Internal Objects (Versie 0.6.8), Semantic MediaWiki (Versie 1.7.1). What I see is that when I run the query the event as not repeated, while if I just use #set_recurring_event everything works normally. This happens with the same example reported in the wiki page. Does anybody have a clue? I am quite newbie so I could be missing something obvious. Paolo


 * Is this happening on a public wiki? If not, could you try to reproduce it on scratchpad.referata.com? Yaron Koren (talk) 02:21, 22 May 2012 (UTC)


 * Hi Yaron. Thank you for the reply. The wiki is not public yet. I tried to reproduce the problem here.
 * Ok, I fixed the problem. There was a php error when running the database update. I saw it enabling error_reporting( E_ALL ); ini_set( 'display_errors', 1 ); in the LocalSettings.php file. However I have another issue: when I ask for a property based on its value, the query returns all the pages containing that property, watever value is specified. I saw that on on scratchpad.referata.com it is the same. Is this related with the InternalOnject extension? (I fixed this by defining the property of type string and adding '~' to the query) Paolo

Using set_internal_recurring_events for date ranges
Dear Yaron. There are at least two different types of date ranges that are standard fare in historical research:


 * 1. (c.) A – (c.) B: meaning that something, e.g. a war or a person’s floruit, lasted from (circa) start date A to (circa) start date B
 * 2. A x B: meaning that something took place sometime between A (terminus post quem) and B (terminus ante quem).

I presume that SIO storage and querying can be used for a continuum like #1, although it's not an actual continuum in semantic terms and approximate dates can be tricky, and probably #2, as long as it’s clear that searching for matches in a given date range can only produce tentative results.

The main problem I had is that the span of such a range can be well over a century. If I understand things correctly, SIO would then store a value for every day that falls within the range until a maximum is reached, at the risk of overloading the database. That doesn’t seem to me like a very efficient way of handling date ranges.

Do you have suggestions or know of any alternative approaches? Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 22:55, 21 May 2012 (UTC)


 * Hi - yes, indeed that's not efficient; I wouldn't use recurring events for historical stuff. Can't you just store a start date and end date (pretending that these are exact dates, and not just "circa"), and then query on those? Yaron Koren (talk) 02:23, 22 May 2012 (UTC)


 * Well, the main objection to that approach would be that a query could be skipping over relevant data. For instance, if you need to query on organisations that were active between 1920 and 1950, but one organisation was founded in 1910 and discontinued in 1960, it will not be included in your results. I know you can keep overload to a minimum by changing the unit in SIO from "day" to "year" or even 20 years (unit=year, period=20). Since these are ad hoc solutions that could work in certain situations but not in others, maybe the safest solutions is to restrict the possible date ranges that are used in queries in advance and use that as the basis for a SIO storage plan. So if you decide beforehand that for certain data, queried ranges should not be below 20 years, it would be enough to create intervals of 20 years (in the example above, you would get 1910, 1930, 1950 and 1960). It may not be an ideal solution and won’t work for calendar and eventline outputs, but it should be feasible. Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 13:51, 22 May 2012 (UTC)


 * I still think you could do it with just queries. In your case, I'm not sure whether you mean organizations that were active in any year between 1920 and 1950, or all the years. If it's the first one, you could query on (start date <= 1950 AND end date >= 1920), while if it's the second one, you could query on (start date <= 1920 AND end date >= 1950). Yaron Koren (talk) 14:23, 22 May 2012 (UTC)


 * Thanks, I hadn't thought of using comparators like that (obvious as it may seem to you)! Yes, I did mean any year and it works as expected. The only mystery now remaining is that values of date-type properties get subtracted, e.g. "1500" is stored as "1499", but I guess that's for a different forum. Cavila MW 1.17, MySQL 5.5.16, Php 5.3.8 23:45, 22 May 2012 (UTC)
 * FYI: Filed as bug 37038 Cavila MW 1.17, MySQL 5.5.23, Php 5.3.10, SMW 1.7.1 07:17, 23 May 2012 (UTC)