Improved i-card.owl checked in

[Paul Trevithick-3]

Sergey,

This is a giant improvement, thank you. I have checked it in here [1].

Questions for you:

1. I presume that you’ve stayed entirely within the IMI specifications? It seems that you have. That was the intent.
2. WRT your #16: CDM does (in my mind) support polymorphism although I realize that the IdAS API does not—but we can fix this when we remove the Model APIs from IdAS
3. WRT your #18: I made these changes, thanks.
4. WRT your #17: Do you have ideas about how to represent these values?
5. Would you be willing to create an i-card-instance.owl file that contains an example p-card and an example m-card? If so I’ll turn them into diagrams and I’ll use them to replace the overly simplistic diagrams here [2]. I think that will help folks understand this sub-part of PDM 1.1 (i.e. The i-card.owl part) much better.
   

--Paul

[1] https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/i-card.owl
[2] http://wiki.eclipse.org/Persona_Data_Model_1.1#I-Cards


On 9/15/09 2:58 PM, "Sergey Lyakhov" <slyakhov@...> wrote:

Paul,
 
I made the following changes to attached i-card.owl:
 
1. I-Card should be able to contain extensions (in xml form).
2. ClaimType should also have the following datatype properties : claimTypeName, claimTypeDescription.
3. supportedClaimType should be object property with ClaimType range.
4. I-Card should have supportedTokenType datatype property.
5. pinDigest should have I-Card as a range (now CardSpace supports it for both m- and p-card, we did not yet implement it for m-card).
6. cardName property missed for I-Card.
7. cardVersion property missed for I-Card.
8. masterKey property missed for I-Card.
9. langId property missed for I-Card.
10. issuer property missed for I-Card.
11. stsPrivacyPolicyVersion missed for M-Card.
12. M-Card should have tokenService object property with TokenService range.
13. TokenService should have endpointReference object property with EndpointReference range.
14. EndpointReference should have address, metadataAddress and certificate properties.
15. TokenService should have userCredential object property with UserCredential range (also, there is CredentialDescriptor class defined in i-card.owl which duplicates UserCredential).
16. UserCredential should be able to contain all forth credential type descriptors. I added them as extended classes of UserCredential, but not sure it is correct. Does CDM support polymorphism?
 
Also the following changes need to be done:
 
17. P-card needs claim values.
18. strongRecipientdentityRequired - the label contains "require aplies to", but this is not quite correct. It meaning is RP should provide a cryptographically protected identity, for example, an X.509v3 certificate. Also "I" is missed in the name of this property, moreover, in CardSpace docs it is named as RequireStrongRecipientIdentity.

_______________________________________________
higgins-dev mailing list
higgins-dev@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

[Sergey Lyakhov]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Paul,

 

> 1. I presume that you’ve stayed entirely within the IMI specifications? It seems that you have. That was the intent.

 

I used MS CardSpace 1.5 doc and infocard xml schema http://schemas.xmlsoap.org/ws/2005/05/identity. I reviewed IMI 1.0 specification, and did not find any difference. However I found out that ic07IssuerInformation element  has a predefined data structure, and should not be a string.  As a result, I've added IssuerInformationEntry class, entryName and entryValue datatype properties, replased ic07IssuerInformation with the same object property. Also I fixed some my previous errors. I attached updated i-card.owl schema.

 

> 2. WRT your #16: CDM does (in my mind) support polymorphism although I realize that the IdAS API does not—but we can fix this when we remove the Model APIs from IdAS

 

Actually, Model API could correctly treat a polymorphism in a schema. Are you going to replace it with a model proposed by Jim a year ago (I and Valery think it is not convenient to use it) or plain just to use owl schema instead of Model API?

 

> 4. WRT your #17: Do you have ideas about how to represent these values?

 

I see the following cases:

1. Store claim values in separate Entity. In this case transaction problems possible if entities are stored in different contexts.

2. Store values as a complex attribute value(s) :

2.1. P-Card has a single-valied attribute with "Claims" value. All attributes of this value has attrID == claim type.  In this case claim values are predefined in schema.

2.2. P-Card has a multy-valied attribute with "Claim" values. These values, in turn, have two attributes: claimType and claimValue. In this case we can use the same schema for different sets of claims.

 

 

> 5. Would you be willing to create an i-card-instance.owl file that contains an example p-card and an example m-card?

 

