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

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

Jim,

I agree that it would be a good thing to have this kind of information
on the idas.model API level. The question is where and how could we
define it.

With regards to _required_ and _optional_ attributes it looks like
more or less simple case - we could just use owl:minCardinality and
owl:maxCardinality restrictions in the context schema to define
whether some type of attribute is required or not.

Unfortunately, it is not so clear for me how to be with the matching
rules.

My first intention with display data on attributes was to use some
kind of metadata but when I knew more about OWL DL restrictions I
realized that it is impossible. OWL DL doesn't allow to add extra
information to the property axiom but it is exactly what I was need to
add metadata to attribute's definition.

Valery

Tuesday, January 16, 2007, 9:03:22 PM, you wrote:

>  
>  
> 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();
> }