higgins-dev http://dev.eclipse.org/mhonarc/lists/higgins-dev/maillist.html higgins-dev en-us Thu, 19 Nov 2009 14:01:56 GMT Thu, 19 Nov 2009 14:01:56 GMT http://blogs.law.harvard.edu/tech/rss MHonArc RSS 2.0 RCFile webmaster@eclipse.org (Webmaster) webmaster@eclipse.org (Webmaster) higgins-dev http://www.eclipse.org/eclipse.org-common/themes/Phoenix/images/eclipse_home_header.jpg http://dev.eclipse.org/mhonarc/lists/higgins-dev/maillist.html [higgins-dev] No Higgins call this week or Nov 26 (US Thanksgiving) http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06127.html There is no Higgins call this week (Nov 19th) or next week (US Thanksgiving). The next Higgins developers call will be Thursday, December 3rd at Noon EDT

There is no Higgins call this week (Nov 19th) or next week (US Thanksgiving).  The next Higgins developers call will be Thursday, December 3rd at Noon EDT

]]> Thu, 19 Nov 2009 13:51:55 GMT http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06127.html mary@xxxxxxx (Mary Ruddy) Re: [higgins-dev] Normalize Authn Service 1.1 to WRAP? http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06126.html Hello, I'm working on normalizing Authn Service 1.1 according to Web Resource Authorization Protocol (WRAP) v. 0.9.7.1 But I'd like to discuss Access Token format. WRAP does not define format of the Access Token, but mentions the Simple Web Token (SWT) lik... Hello, I'm working on normalizing Authn Service 1.1 according to Web Resource Authorization Protocol (WRAP) v. 0.9.7.1 But I'd like to discuss Access Token format. WRAP does not define format of the Access Token, but mentions the Simple Web Token (SWT) like possible Access Token formats (see 6.3, 4.1), btw, higgins already has SAML support, so let compare them. WRAP (4.1) defines the following Access Token requirements: * Protected Resources MUST be able to verify that the Access Token was issued by a trusted Authorization Server and is still valid. * Access Tokens SHOULD periodically expire. * Access Token may be delivered by using HTTP Authorization header or URL parameter or POST parameter. SAML token may be the best choice for WS conversation by using SOAP header. However WRAP assumes to send Access Token by using HTTP header or URL parameter, but the size of all HTTP headers ranging from 4KB to 16KB. SAML is not compact so it may not so good choice to WRAP. We could use SAML without WRAP, when we was going to send Access Token just ones by using POST request, and after that using the Session Token. Simple Web Token is compact and formatted to be easily included in HTTP header. Set of assertions (name/value pairs) should be encoded by using application/x-www-form-urlencoded per 17.13.4 of HTML 4.01. However SWT requires to use SHA 256 HMAC. It assumes that both Auth Service and Protected Service (Attribute Service, CardSync) must know secret HMAC key for calculate/validate HMAC digest, but SWT doesn't define how to distribute HMAC key between all services. Auth service may generate new HMAC key each time, encrypt it by using Protected Service public key and include it in the Access Token. The other option may be using RSA-SHA-256 signature instead of HMAC-SHA-256, but it will be incompatible with SWT. I tend to implement it. Latest WRAP and SWT specifications available at http://groups.google.com/group/oauth-wrap-wg/files . Please let me know your concerns, suggestions. -- thanks, Alexander Yuhimenko On Mon, 9 Nov 2009 15:16:16 +0200 Alexander Yuhimenko <AYuhimenko@xxxxxxxxxxxxxx> wrote: > Thanks Tom, > > I'd like to update Auth Service 1.1 according to WRAP '5.3 Username and Password Profile'. > > We have to add the following changes: > * use 'application/x-www-form-urlencoded' format for encoding request/response parameters (Auth Service supports XML and Protobuf); > * use SWT format for Access Token instead of SAML due to limited http header size, it's usually 8k-16k, but tomcat default is just 4k; > * use Access Token instead of Session Token, so doesn't use Seesion token at all; > * add refresh Access Token method according to 5.3.7 - 5.3.9; > * update request Access Token method according to 5.3.3 - 5.3.6. > > Paul, Valery are you agree? > > > However, WRAP doesn't define API for provisioning and updating user account, so we may leave it as is (using XML/Protobuf), or redefine it in WRAP way? > > -- > thanks, > Alexander Yuhimenko > > On Thu, 5 Nov 2009 20:43:49 -0800 > Tom Carroll <TCarroll@xxxxxxxxx> wrote: > > > Today I saw the WRAP protocol [1] presented at IIW. WRAP is a proposed new version of OAuth that separates the authentication service from the protected resource. If you take a look at WRAP's "username-password" profile, it looks incredibly similar to our Auth Service 1.1. It even contemplates that the client would have been provisioned with a unique identifier (eg 'serialized selector'), but doesn't get into the details of how this would happen, since the protect resource doesn't need to know anything about that. > > > > One difference I see is that in Higgins Authn Svc 1.1, the Access Token (AT) is exchanged for a Session Token at the protected resource, while in WRAP, the AT is sent with every request, and the protected resource just responds. There is no session - it is stateless. Other than that, it seems virtually identical, just a matter of naming conventions. > > > > Anyway, I was thinking that it might make sense to normalize the Authn Service 1.1 protocol to match a profile of the WRAP protocol, or perhaps suggest tweaks or a new profile to WRAP that fits our needs if the un/pw profile doesn't quite fit. It would be good to take a broader community approach, rather than a Higgins-only approach. > > > > [1] http://groups.google.com/group/WRAP-WG > > > > > > _______________________________________________ > higgins-dev mailing list > higgins-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/higgins-dev > ]]> Wed, 18 Nov 2009 14:58:15 GMT http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06126.html AYuhimenko@xxxxxxx (Alexander Yuhimenko) [higgins-dev] Help invoking the RCP identity selector from a web browser http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06125.html Hello, I am working on a prototype and am using the Java RCP Selector 1.0. I followed the directions at http://wiki.eclipse.org/Build_the_Eclipse_RCP_selector_package and http://wiki.eclipse.org/Build_the_Higgins_browser_extension_for_IE to build the binar... Hello,
I am working on a prototype and am using the Java RCP Selector 1.0.
I followed the directions at
http://wiki.eclipse.org/Build_the_Eclipse_RCP_selector_package and
http://wiki.eclipse.org/Build_the_Higgins_browser_extension_for_IE to build
the binaries successfully.
Then I followed the deployment directions at
http://wiki.eclipse.org/RCP_Selector_1.0#Deployer_Perspective.

