Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re[2]: [higgins-dev] Display and schema information in IdAS API

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).

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



Back to the top