Re[4]: [higgins-dev] Display and schema information in IdAS API

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

Yes, it is the main reason why I'm proposing these extension.

Generally speaking I agree with Tom and Jim that it would be better to
have the model interfaces extend IHasMetadata. On the API level it
would be a simplest but elegant solution for all use cases we have now
(display data I'm worry about could be just a special case of
metadata) but I don't think it would be easy on the schema level.

Valery.

Wednesday, January 17, 2007, 5:24:41 PM, you wrote:

> Valery wrote: 
>> 
>> Paul,
>> 
>> Yes, our metadata mechanism is extensible but I don't think it is
>> flexible. (i.e. we can define and use metadata on the instances of
>> attributes but we can't do this on their types/definitions).

> I agree. That's why you're proposing these extensions, right?

>> Valery
>> 
>> Wednesday, January 17, 2007, 12:05:47 AM, you wrote:
>> 
>> > Tom wrote:
>> >>
>> >> In the past, we've been asked for ability to associate any kind of
>> >> metadata with any items in the model.  Shouldn't we go for a flexible,
>> >> extensible metadata approach?
>> 
>> > We do have an extensible metadata mechanism (i.e. anyone can add any
>> kind of
>> > metadata to their context's schema) but what we're proposing here is
>> > essentially a standard set of metadata definitions that are defined in
>> the
>> > base higgins.owl.
>> 
>> >>
>> >> Tom
>> >>
>> >> >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 01/16/07 12:03 PM >>>
>> >> Valery,
>> >>
>> >> I just read this all the way through and apologize not doing so before
>> >> responding the first time :).
>> >>
>> >> I agree with these points and add that we also need some additional
>> >> information:
>> >>
>> >> - On digital subject models, it would be good to differentiate between
>> >> _required_ and _optional_ attributes
>> >> - On attribute models, we need to associate matching rules.
>> Specifically,
>> >> we need to list the matching rules used for equality, and optionally
>> for
>> >> ordering, and substring.
>> >> In the past, we've also heard requests for the ability of an icon to be
>> >> associated with items in the model so a management UI could use
>> graphics
>> >> from the model to display things like a picture of a person for a
>> person
>> >> DS, or a picture of a telephone for a phone number attribute.
>> >>
>> >> Jim
>> >>
>> >> >>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 1/16/07 5:47 AM >>>
>> >>
>> >> Several week ago MikeM proposed to add getName() method to IAttribute
>> >> interface in order to be able to implement Display Token for CardSpace
>> >> interaction with the STS. When I was trying to implement CardSpace
>> >> compatible I-Card provider using IdAS as back end store I ran into
>> >> similar problem - I just realized that IdAS API doesn't provide as
>> >> much information about attributes as I need to implement UI for I-Card
>> >> view/edit in the I-Card Manager component.
>> >>
>> >> It turns out that in order to use IdAS for the I-Card Manager we
>> >> need to provide some additional information about attributes for
>> >> display purposes.
>> >>
>> >> When I was looking at Information Card model I noticed that definition
>> >> of Display Claim is a bit broader then Mike described:
>> >>
>> >> <ic:DisplayClaim URI=*xs:anyURI* ...>
>> >>   <ic:DisplayTag> xs:string </ic:DisplayTag>
>> >>   <ic:Description> xs:string </ic:Description>
>> >>   <ic:DisplayValue> xs:string </ic:DisplayValue>
>> >> </ic:DisplayClaim>
>> >>
>> >> So, along with "Name" (aka ic:DisplayTag) we may need to provide
>> >> "Description" (aka ic:Description) as well but rather for each...
>> >> *type* of claim (aka attribute) then each actual instance.
>> >>
>> >> Moreover, to have a complete set of information for visual
>> >> representation of these items (claims and attributes) we may need to
>> >> provide more then just "Name" and "Description".
>> >>
>> >> In my opinion it would be great to have complete set of information
>> >> for visual representation as follows:
>> >>
>> >> 1. Name
>> >> 2. Description
>> >> 3. Display order
>> >> 4. Display image
>> >>
>> >> What is important from my point is that in IdAS we may need to be able
>> >> to provide display information described above not only for attributes
>> >> but for all other items defined in the IdAS API (including digital
>> >> subjects, attributes, individual properties inside complex attributes
>> >> and even metadata).
>> >>
>> >> I see complete set of items in the IdAS API which should be able to
>> >> provide display information as follows:
>> >>
>> >> 1. IContext
>> >> 2. IDigitalSubject
>> >> 3. IAttribute
>> >> 4. IProperty (which is important in case of complex attributes)
>> >> 5. IMetadata
>> >>
>> >> The question is where this display information could came from?
>> >> Because such information is "static" we could define all required
>> >> information in the context's schema.
>> >>
>> >> When I was working on API for representation of context schema in IdAS
>> >> I introduced IDisplayData interface to provide display information
>> >> about items defined in the context from the context schema. The
>> >> problem is that current higgins.owl doesn't provide definitions for
>> >> such kind of information.
>> >>
>> >> To solve this I've created a small addition to higgins.owl (see
>> >> attached display-data.owl and modified person-with-address.owl as an
>> >> example of usage) which will allow to put such information in
>> >> context's schemas.
>> >>
>> >> In this ontology model "displayData" property is defined as annotation
>> >> property and so we could put instance of such property in both class
>> >> (context, ds) and property (attribute, metadata) definitions without
>> >> contradictions with OWL DL restrictions.
>> >>
>> >> In such way we will be able to define display information for any kind
>> >> of item in IdAS context and retrieve such information using idas.model
>> >> API.
>> >>
>> >> Actually I think it would be more comfortably to work with IdAS
>> >> API if we add few methods to retrieve display information from each
>> >> item in the context (including context itself).
>> >>
>> >> Another thing I need in my implementation of I-Card provider is to
>> >> know what attributes my digital subject could contain (not actually
>> >> contains). I can obtain such information using idas.model API but it
>> >> would be more comfortable if each context item could provide motel
>> >> (information about its definition in the context schema) itself.
>> >>
>> >> In order to be able to provide two kind of information mentioned above
>> >> (display information and schema information) I'd want to propose to
>> >> add one more method to the following items in the IdAS API:
>> >>
>> >> IContext {
>> >>   ...
>> >>   IContextModel getContextModel();
>> >> }
>> >>
>> >> IDigitalSubject {
>> >>   ...
>> >>   IDigitalSubjectModel getDigitalSubjectModel();
>> >> }
>> >>
>> >> IAttribute {
>> >>   ...
>> >>   IAttributeModel getAttributeModel();
>> >> }
>> >>
>> >> IProperty {
>> >>   ...
>> >>   IPropertyModel getPropertyModel();
>> >> }
>> >>
>> >> --
>> >> Best regards,
>> >>
>> >> Valery
>> >> _______________________________________________
>> >> higgins-dev mailing list
>> >> higgins-dev@xxxxxxxxxxx
>> >> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>> > _______________________________________________
>> > higgins-dev mailing list
>> > higgins-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
>> 
>> _______________________________________________
>> higgins-dev mailing list
>> higgins-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev