On Mittwoch, 6. Januar 2010, Patrick Nagel wrote: > Hi Markus, > > On 2010-01-06 09:27 UTC Markus Krötzsch wrote: > > The change will also introduce some fixed limit on how many values a > > multi- valued property can at most have. It is currently set to 5. > > If you have any such properties with more than 5 values then please > > let me know. > > Is this really necessary? I once had an application that would have used > around 30 values in one multi-valued property (project details to be > stored on an invoice page - which can cover multiple projects) - I > didn't go for multi-valued properties though, since it's impossible to > get the data out again in a useful way (which has been brought up a lot > of times on these lists, by me and many others). I'm using Semantic > Internal Objects now, but as Yaron pointed out, there are issues with > it, that would require changes in SMW. > > I really hope that your recent code changes will finally make it > possible to have "bundles of values that belong together" stored in a > property (or an internal object, or whatever other thing), and that it's > possible to get them out again in a useful way - not introduce new > limitations to that feature, that is really necessary as soon as you do > something non-trivial with SMW. > > If there must be a fixed limit, couldn't it be something like 2^14 - > like Excel's maximum amount of columns (iirc)?
In fact, a main purpose of change in SMW is to make way for native "internal objects" which are rather similar to what Semantic Internal Objects does. The difference that remains is that SIO makes an internal object that has a property *to* the page that it was created on, while internal objects in SMW must have a property pointing to the object *from* the page that it was created on (SMW does not currently have a way to properly support the inverted property style of SIO in a way that avoids the bugs that Yaron mentioned earlier). The new code is able to handle arbitrary property-value bundles natively in SMW. A surface syntax for this remains to be implemented, but all essential related to storage and querying of such data is ready. It might happen that multi-valued properties are eventually going to be replaced by this new system altogether, or that they co-exist with various other forms of compound data values. To make multi-valued properties fit into this scheme, however, we need to consider them as internal objects that have values assigned to internal auxiliary properties "_1", "_2", "_3", ... So multi-valued properties are really encoded as internal objects already, with the only peculiarity that the properties are assigned in a hard-coded way and are not entered by the user. We currently have all the special properties "_1", "_2", ... pre-defined in SMW, so that retrieving them even requires one DB lookup less than for the old nary code. If we could agree on some reasonably small upper bound, then I could keep it like this. As I said, it is planed anyway to support a native form of "semantic internal objects" in SMW. I don't think that the input syntax of current multi-valued property data is suitable for anything beyond 10 values. There is also a principal limitation to the number of entries that the type declaration of a multi-valued property can have: the DB column used to store this type string has at most 256 characters. So 51 values are already the theoretical upper limit since even the internal standard types need at least 4 characters and one comma per entry. Markus -- Markus Krötzsch <mar...@semantic-mediawiki.org> * Personal page: http://korrekt.org * Semantic MediaWiki: http://semantic-mediawiki.org * Semantic Web textbook: http://semantic-web-book.org --
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
