Re: [SMW-devel] Semantic mediawiki and map data
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 it 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. Any ideas on what is going on here? Can someone please elaborate the usage of SqlStubSemanticData and how it is implemented in the project? -- 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
[SMW-devel] Is it possible to have several {{{standard input|free text}}} fields on a form?
Today if you specify two or more {{{standard input|free text}}} a form
page and you input value in them both. Only the last value will be
displayed, and also duplicated over all instances of the {{{standard
input|free text}}}.
Why is this? Say if someone wanted to have a form in the middle of a
page, and some free text above and below the form. How would one go
about achieving this?
Would it be possible to extend the {{{standard input|free text}}} with
an extra parameter giving it a name, so that content would not be
duplicated and you could indeed have several instances of this input?
Cheers Kim
--
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
Re: [SMW-devel] Is it possible to have several {{{standard input|free text}}} fields on a form?
What you can do instead is to define a normal text area input and then display this in the template however you want. You don't have to assign it to a semantic property. Can you refer me to any documentation regarding this? or maybe a rough example? Thank you Kim -- 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
Re: [SMW-devel] Semantic mediawiki and map data
So I've managed to get past my issues, even without help! ;) 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, 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?
Kim
On Wed, May 23, 2012 at 2:23 PM, Kim Eik 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 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 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
Re: [SMW-devel] Semantic mediawiki and map data
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)? 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? Best regards from mr. slightly confused On Tue, May 22, 2012 at 9:48 PM, Markus Krötzsch mar...@semantic-mediawiki.org wrote: Hi Kim, that is a very exciting project. Here are some general hints/comments: * Jeroen is right, but I would suggest a slightly different approach :-) * To get started, you can store your data in a Container data item (similar to subobjects and records). In essence, this means that each value can be an arbitrary collection of property-value pairs. This gives you most flexibility and might even be needed for things like polygons where you have no limit on the amount of data. * This does not affect your surface syntax. You can create a datavalue (DV) implementation for your datatypes, and the parsing and general I/O will be the same in any case. So it will allow you to do many things. * Once this works and you have a clearer idea what the data looks like, it might be useful to have special DIs for it. The advantage of that is that the database can handle them more efficiently than general purpose container objects. The disadvantage is that the database would need to handle them in special ways instead of treating them as general purpose container objects. So there is some code needed to get update, retrieval, and query answering implemented. * The special DIs can still support the interface of Container, they can even be a special form of containers, and thus create subobjects to which further properties could be attached. This does not prevent the database from having a special handling for these containers if it is known that their structure is of a special form that could be stored in a more efficient way. So it is not necessary that your code avoids the use of Container-specific code just because of the possible later change to a custom DI. In fact, you will certainly need to use the interface of Container to get at the data. * Nischay is currently working on a general overhaul of the SQL database backend as part of his Google Summer of Code project. This might simplify such extensions in the future by making the code better structured and more accessible. So there are good reasons to wait with DI extensions now. We will keep this use case in mind -- maybe the code that is specific to each DI can be cleanly separated from the rest. Cheers, Markus On 22/05/12 16:08, Jeroen De Dauw wrote: Hey, a map can have several polygons Sure. Which polygons a map shows is determined by the query it visualizes the results for. When creating the definitions of the polygons you should not have to care to much of which polygon will end up on what map. You just create a data structure that makes sense and ensure that you can actually do the kind of queries you want to do. Would this structure be a fair assumption? [[Polygons::[[Polygon::**coords,coords,coords...]]** ,[[Polygon::coords,coords,**coords...]],[[Polygon::** coords,coords,coords...]]**]] No. Imagine you have a pile of articles of cities, then you could have a property such as Has location (which is of type polygon) which would look like: [[Has location::coords,coords,**coords...]] If you have an article describing an object that has multiple polygons, for example a group of islands where each island needs a polygon, then you simply have multiple such properties on the page. So say i have a [[Polygon::coords,coords,**coords]] property defined exactly how can i point additional metadata to this object? In order to be able to point to an object, it needs to be of type page. So you cannot out of the box specify a property such as Has stroke color. One option is to specify the polygons as part of subobjects [0], which can then also hold any extra extra info on the polygon. In a way it would be nicer to not have it as part of the subobject, but it actually behave like one, in which case
Re: [SMW-devel] Semantic mediawiki and map data
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 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 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
