| RE: [higgins-dev] Display and schema information in IdAS API |
|
I think we might be proposing a number of things. I think what Tom and I are talking about has to do with the interfaces in org.eclipse.higgins.idas.model. There are a number of interfaces there that should allow any metadata to be associated with them.
>>> "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 1/16/07 3:05 PM >>> 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 |