>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 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<http://semantic-mediawiki.org/wiki/Subobject>
>>
>> Cheers
>>
>> --
>> Jeroen De Dauw
>> http://www.bn2vs.com
>> 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/<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
>>
>>
>>
>> ______________________________**_________________
>> Semediawiki-devel mailing list
>> Semediawiki-devel@lists.**sourceforge.net<Semediawiki-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/**lists/listinfo/semediawiki-**devel<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
