From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Tuesday, January 16, 2007
1:05 PM
To: Valery Kokhan; Higgins (Trust
Framework) Project developer discussions
Cc:
higgins-dev-bounces@xxxxxxxxxxx; Higgins (Trust Framework) Project developer
discussions
Subject: Re: Re[4]: [higgins-dev]
Display and schema information in IdAS API
Why should this be part of the schema ? Seems that 1
option is that there would have to be a transform at the ISS layer as this may
be device dependant and up to the ISS to transform
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Valery
Kokhan <vkokhan@xxxxxxxxxxxxxx>
|
Valery
Kokhan <vkokhan@xxxxxxxxxxxxxx>
Sent by:
higgins-dev-bounces@xxxxxxxxxxx
01/16/2007 11:48 AM
|
Please respond to
Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>; Please respond to
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|
|
To
|
"Higgins
(Trust Framework) Project developer discussions"
<higgins-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
Re[4]:
[higgins-dev] Display and schema information in IdAS API
|
|
Yes,
I'm saying that this is data which should be associated at the
shema level and model interfaces are a good place
for them but I'm
also saying that it would be more comfortable to
work if each context
item could provide its motel itself.
For example I have some digital subject and I want
to edit its
attributes in some UI. To create such UI I need to
know what kinds of
attributes this ds could contains (not actually
contains) and how to
display them and only then I need attribute's
values if any.
In this case I'd preferable to use
IDigitalSubject.getDigitalSubjectModel() to get
IDigitalSubjectModel
and use information it provides to create an UI.
Then we can use
IDigitalSubject.getAttributes() to fill the UI
with actual attribute's
values.
Valery
Tuesday, January 16, 2007, 6:55:21 PM, you wrote:
>
>
> Oh, it looks like you're saying that this is
data which is to be
> associated with an attribute's type. So
should this data should be
> associated at the schema level? If so,
the model interfaces seem
> like the proper place to add the data in the
IdAS.
>
>
>
>>>> Valery Kokhan
<vkokhan@xxxxxxxxxxxxxx> 1/16/07 9:31 AM >>>
> My understanding of current implementation of
metadata is that it is
> designed to be a "dynamic"
characteristic of the items (attributes and
> digital subgects). We can use metadata to
provide some additional
> information on each instance of attribute
(like "lastModified" or
> "timeSpan") but in this case we
rather need "static" information on
> attribute's type/kind itself and I don't
really understand how we
> can't use metadata there.
> Valery
> Tuesday, January 16, 2007, 6:01:53 PM, you
wrote:
>>
>>
>> I need to read this in more detail, but
my first reaction is that
>> this is what the metadata was placed
there for.
>>
>>
>>
>> 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();
>> }
>
_______________________________________________
> 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