I am able to start the program with the following command just fine and
connect to a card store I created. "C:\workspace\testing\eclipse>java -cp
C:\workspace\testing\eclipse\org.eclipse.equinox.launcher_1.0.101.R34x_v2008
0819.jar org.eclipse.core.launcher.Main -application
org.eclipse.higgins.crpps.application -debug -console -consolelog"

My question is how does the dll invoke this program? I understand we
changed the reg entry and registered the dll but is there a special location
and spot I need to register this command? I have been unsuccessful invoking
the selector from the browser(IE) from any site that uses info cards. 

Any ideas or am I missing something?


Thanks,


Kevin Steuer Jr



]]> Wed, 18 Nov 2009 03:35:13 GMT http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06125.html ksteuer@xxxxxxx (Kevin Steuer Jr) [higgins-dev] updates to util.saml and util.saml.test http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06124.html
I have committed contributions by Anders Domeij of Logica (logica.com) according to these bugzilla entries:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=295042
https://bugs.eclipse.org/bugs/show_bug.cgi?id=295045

The updates include:
- A cleaner separation of SAML 1 and SAML 2 classes
- Fixed and added unit tests which now run without failures
- Added implementation of previously unsupported SAML elements, such as LogoutReqest and LogoutRequestResponse

I have updated our test deployment of the SAML2 IdP at http://graceland.parityinc.net/saml2idp-test/ with the new code and it still runs fine. If someone else's code also depends on util.saml, you may want to test it, but I don't expect any problems.

Thanks a lot Anders!

Markus

On Fri, Nov 13, 2009 at 4:17 AM, Domeij, Anders <anders.domeij@xxxxxxxxxx> wrote:

Hello Markus,

 