I attached icardinstances.owl with those example cards. This ontology imports claimTypes.owl where claim type instances are defined. 

 

Thanks,
Sergey Lyakhov

----- Original Message -----

From: ptrevithick@...

To: slyakhov@...

Cc: synakh@... ; itsinman@... ; higgins-dev@...

Sent: Wednesday, September 16, 2009 6:47 AM

Subject: Improved i-card.owl checked in

Sergey,

This is a giant improvement, thank you. I have checked it in here [1].

Questions for you:

1. I presume that you’ve stayed entirely within the IMI specifications? It seems that you have. That was the intent.
2. WRT your #16: CDM does (in my mind) support polymorphism although I realize that the IdAS API does not—but we can fix this when we remove the Model APIs from IdAS
3. WRT your #18: I made these changes, thanks.
4. WRT your #17: Do you have ideas about how to represent these values?
5. Would you be willing to create an i-card-instance.owl file that contains an example p-card and an example m-card? If so I’ll turn them into diagrams and I’ll use them to replace the overly simplistic diagrams here [2]. I think that will help folks understand this sub-part of PDM 1.1 (i.e. The i-card.owl part) much better.
   

--Paul

[1] https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/i-card.owl
[2] http://wiki.eclipse.org/Persona_Data_Model_1.1#I-Cards


On 9/15/09 2:58 PM, "Sergey Lyakhov" <slyakhov@...> wrote:

Paul,
 
I made the following changes to attached i-card.owl:
 
1. I-Card should be able to contain extensions (in xml form).
2. ClaimType should also have the following datatype properties : claimTypeName, claimTypeDescription.
3. supportedClaimType should be object property with ClaimType range.
4. I-Card should have supportedTokenType datatype property.
5. pinDigest should have I-Card as a range (now CardSpace supports it for both m- and p-card, we did not yet implement it for m-card).
6. cardName property missed for I-Card.
7. cardVersion property missed for I-Card.
8. masterKey property missed for I-Card.
9. langId property missed for I-Card.
10. issuer property missed for I-Card.
11. stsPrivacyPolicyVersion missed for M-Card.
12. M-Card should have tokenService object property with TokenService range.
13. TokenService should have endpointReference object property with EndpointReference range.
14. EndpointReference should have address, metadataAddress and certificate properties.
15. TokenService should have userCredential object property with UserCredential range (also, there is CredentialDescriptor class defined in i-card.owl which duplicates UserCredential).
16. UserCredential should be able to contain all forth credential type descriptors. I added them as extended classes of UserCredential, but not sure it is correct. Does CDM support polymorphism?
 
Also the following changes need to be done:
 
17. P-card needs claim values.
18. strongRecipientdentityRequired - the label contains "require aplies to", but this is not quite correct. It meaning is RP should provide a cryptographically protected identity, for example, an X.509v3 certificate. Also "I" is missed in the name of this property, moreover, in CardSpace docs it is named as RequireStrongRecipientIdentity.

_______________________________________________
higgins-dev mailing list
higgins-dev@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

[Paul Trevithick-3]

On 9/18/09 6:56 AM, "Sergey Lyakhov" <slyakhov@...> wrote:

Paul,

> 1. I presume that you’ve stayed entirely within the IMI specifications? It seems that you have. That was the intent.
 
I used MS CardSpace 1.5 doc and infocard xml schema http://schemas.xmlsoap.org/ws/2005/05/identity. I reviewed IMI 1.0 specification, and did not find any difference. However I found out that ic07IssuerInformation element  has a predefined data structure, and should not be a string.  As a result, I've added IssuerInformationEntry class, entryName and entryValue datatype properties, replased ic07IssuerInformation with the same object property. Also I fixed some my previous errors. I attached updated i-card.owl schema.

## Great. Thanks.
 
> 2. WRT your #16: CDM does (in my mind) support polymorphism although I realize that the IdAS API does not—but we can fix this when we remove the Model APIs from IdAS
 
Actually, Model API could correctly treat a polymorphism in a schema. Are you going to replace it with a model proposed by Jim a year ago (I and Valery think it is not convenient to use it) or plain just to use owl schema instead of Model API?

## I have yet another idea up my sleeve. Valery probably won’t like it either, but we’ll see. I’ll let you know within 1 week.
 
> 4. WRT your #17: Do you have ideas about how to represent these values?
 
