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 > > 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/ > > > > _______________________________________________ > 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
