On 24/05/12 09:41, Kim Eik wrote:
> So I've managed to get past my issues, even without help! ;)
Great :-)
Re your missing table issue: future versions of SMW will always have
coordinate support enabled. Migration code (if needed) will be based on
the SM table. So a good approach might be to store your data in this
table rather than creating a new one (I am not even sure how SMW would
behave when registering two tables that can hold coordinates). You could
simply require SM as a prerequisite for your code (temporarily, until
SMW does the right thing by default), or you could create the same table
as SM.
> Anyways,
> you knock one down, and another one pops up, isn't that how it usually
> is? So what i have done so far is that i put all the coordinates in a
> Container object instead. that solved the one to many mapping,
Yes, that is the right way to go, I think.
> however
> now it seems that i can't retrieve the data when i try to query it
> through the #ask: parser function.
>
> I have a page where i have defined the property
> [[Polygon::<coords>,<coords>....]], the page belongs to a category Polygon.
>
> on the category page i have the following contents:
>
> {{#ask: [[Category:Polygon]]
> | ?Coordinates
> | ?Polygon
> | template=Oilfield-popup
> | format=table
> }}
>
> which draws a table on the cateogory page, however, the column with the
> polygon data is empty.
>
> When digging in the sourcecode i can see that there is a call made to
> SMWResultArray::getNextDataValue(), this however seems to always return
> false instead of the expected container value when it comes to the
> polygon property. Can someone please explain why that is?
There are two things here: using container-type values in query
conditions (querying by their values) and using container-type values in
printouts (displaying their values). The second is not completely clear
to me right now. The DV for Record is getting a Container on
initialisation, so SMW seems to reproduce the complete container in this
case (this might happen in SMW_SqlStubSemanticData.php). I don't know
right now why this would work there and not for your case. Did you
register your new datatype (DV class) to use containers? This is done in
the hook smwInitDatatypes; see SMW_DatavalueFactory for docuemntation
(it's similar to the property registration, using registerDatatype and
registerDatatypeAlias). Without this, SMW won't know that you need a
container and it will just give you the subobject (wikipage DI) when
retireving data from the store; this would then be rejected by your DV,
and no values would be created.
Now for the first issue (which may not be your problem yet, but will
probably come up later). Container-type data values need to be queried
differently. Every datavalue has its own code for deciding what to query
when a user enters some string in #ask. This is implemented in the
SMWDataValue's method getQueryDescription(). The default handling is to
interpret initial comparators (<, >, ...) first, and then parse the rest
like a user input. The result is used for querying. This does not work
for containers, since, IIRC, SMW does not currently support the use of
container DIs in queries (i.e., in the PHP level description of
queries). I might be wrong here.
The pedestrian solution for now is to implement something like in
SMW_DV_Record.php. The code there has two modes during parsing: either
construct a DIContainer or construct a query description. This is
actually needed there because Records also support comparators (<, >,
...) for *each* of their component values in queries; so the parsing is
sightly different (it must allow comparators in front of each value, not
just at the very beginning). If this is not desired, then one could also
have the same parsing and just turn the container into a query (this
might already have code somewhere; not sure). The only thing to do
differently would be to use an anonymous subject for the Container in
this case -- otherwise the query will search for exactly the subject
name that you have given, which is not correct.
This thread is getting into the most comprehensive documentation of SMW
internals ever written ;-)
Markus
> On Wed, May 23, 2012 at 2:23 PM, Kim Eik <k...@heldig.org
> <mailto:k...@heldig.org>> wrote:
>
> Ok, so i figured out how to create the necessary table.. however i'm
> unsure of how i should set up a one to many mapping towards the
> sm_coords table..
>
> as of now i have defined the following table:
>
> self::$prop_tables['smw_polygon'] = new SMWSQLStore2Table(
> 'sm_polygon',
> array( 'coordinate_id' => 'p'),
> array( 'coordinate_id' )
> );
>
> where coordinate_id is supposed to refer to sm_coords table entries.
> however, it seems that no other table here has this type of
> structure/mapping. So i'm guessing this is the wrong way to go? I
> could always just have all the data in a clob field instead, but
> this i'm guessing isn't very optimal when taking semantic search
> into account.
>
> So how should i create a one to many mapping on the database level
> as well as on the logic level? or should polygons be stored in some
> other way?
>
> Cheers.
>
> On Wed, May 23, 2012 at 12:49 PM, Kim Eik <k...@heldig.org
> <mailto:k...@heldig.org>> wrote:
>
> Ok, so i have run into an issue.
>
> A database query syntax error has occurred. This may indicate a
> bug in the software. The last attempted database query was:
>
> (SQL query hidden)
>
> from within function "SMW::getPropertySubjects". Database
> returned error "1103: Incorrect table name '' (localhost)".
>
> What i have done so far is defined a new property Geographic
> polygon. and in my test wiki i tried setting the property [[Has
> type::Geographical polygon]]
>
> By doing that i'm now getting this database issue. From what i
> can gather i'm missing a database table to store my structure.
> In the existing code i can see tht TYPE_GEO is defined as
> smw_coords which im guessing is the table name that stores
> Geographic coordinates.
>
> SMWDataItem::TYPE_GEO => 'smw_coords', // currently
> created only if Semantic Maps are installed
>
> Now, how should i proceed to add a table for a polygon?
> a polygon is just a collection of coords, so i guess i could use
> smw_coords as my main table for storing the coordinates of
> polygons, and then another table that refers to smw_coords with
> a one to many mapping.
>
> And where in the semantic maps extension can i actually find som
> sql code that creates the given table?
>
> Oh, and btw, i could use some code review as im piecing this
> together. would it be ok if i added the code ive written so far
> to gerrit? so you guys can follow my progress line by line? that
> way you could probably help me better if other issues arise. So
> far i have written code for SemanticMediaWiki and SemanticMaps.
>
> Cheers
>
>
> On Wed, May 23, 2012 at 11:11 AM, Markus Krötzsch
> <mar...@semantic-mediawiki.org
> <mailto:mar...@semantic-mediawiki.org>> wrote:
>
> On 23/05/12 09:02, Kim Eik wrote:
>
> >From your descritpion, a container data item looks
> like the way to go
> for storing my structures. Do you have a practical
> example on how
> container data item is used?
>
> From the code documentation i can see that:
>
> * Being a mere placeholder/template for other data, an
> SMWDIContainer
> is not
> * immutable as the other basic data items. New
> property-value pairs
> can always
> * be added to the internal SMWContainerSemanticData.
>
> so is it correct to assume that in a practical example,
> in order to
> create a container data item, you actually create a
> template which holds
> all your other properties (like a set of
> [[Polygon::...]] properties)?
>
>
> The word "template" is not well chosen in this
> documentation. It has nothing to do with a MW template. When
> using containers to store data, they are simply like an
> "internal wiki page" together with property-value
> assignments. Instead of using containers, one could also
> create a new wiki page, assign all the data to that wiki
> page, and then use the wiki page instead of the Container DI
> as a property value. But this would not fit into one
> property assignment and would require multiple operations
> instead. Containers are mainly a convenience structure so
> that data for multiple (sub)wikipages can be processed in
> one go.
>
> The word "template" comes in when you use a container value
> as a search pattern (in queries or in special pages). Then a
> container can be used without a subject ("anonymous"
> subject): in this case the subject's name does not matter in
> the search and only the property values of the container are
> used to find matches. This is what is meant by "template" in
> this sentence.
>
> You can see a short code example on how to create arbitrary
> container DIs in the file SMW_Subobject.php (the
> implementation of the subobject parser function). This code
> uses a user-provided name for the subobject. There is also
> code in SMW_DV_Record.php that generates an internal name on
> the fly by hashing the data (around line 42). Generated
> names should start with "_". This allows SMW to decide if a
> subobject name should be displayed to users or not.
>
>
>
> As i said, i'm quite new to this semantic way of
> structuring data, so
> please forgive me for not having a better understanding
> of how all this
> is connected.
>
> And another thing, in which end would you say i should
> start trying to
> implement my data structure, should i start with the
> individual
> dataitems/datavalues and then look at creating a
> container? do i even
> need to create/subclass my own container? or can i use
> the one already
> defined?
>
>
> You can use the one that is already defined. In order to
> store data in a container, you need properties. You need to
> register these properties so that they are available (and
> have the correct type) without the user having to create
> pages for them. Every property has an internal string ID
> that you use in the code to address it. It can also have a
> user-label that users can write to address it (if no label
> is given, then users will never see it and cannot search for
> it).
>
> Property registration is done in a hook, for example:
>
> $wgHooks['smwInitProperties'][ ] = 'myinitProperties';
>
> function myinitProperties() {
> // Register a user-visible property with ID '___myp':
> SMWDIProperty:: registerProperty('___myp', '_num',
> 'Myproperty', true);
> // Register an alternative user label for this property:
> SMWDIProperty:: registerPropertyAlias('___myp' , 'My
> property');
>
> return true;
> }
>
> See the documentation for registerProperty() for details.
> Always call your own property IDs with three initial
> underscores to avoid name clashes.
>
>
> After you registeed properties in this way, you can use them
> for storing and retrieving values in the container (if they
> have a user label, you can also use them in the wiki; a good
> way to try if it worked). In PHP, you can create a property
> object like this:
>
> $myProperty = new SMWDIProperty('___myp');
>
> Do not use your label but the property ID here. To create a
> property from its label, you could use the method
> SMWDIProperty:: newFromUserLabel(), but this should not be
> needed. If the property is registered, SMW will use the
> right datatype for storing and retrieving it. If the
> datatype is changed later on, SMW will not find old stored
> values any more (as expected; if you store values as a
> string, you don't get them when looking for numbers later
> on). However, the problem repairs itself over time (old
> values get deleted when pages are stored again).
>
> Moreover, you can add any value for any property in a
> Container -- it is not checked if the types are the same
> (e.g., you can assign a DIString object to a property that
> is declared to hold a number). If types are not the same,
> the data might simply not be stored, or might be stored in
> the wrong place and not be found again. Again, this will
> repair itself when correcting the code and not cause
> permanent problems.
>
> One way to inspect the current database contents is
> Special:Browse (if your properties have user labels). To
> view properties that have no user label, you can try
> Special:RDFExport (but this does not have good support for
> showing data of subobjects).
>
> That's all! It is a lot of material in the beginning, but it
> is not that complicated in the end ... I hope ;-).
>
> Markus
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
