[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: Re[4]: [higgins-dev] Display and schema information in IdAS API
|
Why do we need to agree upon #2 as this will be attribute type specific and we only have to agree upon attribute type ? also not really sure about #1
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
![Inactive hide details for "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]()
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
01/16/2007 04:51 PM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx> |
|
|
This is fascinating. I can see both sides. Recent conversations in the identityschemas.org group (especially with Dick Hardt) support your view that the metadata should NOT be included in the Context itself, but should instead live externally.
What we’re talking about within http://identityschemas.org is having attribute type URLs be dereferenceable. (Not the existing MSFT CardSpace ones (these can be grandfathered as a special case) but in general). Attribute type URIs would dereference to either (a) a document describing metadata about the attribute or (b) a reference to a section about that attribute within a larger document. I’m pushing for (b) so that higgins.owl-based documents could be used as the metadata description format.
Interestingly, as long as we add the required semantics to higgins.owl (ignoring OpenID, etc. for the moment), then we can support either (i) what you’re saying (have a separate higgins.owl-based file to declaratively describe the attribute’s metadata) or (ii) allow the Context to include this metadata “inline” if it so wished.
In summary:
1) We need to agree on exactly what metadata semantics we require. Valery has suggested some. Jim has suggested some more.
2) We need to agree on a description language. I think we should use OWL. And specifically define the core constructs in higgins.owl
3) We need to agree on where it lives (you’re proposing external-to-IdAS, Valery is proposing external or “inline” in the Context schema. Personally I think we’re both right. And either way this third point is orthogonal to 1) and 2) above.
-Paul
From: higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Anthony Nadalin
Sent: Tuesday, January 16, 2007 5:25 PM
To: Higgins (Trust Framework) Project developer discussions
Cc: 'Higgins (Trust Framework) Project developer discussions'; higgins-dev-bounces@xxxxxxxxxxx
Subject: RE: Re[4]: [higgins-dev] Display and schema information in IdAS API
Well I think that the attribute type is sufficient to describe the display name, since we are using the attribute type to do the actually match. So I'm not in favor or adding yet more metadata to describe the display name and then trying to keep these all in sync
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
![Inactive hide details for "Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>]()
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
01/16/2007 04:16 PM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions" <higgins-dev@xxxxxxxxxxx> |
|
|
Agree that the layers above IdAS can still (and should) transform as they wish. Nevertheless, the ability for a context to be able to self-describe not just the value of an attribute (e.g. “Trevithick”) but also the preferred/suggested label (e.g. “Last name” (modulo language/internationalization)) is, in practice, essential in cases where the upper layers are unfamiliar with the attribute type (e.g. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname).
Valery and Sergei Yakovlev are working on the I-Card Manager and it provides an ability to browse/edit any Context irrespective of Context schema. Our proposal provides the needed support for this component.
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
![Inactive hide details for Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]()
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> |
|
|
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_______________________________________________
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
