Thanks for the detailed information. It sounds certainly like a big improvement 
although losing the order information of the record fields is quite a big 
shock. Using these new default properties is then a bit dangerous because 
although it technically works the returned information is, if more than one 
default type exists within a record, rather unusable as the fields are randomly 
mixed up so one has to be careful as this problem might initially not be 
obvious.

Do ask queries like {{#ask: [[RecProp::;;3.5;;]]|?RecProp|format=table}} still 
work by the system looking up what property type the third field of the record 
has before executing the query?

Thanks,
Günther

--- On Wed, 7/13/11, Markus Krötzsch <mar...@semantic-mediawiki.org> wrote:

> From: Markus Krötzsch <mar...@semantic-mediawiki.org>
> Subject: Re: [Semediawiki-user] [News] New default properties for each type
> To: zehet...@molgen.mpg.de
> Cc: "Semantic MediaWiki developers" 
> <semediawiki-devel@lists.sourceforge.net>, "Semediawiki-user" 
> <semediawiki-u...@lists.sourceforge.net>
> Date: Wednesday, July 13, 2011, 11:06 PM
> On 13/07/11 20:23, Günther Zehetner
> wrote:
> > Hi,
> >
> > Does this mean for a record property like
> [[Item::Name;Source]] where Name and Source are defined as
> property String it is in SMW 1.6 not possible anymore to see
> in the database which value is used for Name and which for
> Source? So either Name;Source or Source;Name is returned and
> no way to know which is which???
> 
> That depends on the declaration that you use for Item. The
> change in 
> Type:Record is that it now stores values by /property name/
> (as 
> everything else in SMW) and not by /position/. So if you
> declare a 
> Record like
> 
> [[has fields::String;String]]
> 
> then the two values would both be assigned to the new
> builtin 
> datatype-named Property:String. No order would be stored
> and you would 
> get any order when querying.
> 
> However, you can fix this easily: just create new
> properties of type 
> String, e.g. Property:Name and Property:Source, and change
> the 
> declaration of Item to
> 
> [[has fields::Name;Source]]
> 
> You could also call the properties String1 and String2 if
> you have no 
> better name for them. But the idea is that using
> human-readable names 
> helps to make Records more user-friendly. For example, it
> is possible to 
> query directly for values of property Name while this would
> have been 
> impossible with the old Records. Overall, all browsing,
> search, and 
> query features of SMW will work more smoothly with Records.
> (Basically, 
> Record values behave like internal wiki pages that have the
> property 
> values of the record).
> 
> The new system is strictly more powerful than the old one
> (since you can 
> simulate the old one using dummy properties like String1,
> Page2, etc. 
> while you can query these properties in the new system
> only). It creates 
> some inconvenience during transition, but the new
> datatype-named builtin 
> properties should minimize this.
> 
> The next step will be to create further datatypes that can
> act as 
> containers for arbitrary property-value pairs. Record only
> works with a 
> fixed list of input properties (main advantage: the
> property does not 
> need to be named when using it). But there is really no
> reason in SMW 
> now to have this restriction. One could as well have
> arbitrary 
> property-value "groups" that need no prior declaration of
> the allowed 
> properties. SMW already supports this internally -- all
> that we need is 
> a syntax for writing such groups.
> 
> Regards
> 
> Markus
> 
> >
> >> The new system will help smooth transition for
> recent
> >> changes in
> >> Type:Record. Records are no longer declared with a
> list of
> >> types but
> >> with a list of properties (which can be any
> user-defined
> >> property). With
> >> the new type-named properties, the old
> declarations will
> >> still work
> >> (exception: if the same type is used more than
> once, the
> >> order among the
> >> associated values is not reliably preserved; you
> should use
> >> another more
> >> specific property for avoiding duplicates).
> >
> >
> 
> 
> ------------------------------------------------------------------------------
> AppSumo Presents a FREE Video for the SourceForge Community
> by Eric 
> Ries, the creator of the Lean Startup Methodology on "Lean
> Startup 
> Secrets Revealed." This video shows you how to validate
> your ideas, 
> optimize your ideas and identify your business strategy.
> http://p.sf.net/sfu/appsumosfdev2dev
> _______________________________________________
> Semediawiki-user mailing list
> semediawiki-u...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-user
> 

------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel

Reply via email to