I see the following cases:
1. Store claim values in separate Entity. In this case transaction problems possible if entities are stored in different contexts.
2. Store values as a complex attribute value(s) :
2.1. P-Card has a single-valied attribute with "Claims" value. All attributes of this value has attrID == claim type.  In this case claim values are predefined in schema.
2.2. P-Card has a multy-valied attribute with "Claim" values. These values, in turn, have two attributes: claimType and claimValue. In this case we can use the same schema for different sets of claims.
 
## Before I respond to your proposal, I want to see if we first agree on something else. In CDM 1.1 attributes can have either (a) literal value(s) or (b) complex value(s). If (b) the value IS an entity. Do you agree with that?
 
> 5. Would you be willing to create an i-card-instance.owl file that contains an example p-card and an example m-card?
 
I attached icardinstances.owl with those example cards. This ontology imports claimTypes.owl where claim type instances are defined.

## Wonderful, thank you.
 
Thanks,
Sergey Lyakhov

----- Original Message -----
 
From:  Paul  Trevithick <ptrevithick@...>  
 
To: Sergey Lyakhov <slyakhov@...>  
 
Cc: Vadym Synakh <synakh@...>  ; Igor  Tsinman <itsinman@...>  ; higgins-dev <higgins-dev@...>  
 
Sent: Wednesday, September 16, 2009 6:47  AM
 
Subject: Improved i-card.owl checked  in
 

Sergey,

This is a giant improvement, thank you.  I have checked it in here [1].

Questions for you:
 

1. I presume that  you’ve stayed entirely within the IMI specifications? It seems that you  have. That was the intent.  
2. WRT your #16:  CDM does (in my mind) support polymorphism although I realize that the IdAS  API does not—but we can fix this when we remove the Model APIs from IdAS   
3. WRT your #18: I  made these changes, thanks.  
4. WRT your #17: Do  you have ideas about how to represent these values?  
5. Would you be  willing to create an i-card-instance.owl file that contains an example  p-card and an example m-card? If so I’ll turn them into diagrams and I’ll  use them to replace the overly simplistic diagrams here [2]. I think that  will help folks understand this sub-part of PDM 1.1 (i.e. The i-card.owl  part) much better.
   

--Paul

[1] https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/i-card.owl
[2]  http://wiki.eclipse.org/Persona_Data_Model_1.1#I-Cards


On  9/15/09 2:58 PM, "Sergey Lyakhov" <slyakhov@...>  wrote:

 

Paul,
 
I made the following changes to  attached i-card.owl:
 
1. I-Card should be able to contain  extensions (in xml form).
2. ClaimType should also have the following  datatype properties : claimTypeName, claimTypeDescription.
3.  supportedClaimType should be object property with ClaimType range.
4.  I-Card should have supportedTokenType datatype property.
5. pinDigest  should have I-Card as a range (now CardSpace supports it for both m- and  p-card, we did not yet implement it for m-card).
6. cardName property  missed for I-Card.
7. cardVersion property missed for I-Card.
8.  masterKey property missed for I-Card.
9. langId property missed for  I-Card.
10. issuer property missed for I-Card.
11.  stsPrivacyPolicyVersion missed for M-Card.
12. M-Card should have  tokenService object property with TokenService range.
13. TokenService  should have endpointReference object property with EndpointReference  range.
14. EndpointReference should have address, metadataAddress and  certificate properties.
15. TokenService should have userCredential  object property with UserCredential range (also, there is  CredentialDescriptor class defined in i-card.owl which duplicates  UserCredential).
16. UserCredential should be able to contain all forth  credential type descriptors. I added them as extended classes of  UserCredential, but not sure it is correct. Does CDM support  polymorphism?
 
Also the following changes need to be  done:
 
17. P-card needs claim values.
18.  strongRecipientdentityRequired - the label contains "require aplies to", but  this is not quite correct. It meaning is RP should provide a  cryptographically protected identity, for example, an X.509v3 certificate.  Also "I" is missed in the name of this property, moreover, in CardSpace docs  it is named as RequireStrongRecipientIdentity.

 

_______________________________________________
higgins-dev mailing list
higgins-dev@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

[Sergey Lyakhov]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Paul,

 

>> Actually, Model API could correctly treat a polymorphism in a schema. Are you going to replace it with a model proposed by

