[Mondrian] Properties VS multiple member captions

Fri Apr 24 10:44:51 EDT 2015

"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

and in olap4j:

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

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> 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> 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> 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> 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> 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
>>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>>
>>
>>
>>
>> --
>> Roland Bouman
>> blog: http://rpbouman.blogspot.com/
>> twitter: @rolandbouman
>> linkedin: 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) and "Pentaho Kettle Solutions" (Wiley, ISBN:
>> 978-0-470-63517-9 http://tinyurl.com/33r7a8m)
>>  _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org
>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>
>>
>>
>> _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org
>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>
>>
>
>
> --
> Roland Bouman
> blog: http://rpbouman.blogspot.com/
> twitter: @rolandbouman
> linkedin: 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) and "Pentaho Kettle Solutions" (Wiley, ISBN:
> 978-0-470-63517-9 http://tinyurl.com/33r7a8m)
>  _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>

-- 
Roland Bouman
blog: http://rpbouman.blogspot.com/
twitter: @rolandbouman
linkedin: 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) and "Pentaho Kettle Solutions" (Wiley, ISBN:
978-0-470-63517-9 http://tinyurl.com/33r7a8m)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20150424/e2a85cba/attachment.html 