On Donnerstag, 7. Januar 2010, Schuchardt, Karen L wrote: > Hi all, > > Forgive me if I misunderstand or am off topic.... > > The idea of internal objects is very interesting and I appreciate the > description of SIO versus SMW native objects. What I am wondering is if > the idea of internal objects could be extended to complex objects like > tables. One could imagine a whole set of capabilities oriented around > tables of data entered by users and/or extracted from collections of > pages. In the latter case, you would not want to be constrained to a 1 to > 1 mapping between page and object. And in either case, you would not want > the object stored as a 256 character string. I'm curious as to whether > you have considered this type of capability and how will it does (or > doesn't) fit within your design or future plans.
It is good to have a general discussion about new "compound" datatypes, especially the ones that can already be realised in SMW with only little effort. This includes essentially all types of data that one could indirectly represent by relating a page to an auxiliary page that contains this data. Using SMW's new features, the auxiliary page would then become the "internal object" that is attached to the original page automatically when data is entered. There is no limit to 256 characters involved here (this limit is only created for the old multi-valued properties due to the way in which they are declared). Yet, every data item in SMW still belongs to exactly one page, so a table structure that somehow exists outside this framework (due to being related to many pages) is not possible. Of course, making data that exists independently of pages breaks many of the basic assumptions of SMW and MediaWiki, since all special pages, version history, maintenance scripts, and access control are all based on the fact that all content relates to pages. Changing this is not in scope for SMW development, but an extension that does that may still be able to use some of SMW's code (e.g. for processing user input in various datatypes). But there are many realistic extensions that could be accomplished based on SMW's improved management for compound data -- essentially arbitrary datatypes consisting of more than one value could be done. Concrete proposals for such types that also describe how the data would be entered on a wiki page are welcome. Markus > > Karen > > > On 1/6/10 12:17 PM, "Markus Krötzsch" <mar...@semantic-mediawiki.org> > wrote: > > 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 > -- > -- 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