>> Jim a year ago (I and Valery think it is not convenient to use it) or plain just to use owl schema instead of Model API?

> ## I have yet another idea up my sleeve. Valery probably won’t like it either, but we’ll see. I’ll let you know within 1 week.

When I wrote  "...replaces IModel interfaces with something you were going to propose" here http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06101.html  , I supposed you have a new idea to replace IModel interfaces with something.  It looks I misunderstood your sentence.

 

 

Thanks,
Sergey Lyakhov

----- Original Message -----

From: ptrevithick@...

To: slyakhov@...

Cc: synakh@... ; itsinman@... ; higgins-dev@...

Sent: Saturday, September 19, 2009 6:27 PM

Subject: Re: Improved i-card.owl checked in

On 9/18/09 6:56 AM, "Sergey Lyakhov" <slyakhov@...> wrote:

Paul,

> 1. I presume that you’ve stayed entirely within the IMI specifications? It seems that you have. That was the intent.
 
I used MS CardSpace 1.5 doc and infocard xml schema http://schemas.xmlsoap.org/ws/2005/05/identity. I reviewed IMI 1.0 specification, and did not find any difference. However I found out that ic07IssuerInformation element  has a predefined data structure, and should not be a string.  As a result, I've added IssuerInformationEntry class, entryName and entryValue datatype properties, replased ic07IssuerInformation with the same object property. Also I fixed some my previous errors. I attached updated i-card.owl schema.

## Great. Thanks.
 
> 2. WRT your #16: CDM does (in my mind) support polymorphism although I realize that the IdAS API does not—but we can fix this when we remove the Model APIs from IdAS
 
Actually, Model API could correctly treat a polymorphism in a schema. Are you going to replace it with a model proposed by Jim a year ago (I and Valery think it is not convenient to use it) or plain just to use owl schema instead of Model API?

## I have yet another idea up my sleeve. Valery probably won’t like it either, but we’ll see. I’ll let you know within 1 week.
 
> 4. WRT your #17: Do you have ideas about how to represent these values?
 
I see the following cases:
1. Store claim values in separate Entity. In this case transaction problems possible if entities are stored in different contexts.
2. Store values as a complex attribute value(s) :
2.1. P-Card has a single-valied attribute with "Claims" value. All attributes of this value has attrID == claim type.  In this case claim values are predefined in schema.
2.2. P-Card has a multy-valied attribute with "Claim" values. These values, in turn, have two attributes: claimType and claimValue. In this case we can use the same schema for different sets of claims.
 
## Before I respond to your proposal, I want to see if we first agree on something else. In CDM 1.1 attributes can have either (a) literal value(s) or (b) complex value(s). If (b) the value IS an entity. Do you agree with that?
 
> 5. Would you be willing to create an i-card-instance.owl file that contains an example p-card and an example m-card?
 
I attached icardinstances.owl with those example cards. This ontology imports claimTypes.owl where claim type instances are defined.

## Wonderful, thank you.
 
Thanks,
Sergey Lyakhov

----- Original Message -----
 
From:  Paul  Trevithick <ptrevithick@...>  
 
To: Sergey Lyakhov <slyakhov@...>  
 
Cc: Vadym Synakh <synakh@...>  ; Igor  Tsinman <itsinman@...>  ; higgins-dev <higgins-dev@...>  
 
Sent: Wednesday, September 16, 2009 6:47  AM
 
Subject: Improved i-card.owl checked  in
 

Sergey,

This is a giant improvement, thank you.  I have checked it in here [1].

Questions for you:
 

1. I presume that  you’ve stayed entirely within the IMI specifications? It seems that you  have. That was the intent.  
2. WRT your #16:  CDM does (in my mind) support polymorphism although I realize that the IdAS  API does not—but we can fix this when we remove the Model APIs from IdAS   
3. WRT your #18: I  made these changes, thanks.  
4. WRT your #17: Do  you have ideas about how to represent these values?  
5. Would you be  willing to create an i-card-instance.owl file that contains an example  p-card and an example m-card? If so I’ll turn them into diagrams and I’ll  use them to replace the overly simplistic diagrams here [2]. I think that  will help folks understand this sub-part of PDM 1.1 (i.e. The i-card.owl  part) much better.
   

--Paul

[1] https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/i-card.owl
[2]  http://wiki.eclipse.org/Persona_Data_Model_1.1#I-Cards