Finally,

I have just opened 2 bugs in Bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=295042 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=295045.

I’ve attached the source files with the bug fixes to the first one.

 

I’ve also left a message in the dev mailing list.

 

If you have any comments or questions feel free tol mail me.

 

Rgds

/Anders

 

From: Markus Sabadello [mailto:markus.sabadello@xxxxxxxxx]
Sent: den 21 oktober 2009 14:47


To: Domeij, Anders
Subject: Re: Higgins SAML2 IdP

 

Not right now.. I'll try to take a look later this week..

Markus

On Wed, Oct 21, 2009 at 2:32 PM, Domeij, Anders <anders.domeij@xxxxxxxxxx> wrote:

Do you have time to test it before I ‘go formal’

 

From: Markus Sabadello [mailto:markus.sabadello@xxxxxxxxx]
Sent: den 21 oktober 2009 14:25


To: Domeij, Anders
Subject: Re: Higgins SAML2 IdP

 

Hello,



Cool, sounds great. Could you please do the following:

1. Go to https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Higgins&format=guided. Log in or create a Bugzilla account if you don't have one.
2. Create a new bug for Higgins. Select "Utilities" in the "Component" list.
3. Fill out some of the text fields that make sense, e.g. just copy&paste your e-mail.
4. After the bug is filed, attach the 2 files to the bug.
5. Then send a message to the Higgins dev list (not just me), if possible with the bug ID.

Sorry, but that's the formal process according to Eclipse rules..

I can then take a look and check in the changes :)

thanks
Markus

On Wed, Oct 21, 2009 at 1:03 PM, Domeij, Anders <anders.domeij@xxxxxxxxxx> wrote:

Hello Marcus,

 

I’m sending you the source trees (zipped) for org.eclipse.higgins.util.saml & org.eclipse.higgins.util.saml.test.

 

There have been many small changes in many files J

 

The XML generated for different SAML elements is now more strict so that the individual elements can be tested with JUnit.

As far as the JUnit tests being all-inclusive and relevant, I have’t had the time nor do I have enough experience of SAML usage to asses their value. At least now they run….

 

As for SAML ver 2

I have added the SAML2LogoutRequest/Response elements as described in the Web SSO Profile.

 

Hope you have time to diff and look at it.

Comments appreciated

 

When (if) you add the changes to SVN please let me know so I can check them out again. For the time being I’ll keep using my own copies in the project I’m currently working on.

 

Rgds

/Anders

 

 


]]> Fri, 13 Nov 2009 22:41:29 GMT http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06124.html markus.sabadello@xxxxxxx (Markus Sabadello) [higgins-dev] No higgins-dev call today http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06123.html Title: No higgins-dev call today Title: No higgins-dev call today ]]> Thu, 12 Nov 2009 14:09:57 GMT http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06123.html ptrevithick@xxxxxxx (Paul Trevithick) Re: [higgins-dev] Normalize Authn Service 1.1 to WRAP? http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06122.html Thanks Tom, I'd like to update Auth Service 1.1 according to WRAP '5.3 Username and Password Profile'. We have to add the following changes: * use 'application/x-www-form-urlencoded' format for encoding request/response parameters (Auth Service supports XM... Thanks Tom, I'd like to update Auth Service 1.1 according to WRAP '5.3 Username and Password Profile'. We have to add the following changes: * use 'application/x-www-form-urlencoded' format for encoding request/response parameters (Auth Service supports XML and Protobuf); * use SWT format for Access Token instead of SAML due to limited http header size, it's usually 8k-16k, but tomcat default is just 4k; * use Access Token instead of Session Token, so doesn't use Seesion token at all; * add refresh Access Token method according to 5.3.7 - 5.3.9; * update request Access Token method according to 5.3.3 - 5.3.6. Paul, Valery are you agree? However, WRAP doesn't define API for provisioning and updating user account, so we may leave it as is (using XML/Protobuf), or redefine it in WRAP way? -- thanks, Alexander Yuhimenko On Thu, 5 Nov 2009 20:43:49 -0800 Tom Carroll <TCarroll@xxxxxxxxx> wrote: > Today I saw the WRAP protocol [1] presented at IIW. WRAP is a proposed new version of OAuth that separates the authentication service from the protected resource. If you take a look at WRAP's "username-password" profile, it looks incredibly similar to our Auth Service 1.1. It even contemplates that the client would have been provisioned with a unique identifier (eg 'serialized selector'), but doesn't get into the details of how this would happen, since the protect resource doesn't need to know anything about that. > > One difference I see is that in Higgins Authn Svc 1.1, the Access Token (AT) is exchanged for a Session Token at the protected resource, while in WRAP, the AT is sent with every request, and the protected resource just responds. There is no session - it is stateless. Other than that, it seems virtually identical, just a matter of naming conventions. > > Anyway, I was thinking that it might make sense to normalize the Authn Service 1.1 protocol to match a profile of the WRAP protocol, or perhaps suggest tweaks or a new profile to WRAP that fits our needs if the un/pw profile doesn't quite fit. It would be good to take a broader community approach, rather than a Higgins-only approach. > > [1] http://groups.google.com/group/WRAP-WG > > ]]> Mon, 09 Nov 2009 13:17:15 GMT http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06122.html AYuhimenko@xxxxxxx (Alexander Yuhimenko) [higgins-dev] Normalize Authn Service 1.1 to WRAP? http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06121.html Today I saw the WRAP protocol [1] presented at IIW. WRAP is a proposed new version of OAuth that separates the authentication service from the protected resource. If you take a look at WRAP&#8217;s &#8220;username-password&#8221; profile, it looks incredibly similar to our...

