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

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