[Mondrian] Properties VS multiple member captions

Diethard Steiner diethard.steiner at gmail.com
Fri Apr 24 10:53:21 EDT 2015


That’s interesting, thanks. I see there is also CAPTION_ABREVIATION  and CAPTION_SHORT. It would be really good to know if this is supported by Mondrian!

> On 24 Apr 2015, at 15:44, Roland Bouman <roland.bouman at gmail.com> wrote:
> 
> "The intrinsic member property caption has a 1:1 relationship to the member key, the same is not true for any other random property we manually add"
> 
> Well, not necessarily. Captions are unique only in sofar the schema designer took care to make them unique, or unique enough within the context.
> 
> I agree that there is an expectation that the Caption is unique enough to make sense in the user output.
> 
> Actually, I'm just looking at the metadata that is available for properties, at least in OLE DB
> 
> https://msdn.microsoft.com/en-us/library/ms126309.aspx <https://msdn.microsoft.com/en-us/library/ms126309.aspx> 
> 
> and in olap4j:
> 
> http://www.olap4j.org/api/org/olap4j/metadata/Property.ContentType.html <http://www.olap4j.org/api/org/olap4j/metadata/Property.ContentType.html>
> 
> And it seems that there is at least at the API level the ability to have a property marked as "Caption".
> 
> http://www.olap4j.org/api/org/olap4j/metadata/Property.ContentType.html#CAPTION <http://www.olap4j.org/api/org/olap4j/metadata/Property.ContentType.html#CAPTION>
> 
> I'm not sure if there is a way to define this in a mondrian schema though.
> 
> (standards also define different types of dimensions, in addition to standard and date, as well as additional types for levels. I don't know if it's possible to author that at the schema level either) 
> 
> On Fri, Apr 24, 2015 at 4:25 PM, Diethard Steiner <diethard.steiner at gmail.com <mailto:diethard.steiner at gmail.com>> wrote:
> In regards to the client UI: Yes, I suppose it would work if there was a better support for properties. The only concern is that some end users might not be aware which properties are unique and which ones not.
> So how about a MDX query then: Our result will show both member key and the property/alternative caption. There is no way to show the property value on its own on one axis (as far as I know). That’s a complexity a client GUI could hide. 
> 
> The intrinsic member property caption has a 1:1 relationship to the member key, the same is not true for any other random property we manually add. That’s why originally I thought it might be a good idea to be declare several captions (or maybe have at least a is_unique flag for properties).
> 
> 
>> On 24 Apr 2015, at 15:02, Roland Bouman <roland.bouman at gmail.com <mailto:roland.bouman at gmail.com>> wrote:
>> 
>> "This is why I was wondering if maybe it might be a good idea to have a feature that allows the definition of more than one caption per level. "
>> 
>> Well, "the Caption" is simply a property. An intrinsic one, but still, only a property. There's nothing that says how it should be used. 
>> Although most tool vendors take the hint and use it for a label in the UI :)
>> So, what difference does it make what property you use to fill that label? it's up to the tool really.
>> 
>> If you like you can create custom properties called Caption1, Caption2, ...etc. and then you basically have what you want. 
>> One could perhaps imagine an additional array data type, and a special MDX accessor that does: Member.Properties("Captions").Item(1) or something like that, but it doesn't really add more functionality. 
>> 
>> (For the record, I am not proposing such a feature should be created - on the contrary!)
>> 
>> I guess I'm saying, you already have what you want. All you need is user input that tells you which properties the end user would like to use as labels in the UI/output.
>> 
>> Best regards,
>> 
>> Roland
>> 
>> Roland
>> 
>> On Fri, Apr 24, 2015 at 3:44 PM, Diethard Steiner <diethard.steiner at gmail.com <mailto:diethard.steiner at gmail.com>> wrote:
>> Thanks Roland for your reply! For the use case I illustrated before I was wondering if properties are really the right way to go. I’ve seen a few Mondrian schemas where it was implemented this way - and this might be because there was no better option. I do think properties have their valid use cases, however, displaying Jan or January or 1 is more like using a different format (or caption). This is why I was wondering if maybe it might be a good idea to have a feature that allows the definition of more than one caption per level. The advantage I see is that once such a feature is support in Mondrian and there is MDX support for it, we could just display that caption independently (instead of having to display the standard caption plus the member property). [Note: I am just talking about cases where there is a 1:1 relationship between the member key and the alternative caption].
>> 
>> 
>>> On 24 Apr 2015, at 14:18, Roland Bouman <roland.bouman at gmail.com <mailto:roland.bouman at gmail.com>> wrote:
>>> 
>>> Personally, I think it is the job of the client tool to provide captions, and to provide the user with options that say which properties should be used in the user interface to label members.
>>> 
>>> In fact this is already the case: many tools will use the intrinsic property MEMBER_NAME or MEMBER_CAPTION; it's just that most client tools don't bother to offer options for the end user to make a selection, let alone, specify a user-defined property.
>>> 
>>> I don't see how Mondrian can dictate how properties are to be used to label things in the user interface.
>>> 
>>> My 2cts.
>>> 
>>> Roland.
>>> 
>>> On Fri, Apr 24, 2015 at 2:57 PM, Diethard Steiner <diethard.steiner at gmail.com <mailto:diethard.steiner at gmail.com>> wrote:
>>> Good afternoon,
>>> 
>>> Over the last few weeks I had quite an interesting discussion about a date dimension and properties.
>>> 
>>> Properties, as you might know, are mainly used to display additional info about a member. And this info does not have to be unique to one member (value/key). So e.g. price could be a property of product and the same price could potentially show up for various products.
>>> 
>>> There is however at least one interesting case where properties are used to display alternative labels/captions: E.g. think of a date dimension where month might be displayed as an Integer value, but using properties you could also show Jan and/or January (2 additional properties that are available in our imaginary Mondrian Schema). Now in this case the values are unique for each member, meaning, Jan will only show up for 1 and not for e.g. 2 as well. End user would might want to sometimes use the abbreviated month name (e.g. Jan) in the report, sometimes the full name and on rare occasions the integer version. However, the end user isn’t interested in showing the key (the integer version of the month) when they use any of the properties. The problem is that properties cannot be used on their own (which makes sense when the values are not unique). So here really we would have to create 2 additional hierarchies to independently display the month abbreviation or the month full name, but this approach is certainly far from ideal. So I was wondering, if there is a way to define alternative captions for a member? (which means we would only have to create one hierarchy which could cater for various needs). For a moment I thought maybe I could just use a formatting mask to turn 1 into Jan or January. This might work with a date dimension, but let’s think of a more complex case, where these alternative captions can only be sourced from a DB.
>>> 
>>> I am looking forward to hearing your thoughts on this.
>>> 
>>> Best regards,
>>> Diethard
>>> 
>>> _______________________________________________
>>> Mondrian mailing list
>>> Mondrian at pentaho.org <mailto:Mondrian at pentaho.org>
>>> http://lists.pentaho.org/mailman/listinfo/mondrian <http://lists.pentaho.org/mailman/listinfo/mondrian>
>>> 
>>> 
>>> 
>>> -- 
>>> Roland Bouman
>>> blog: http://rpbouman.blogspot.com/ <http://rpbouman.blogspot.com/>
>>> twitter: @rolandbouman
>>> linkedin: http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro <http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro>
>>> 
>>> Author of "Pentaho Solutions" (Wiley, ISBN: 978-0-470-48432-6 http://tinyurl.com/lvxa88 <http://tinyurl.com/lvxa88>) and "Pentaho Kettle Solutions" (Wiley, ISBN: 978-0-470-63517-9 http://tinyurl.com/33r7a8m <http://tinyurl.com/33r7a8m>)
>>> _______________________________________________
>>> Mondrian mailing list
>>> Mondrian at pentaho.org <mailto:Mondrian at pentaho.org>
>>> http://lists.pentaho.org/mailman/listinfo/mondrian <http://lists.pentaho.org/mailman/listinfo/mondrian>
>> 
>> 
>> _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org <mailto:Mondrian at pentaho.org>
>> http://lists.pentaho.org/mailman/listinfo/mondrian <http://lists.pentaho.org/mailman/listinfo/mondrian>
>> 
>> 
>> 
>> 
>> -- 
>> Roland Bouman
>> blog: http://rpbouman.blogspot.com/ <http://rpbouman.blogspot.com/>
>> twitter: @rolandbouman
>> linkedin: http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro <http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro>
>> 
>> Author of "Pentaho Solutions" (Wiley, ISBN: 978-0-470-48432-6 http://tinyurl.com/lvxa88 <http://tinyurl.com/lvxa88>) and "Pentaho Kettle Solutions" (Wiley, ISBN: 978-0-470-63517-9 http://tinyurl.com/33r7a8m <http://tinyurl.com/33r7a8m>)
>> _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org <mailto:Mondrian at pentaho.org>
>> http://lists.pentaho.org/mailman/listinfo/mondrian <http://lists.pentaho.org/mailman/listinfo/mondrian>
> 
> 
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org <mailto:Mondrian at pentaho.org>
> http://lists.pentaho.org/mailman/listinfo/mondrian <http://lists.pentaho.org/mailman/listinfo/mondrian>
> 
> 
> 
> 
> -- 
> Roland Bouman
> blog: http://rpbouman.blogspot.com/ <http://rpbouman.blogspot.com/>
> twitter: @rolandbouman
> linkedin: http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro <http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro>
> 
> Author of "Pentaho Solutions" (Wiley, ISBN: 978-0-470-48432-6 http://tinyurl.com/lvxa88 <http://tinyurl.com/lvxa88>) and "Pentaho Kettle Solutions" (Wiley, ISBN: 978-0-470-63517-9 http://tinyurl.com/33r7a8m <http://tinyurl.com/33r7a8m>)
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20150424/f183c6cc/attachment-0001.html 


More information about the Mondrian mailing list