Today I saw the WRAP protocol [1] presented at IIW. WRAP is a proposed new version of OAuth that separates the authentication service from the protected resource. If you take a look at WRAP’s “username-password” profile, it looks incredibly similar to our Auth Service 1.1. It even contemplates that the client would have been provisioned with a unique identifier (eg ‘serialized selector’), but doesn’t get into the details of how this would happen, since the protect resource doesn’t need to know anything about that.

 

One difference I see is that in Higgins Authn Svc 1.1, the Access Token (AT) is exchanged for a Session Token at the protected resource, while in WRAP, the AT is sent with every request, and the protected resource just responds. There is no session – it is stateless. Other than that, it seems virtually identical, just a matter of naming conventions.

 

Anyway, I was thinking that it might make sense to normalize the Authn Service 1.1 protocol to match a profile of the WRAP protocol, or perhaps suggest tweaks or a new profile to WRAP that fits our needs if the un/pw profile doesn’t quite fit. It would be good to take a broader community approach, rather than a Higgins-only approach.

 

[1] http://groups.google.com/group/WRAP-WG

 

 

]]> Fri, 06 Nov 2009 04:43:42 GMT http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06121.html TCarroll@xxxxxxx (Tom Carroll) [higgins-dev] Project meta data is out of date for technology.higgins http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06120.html Mary, Paul, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * Project home page is not a Phoenix-style page (projecturl = http:/... Mary, Paul, Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * Project home page is not a Phoenix-style page (projecturl = http://www.eclipse.org/higgins/) ]]> Thu, 05 Nov 2009 05:00:22 GMT http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06120.html emo@xxxxxxx (portal on behalf of emo) Re: [higgins-dev] IdAS changes proposal http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06119.html Title: Re: [higgins-dev] IdAS changes proposal Hello, I commited a new IdAS API, implementation of a new model and a new RDF CP into Eclipse SVN. The following projects were added: 1. org.eclipse.higgins.idas.api2 - new IdAS/model API; main changes - e... Title: Re: [higgins-dev] IdAS changes proposal
Hello,
 
I commited a new IdAS API, implementation of a new model and a new RDF CP into Eclipse SVN. The following projects were added:
 
1. org.eclipse.higgins.idas.api2 - new IdAS/model API; main changes - eleminating of BlankEntity, entityId (attribute of Entity) and IFilter interfaces.
2. org.eclipse.higgins.idas.cp.model2 and org.eclipse.higgins.idas.cp.model2.test - implementation of a new model;
3. org.eclipse.higgins.idas.cp.rdf2 and org.eclipse.higgins.idas.cp.rdf2.test - implementation of new IdAS API.
4. org.eclipse.higgins.idas.common2 and org.eclipse.higgins.idas.registry2 - duplicates of the same previous projects which need to be used with a new API. IdAS registry was duplicated to provide the possibility to use both IdAS API in the same application.
 
Thanks,
Sergey Lyakhov
----- Original Message -----
Sent: Friday, October 16, 2009 5:49 PM
Subject: Re: [higgins-dev] IdAS changes proposal

Paul,
 
> 1. We define a new .api2 that replaces the IFilter stuff with SPARQL.
 
Yes, replaces IFilter, removes IBlankEntity, and (perhaps) replaces IModel interfaces with something you were going to propose.
 
> 2. We define a sub-set of SPARQL that could be used with .api2 for purposes of creating an adaptor CP, yet would still have acceptable performance.
 
Yes. Also, because SPARQL allows to query literals, I suppose it would be useful to query as full Entities as separate attribute values. I suppose we should add two methods to IContext:
a) Iterator getEntities(String sparql) - returns iterator of IEntity;
a) Iterator getValues(String sparql) - returns iterator of List, where list contains data objects;
 
 
> We would implement the full new .api2 in any new CPs that are based on RDF technology directly (e.g. Jena) or on something like RDF (e.g. XDI).
 