On  9/15/09 2:58 PM, "Sergey Lyakhov" <slyakhov@...>  wrote:

 

Paul,
 
I made the following changes to  attached i-card.owl:
 
1. I-Card should be able to contain  extensions (in xml form).
2. ClaimType should also have the following  datatype properties : claimTypeName, claimTypeDescription.
3.  supportedClaimType should be object property with ClaimType range.
4.  I-Card should have supportedTokenType datatype property.
5. pinDigest  should have I-Card as a range (now CardSpace supports it for both m- and  p-card, we did not yet implement it for m-card).
6. cardName property  missed for I-Card.
7. cardVersion property missed for I-Card.
8.  masterKey property missed for I-Card.
9. langId property missed for  I-Card.
10. issuer property missed for I-Card.
11.  stsPrivacyPolicyVersion missed for M-Card.
12. M-Card should have  tokenService object property with TokenService range.
13. TokenService  should have endpointReference object property with EndpointReference  range.
14. EndpointReference should have address, metadataAddress and  certificate properties.
15. TokenService should have userCredential  object property with UserCredential range (also, there is  CredentialDescriptor class defined in i-card.owl which duplicates  UserCredential).
16. UserCredential should be able to contain all forth  credential type descriptors. I added them as extended classes of  UserCredential, but not sure it is correct. Does CDM support  polymorphism?
 
Also the following changes need to be  done:
 
17. P-card needs claim values.
18.  strongRecipientdentityRequired - the label contains "require aplies to", but  this is not quite correct. It meaning is RP should provide a  cryptographically protected identity, for example, an X.509v3 certificate.  Also "I" is missed in the name of this property, moreover, in CardSpace docs  it is named as RequireStrongRecipientIdentity.

 

_______________________________________________
higgins-dev mailing list
higgins-dev@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

[Paul Trevithick-3]

Sergey,

Sorry. I haven’t been very clear. Let me try again here.

The changes that we’ve made in the Context Data Model 1.1, and implemented in IdAS mean that we now have a data model that can represent RDF graphs as CDM entities, simple (literal) attributes and complex (entity-valued) attributes in a very natural way. This opens up the possibility of CDM/IdAS contexts containing not just “instance” data (e.g. the (entity attribute attribute-value) statement (paul eyeColor green)) but also statements like (paul rdf:type :Person) and, more to the point of what we are discussing here, statements about the Person class itself. And of course of this is exactly how things are done in in the world of RDF.

I’m proposing that we model in CDM classes of entities and kinds of attributes using entities and attributes. We would use the URI rdf:type to link an instance entity to its class entity(ies). And we would use various RDF vocabularies to describe these classes of entities and attributes. All that remains for us (e.g. me) to do is to document on the CDM page on the Higgins wiki exactly which vocabularies we are using, and which parts of them. The obvious choice is to use the RDFS vocabulary. Some of OWL is may be useful. I find that parts of the SPIN (see http://spinrdf.org) vocabulary may also be extremely useful. SPIN introduces ways to model closed-world, OOP concepts of classes and attributes that I think Context CP developers will find familiar and useful, which still allowing open world models like native RDF.

With this approach no further changes are required to IdAS, and we don’t need the current Model interfaces. What does change with this approach is that if a context developer wants to express the “class” aspects of the entity and attribute instances in their context data set, they would need to populate their context (or some context) with yet more entities that describe classes of entities and attributes (e.g. as owl:Classes, owl:DatatypeProperties and owl:ObjectProperties). If they do this, the the existing Higgins IdAS 1.1 API can be used to inspect and navigate these “class” entities.

--Paul




On 10/20/09 11:07 AM, "Sergey Lyakhov" <slyakhov@...> wrote:

Paul,

>> Actually, Model API could correctly treat a polymorphism in a schema. Are you going to replace it with a model proposed by
>> Jim a year ago (I and Valery think it is not convenient to use it) or plain just to use owl schema instead of Model API?

> ## I have yet another idea up my sleeve. Valery probably won’t like it either, but we’ll see. I’ll let you know within 1 week.
When I wrote  "...replaces IModel interfaces with something you were going to propose" here http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06101.html <http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06101.html>   , I supposed you have a new idea to replace IModel interfaces with something.  It looks I misunderstood your sentence.

_______________________________________________
higgins-dev mailing list
higgins-dev@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev