>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 <markus@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.



On 22/05/12 16:08, Jeroen De Dauw wrote:

 > 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?

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 you could have a list of "Has
point" properties. This way you could do stuff like querying all the
points in a polygon that have a latitude more then x. This requires some
more thought I think - anyone more thoughts on this?

[0] http://semantic-mediawiki.org/wiki/Subobject


Jeroen De Dauw
Don't panic. Don't be evil.

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