Yes.
 
> We will inform Mary Ruddy ASAP about any new tech (e.g. ARQ or newer versions of Jena) we want to use for this new CP so we can get the Eclipse legal process going.
 
Yes, of course.
 
Thanks,
Sergey Lyakhov
----- Original Message -----
Sent: Thursday, October 15, 2009 9:58 PM
Subject: Re: [higgins-dev] IdAS changes proposal

Sergey,

Are you proposing that:
  1. We define a new .api2 that replaces the IFilter stuff with SPARQL.
  2. We define a sub-set of SPARQL that could be used with .api2 for purposes of creating an adaptor CP, yet would still have acceptable performance.
  3. We would implement the full new .api2 in any new CPs that are based on RDF technology directly (e.g. Jena) or on something like RDF (e.g. XDI). [Of course as you know Jena has an add-on (ARQ) SPARQL processor, so if we use ARQ + Jena we?re ?done? from a raw functionality point of view?we just have to adapt to the IdAS .api2]
  4. We will inform Mary Ruddy ASAP about any new tech (e.g. ARQ or newer versions of Jena) we want to use for this new CP so we can get the Eclipse legal process going.

--Paul

On 10/15/09 12:16 PM, "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> wrote:
Paul,

Actually, I did mean the following:
 
1. Main point - it is difficult to implement full SPARQL specification in Upper CP because it is really difficult task.  In other words, we can implement "restricted" SPARQL functionality where some queries will not work.
 
2. (as you understood)  some semantics can?t be expressed in the .api CP using .api.IFilter. For such queries (where regex() is present for an example) Upper CP will work solwly.
 
Thanks,
Sergey Lyakhov

----- Original Message -----
 
From:  Paul  Trevithick <mailto:ptrevithick@xxxxxxxxx>  
 
To: higgins-dev <mailto:higgins-dev@xxxxxxxxxxx>  
 
Cc: Vadym Synakh <mailto:synakh@xxxxxxxxxxxxxx>  ; Paul Trevithick <mailto:paul@xxxxxxxxxxxxx>   ; Igor  Tsinman <mailto:itsinman@xxxxxxxxxxxxx>  
 
Sent: Thursday, October 15, 2009 6:41  PM
 
Subject: Re: [higgins-dev] IdAS changes  proposal
 

Sergey,

Let me see if I understand what you are  saying. Are you saying this:

 
  • We could  implement the .api2 CP as shown below, but it will be difficult to implement  in it many aspects of SPARQL because the semantics can?t be expressed in the  .api CP using .api.IFilter.

If yes, then I was  thinking was different. I was not assuming that .api.IFilter semantics  were sufficient to express the SPARQL semantics directly. I was, however,  assuming that the upper .api2 CP may in some cases have to read (using lower  .api CP) many, most, and sometimes ALL (!) entities from the lower .api CP and  perform the SPARQL WHERE filtering algorithms itself. And this is why I was  saying that the performance may be very bad when this two layer approach is  taken.

