Last modified: 2012-10-18 11:19:04 UTC
I have tried to extend SemanticMediaWiki with additional geographical shapes as semantic properties. (this has been done in the branch 'polygons') A polygon property consists of many coordinate properties. This is a more advanced structure than previously defined. Storing the data seems to work fine, however reading the data doesn't go as well. I seem to have isolated the issue to the method getProperyValues in the class SqlStubSemanticData. Here it seems that there is some kind of mixup going on when i have defined a container to hold coordinates. According to the code it seems that it tries to fetch a given array entry with the key of the property in mStubPropVals. So if i have defined the property "Polygon" that is of type _gpo (Graphical Polygon), this type holds a list of _geo properties which is also defined as a semantic property "Coordinates" However, when this instance of Property is loaded in SqlStubSemanticData, i can see that the mStubPropVals is populated with a key of "Coordinates" when it is looking for a key "Polygon". This issue prevents me to go forward with my geographical shapes properties. Would be great if someone with a greater understanding of the database abstraction layer could take a look at this. Steps to reproduce issue: 1. Checkout polygons branch 2. Create a property of type [[Has type::Geographic polygon]] 3. Create a page with polygon property (ex. [[Polygon::34,24:33,22:64,22]]) 4. Create an ask query. something along the lines of: {{#ask: [[Category:Polygon]] | ?Polygon | format=table }} 5. Put a breakpoint in SqlStubSemanticData in the method getProperyValues and look at how the polygon data is attempted to be loaded.
This fixes the bug in getPropertyValues(), but doesn't achieve the required task (maybe) if ( $propertyDiId == SMWDataItem::TYPE_CONTAINER || $propertyDiId == SMWDataItem::TYPE_GEOPOL )
Part of this might be a documentation issue, and part of the internal behaviour also changed on master recently. So let me briefly explain how containers work now. Containers are "virtual" data items that are merely wrappers for a number of property-value assignments that they contain. The DIContainer class only exists to allow many annotations to be packaged into one value for interfaces that expect a single value (e.g., the result of parsing user input should be one value). However, once the DIContainer is passed to an SMWSemanticData object, it gets decomposed immediately: the subject DIWikiPage of the container will be used as the property value, the remaining annotations about the subject get stored separately as "subsemanticdata". If you store more than one container with the same subject, then the data about this subject will be merged. This has always been happening more or less implicitly in the database, but until recently it had not been happening in SMWSemanticData right away. As it now is, no SMWSemanticData can ever hold a DIContainer value -- you can give one to it but it is the same as if you had used the subject and added the subsemanticdata directly (there are methods for this now). Now when you query for the data of a page, the store will only fetch its actual property values, not the property values of its subobjects. Thus, you will see the DIWikiPage (subject) but not the subsemanticdata (the rest of the container). To get this data, you need to call getSemanticData() for the subject DIWikiPage. Maybe this information already allows you to solve your problem (together with the recent code).
P.S. Unless you want to access individual coordinates in the database (e.g., find all polygons that have a coordinate with latitude 12.34), it would be much more efficient to store the whole polygon data as a string blob. This will greatly reduce the number of database accesses needed to fetch it.
The DI type has been changed to Blob, this doesn't cause the error anymore. I am closing this as invalid.