I?m looking for a solution that allows the old .api to be  maintained and to be able to reuse these ?old? CPs by adapting them with the  upper .api2 CP. If the performance is too bad, then the developer can  implement a ?native? (not two layered) CP using .api2.

--Paul

On  10/15/09 11:27 AM, "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx>  wrote:

 
Paul,

> Do you  think it is practical to implement this:
>  +----------------------------------------+
> | Upper CP that  implements .idas.api2    |
> | SPARQL api but  read/writes ?raw?       |
> |  entities/attributes from lower CP      |
>  +----------------------------------------+
>  +----------------------------------------+
> | Lower CP implements  existing .idas.api |
>  +----------------------------------------+

I think we are able to implement basic aspects of SPARQL which  will satisfy our requirements. However it will be difficult to implement  many aspects of SPARQL such as FILTER functions in WHERE clause (moreover,  there is no any equivalent of those functions in idas.api.IFilter). For  example, if I want to use regex(..) SPARQL FILTER function in  Upper CP, I'll need first select all entities from old CP,  and than make additional check selecting entities which conform to the  regexp.

Thanks,
Sergey Lyakhov
 

----- Original Message -----  
 
From:  Paul  Trevithick <mailto:ptrevithick@xxxxxxxxx>   
 
To: higgins-dev <mailto:higgins-dev@xxxxxxxxxxx>   
 
Cc: Vadym Synakh <mailto:synakh@xxxxxxxxxxxxxx>   ; Paul Trevithick <mailto:paul@xxxxxxxxxxxxx>    ; Igor  Tsinman <mailto:itsinman@xxxxxxxxxxxxx>   
 
Sent: Thursday, October 15, 2009 4:31   PM
 
Subject: Re: [higgins-dev] IdAS changes   proposal
 

Sergey,

Hmmm, this is a tough one.  We don?t  want to lose the investments in the existing CPs (the old  .idas.api). Yet we  don?t want to create a burden for new CP  developers. While we mull this over,  I have a question. Do you think  it is practical to implement  this:

 
 
+----------------------------------------+
| Upper  CP  that implements .idas.api2    |
| SPARQL api  but  read/writes ?raw?       |
|   entities/attributes from lower CP        |
+----------------------------------------+
+----------------------------------------+
|   Lower CP implements existing .idas.api   |
+----------------------------------------+

If so, then we could maintain both the lower and the  upper  APIs. Any CP that didn?t want to support the .api2 (upper api)  wouldn?t have  to, there because they could use the upper ?adapter?  CP. The result might be  very slow, but at least it (might) work. And  if good SPARQL performance was  required, then the CP would be force  to do a native implementation of  .idas.api2.

[One really  interesting benefit of implementing SPARQL is  that with the above  adapter plus a web service front end, we can expose any  IdAS data  source as a SPARQL endpoint. Then we?d have XDI and SPARQL endpoints   for the Attribute Service. The Linked Object Data (LOD) semweb folks  are  creating lots of SPARQL endpoints?we?d dovetail with these   efforts.

--Paul



On  10/15/09 6:23 AM, "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx>   wrote:

 
 
Paul,

Sorry for   delay.

> 3. Jim Sermersheim  invented  IFilter because we needed something and SPARQL wasn?t yet  established. Now  that it is, I wonder if we shouldn?t give it  another look  
 
It would  be very convinient to use SPARQL for   RDF-based context  providers (like jena CP). However it would be hard  to implement  all aspects of SPARQL for context providers which are not based  on  RDF (JNDI, XML, Hibernate etc.).
> When you go to make these   changes, it will be critical to load into your workbench every  possible  context
> provider that you can find so that you  can fix them so that  they don?t all break.

It  will take a lot of work to  implement new filter/model for all providers. So,  I suppose there  is a sence to put new IdAS interfaces into a new project  (like  org.eclipse.higgins.idas.api2) and than fix all providers to support    these new interfaces. What do you think about   this?
 
Thanks,
Sergey  Lyakhov
 
 

----- Original Message -----   
 
From:  Paul  Trevithick <mailto:ptrevithick@xxxxxxxxx>    
 
To: higgins-dev <mailto:higgins-dev@xxxxxxxxxxx>    
 
Cc: Vadym Synakh <mailto:synakh@xxxxxxxxxxxxxx>    ; Paul Trevithick <mailto:paul@xxxxxxxxxxxxx>     ; Igor  Tsinman <mailto:itsinman@xxxxxxxxxxxxx>    
 
Sent: Monday, September 28, 2009 3:11    AM
 
Subject: Re: [higgins-dev] IdAS  changes   proposal
 

Sergey,

My   responses:
 
 
 
  1. agree         
  2. agree         
  3. Jim   Sermersheim  invented IFilter because we needed something  and  SPARQL wasn?t yet  established. Now that it is, I  wonder if we  shouldn?t give it another look        
  4. (4.1):  short   answer: no. Longer answer: cdm.owl is an attempt  to approximate in  owl  concepts that cannot be directly  operationalized in real  RDF/OWL based  systems. Only  higgins.owl should be imported and  used. Cdm.owl is just an   attempt at explanation. It can be  ignored. (4.2) A lot  of OWL URLS end in  .owl, but it isn?t a firm  requirement  or  convention.

When you go to  make  these changes, it will be  critical to load into your  workbench every  possible context provider that you  can  find so that you can fix them  so that they don?t all break.   

--Paul

On 9/23/09 12:07  PM, "Sergey  Lyakhov" <slyakhov@xxxxxxxxxxxxxx>    wrote:

 
 
 
Paul,

I suppose,  cdm:entityId is redundant and we can use rdf:ID   instead.  As a result:

1.1. In this case  IEntity.getEntityID() will retun   rdf:ID.
1.2. In case of blank  entity (previously  known as a complex  value) it should return  null.
1.3.  entityId attribute will be   eliminated.

I suppose we need to  do the following changes to IdAS  interfaces  to be  compatible with CDM:

2.1. BlankEntity  class  has  been eliminated from cdm.owl. So, I suppose we  need to do the  same for IdAS  interfaces and replace  IBlankEntity with IEntity  (eliminate IBlankEntity   interface).
 
Because there is  no any  difference between entity  and complex value, we can define   the following:

2.2. If Entity has  been  created by  IContext.addEntity(entityType, entityID)  method, it should always   have entityID (should not be a  blank entity). In other words, a  unique value  should be  generated by a context and used as  entityId, if no entityId   passed.
2.3. If Entity has been  created by  IAttribute.addValue(URI)  method, it should be a blank   entity.
2.4. If Entity has been added by    IAttribute.addValue(IAttributeValue) it should be the  same type as  passed  entity. If passed entity is a blank  entity, new blank  entity should be  created as a copy of  passed, otherwise a  reference to the existent (non   blank) entity should be  created.
2.5. When Entity is  deleted, all its  subentities which  are a blank entity  should be deleted  too.
 
Also we  need more  flex IFilter API:
 
3.1.  IFilter should be   able to query both types of entities as blank as   usual.
3.2.  IFilter should be able to query a  separate value (entity or  simple  value) of any nesting  level, not only direct attributes of    Entity.
 
Also I have some notes about   CDM:
 
4.1.  CDM.owl contains entityRelation  and  contextRelation object properties. Do we  need to  reflect them in  IdAS interfaces?
4.2. Namespase of cdm.owl  http://www.eclipse.org/higgins/ontologies/2008/6/cdm.owl    ends with .owl. Is it correct?

Thanks,
Sergey    Lyakhov



 
 
 


_______________________________________________
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

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
]]> Wed, 04 Nov 2009 18:21:05 GMT http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06119.html slyakhov@xxxxxxx (Sergey Lyakhov) [higgins-dev] No Higgins call this week or next due to IIW http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06118.html There is no Higgins developers call this week as we prepare for Internet Identity World (IIW) or next week when most of us are at IIW.

There is no Higgins developers call this week as we prepare for Internet Identity World (IIW) or next week when most of us are at IIW. 

]]> Wed, 28 Oct 2009 15:25:29 GMT http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg06118.html mary@xxxxxxx (Mary Ruddy)