Nabble - Higgins - Dev

Need Help in deploying RPPS-Web

2009-11-27T11:30:18Z

Hi All,

I need some help in deploying the RPPS-Web application. We see the following error after deploying the application:

ERROR [main] RppsService$4.initialValue (RppsService.java:336) - java.lang.ClassNotFoundException: org.eclipse.higgins.idas.cp.hb.impl.ContextFactory

I have attached a few files for further information including
- Stack Trace
- User.xml - This file has a reference to the class that Tomcat is not able to find
- context.xml

I will appreciate if anyone can provide any pointers in resolving the errors.

--
Regards,
Daljeet Singh

27 Nov 2009 14:16:49,479 ERROR [main] ConfigurationHandler.configure (ConfigurationHandler.java:439) - org.eclipse.higgins.idas.cp.hb.impl.ContextFactory

27 Nov 2009 14:16:49,488 ERROR [main] RppsService$4.initialValue (RppsService.java:336) - java.lang.ClassNotFoundException: org.eclipse.higgins.idas.cp.hb.impl.ContextFactory

java.lang.ClassNotFoundException: org.eclipse.higgins.idas.cp.hb.impl.ContextFactory
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:316)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at org.eclipse.higgins.configuration.common.ConfigurableComponentFactoryHelper.getClassByName(ConfigurableComponentFactoryHelper.java:160)
at org.eclipse.higgins.configuration.common.ConfigurableComponentFactoryHelper.getInstanceFromClassName(ConfigurableComponentFactoryHelper.java:36)
at org.eclipse.higgins.configuration.xml.ClassInstanceHandler.getSetting(ClassInstanceHandler.java:82)
at org.eclipse.higgins.configuration.xml.MapHandler.getSetting(MapHandler.java:108)
at org.eclipse.higgins.configuration.xml.ConfigurationHandler.configure(ConfigurationHandler.java:425)
at org.eclipse.higgins.configuration.xml.ConfigurationHandler.configure(ConfigurationHandler.java:291)
at org.eclipse.higgins.rpps.core.impl.RppsService$4.initialValue(RppsService.java:331)
at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:141)
at java.lang.ThreadLocal.get(ThreadLocal.java:131)
at org.eclipse.higgins.rpps.core.impl.RppsService.userIdentifierExists(RppsService.java:4477)
at org.eclipse.higgins.rpps.servlet.InitializeServlet.init(InitializeServlet.java:39)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4149)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4458)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
27 Nov 2009 14:16:49,492 ERROR [main] InitializeServlet.init (InitializeServlet.java:42) - java.lang.NullPointerException

java.lang.NullPointerException
at org.eclipse.higgins.rpps.core.impl.RppsService.userIdentifierExists(RppsService.java:4477)
at org.eclipse.higgins.rpps.servlet.InitializeServlet.init(InitializeServlet.java:39)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4149)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4458)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
27 Nov 2009 14:16:50,791 ERROR [main] WSDDService.deployTypeMapping (WSDDService.java:560) - Unable to deploy typemapping: {http://tobj.core.rpps.higgins.parityinc.net}FormTO

java.lang.ClassNotFoundException: net.parityinc.higgins.rpps.core.tobj.FormTO
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1387)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
at org.apache.axis.utils.ClassUtils$2.run(ClassUtils.java:187)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.axis.utils.ClassUtils.loadClass(ClassUtils.java:160)
at org.apache.axis.utils.ClassUtils.forName(ClassUtils.java:100)
at org.apache.axis.deployment.wsdd.WSDDTypeMapping.getLanguageSpecificType(WSDDTypeMapping.java:183)
at org.apache.axis.deployment.wsdd.WSDDService.deployTypeMapping(WSDDService.java:542)
at org.apache.axis.deployment.wsdd.WSDDService.initTMR(WSDDService.java:253)
at org.apache.axis.deployment.wsdd.WSDDService.<init>(WSDDService.java:233)
at org.apache.axis.deployment.wsdd.WSDDDeployment.<init>(WSDDDeployment.java:192)
at org.apache.axis.deployment.wsdd.WSDDDocument.setDocument(WSDDDocument.java:139)
at org.apache.axis.deployment.wsdd.WSDDDocument.<init>(WSDDDocument.java:65)
at org.apache.axis.configuration.FileProvider.configureEngine(FileProvider.java:179)
at org.apache.axis.AxisEngine.init(AxisEngine.java:172)
at org.apache.axis.AxisEngine.<init>(AxisEngine.java:156)
at org.apache.axis.server.AxisServer.<init>(AxisServer.java:88)
at org.apache.axis.server.DefaultAxisServerFactory.createServer(DefaultAxisServerFactory.java:109)
at org.apache.axis.server.DefaultAxisServerFactory.getServer(DefaultAxisServerFactory.java:73)
at org.apache.axis.server.AxisServer.getServer(AxisServer.java:73)
at org.apache.axis.transport.http.AxisServletBase.getEngine(AxisServletBase.java:185)
at org.apache.axis.transport.http.AxisServletBase.getOption(AxisServletBase.java:396)
at org.apache.axis.transport.http.AxisServletBase.init(AxisServletBase.java:112)
at org.apache.axis.transport.http.AxisServlet.init(AxisServlet.java:156)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4149)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4458)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:583)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
<Configuration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://higgins.eclipse.org/sts/Configuration" xmlns:htf="http://higgins.eclipse.org/sts/Configuration">
<SettingHandlers>
<SettingHandler Type="htf:map" Class="java.util.Map" Handler="org.eclipse.higgins.configuration.xml.MapHandler"/>
<SettingHandler Type="htf:list" Class="java.util.List" Handler="org.eclipse.higgins.configuration.xml.ListHandler"/>
<SettingHandler Type="xsd:string" Class="java.lang.String" Handler="org.eclipse.higgins.configuration.xml.StringHandler"/>
<SettingHandler Type="xsd:boolean" Class="java.lang.Boolean" Handler="org.eclipse.higgins.configuration.xml.BooleanHandler"/>
<SettingHandler Type="xsd:anyURI" Class="java.net.URI" Handler="org.eclipse.higgins.configuration.xml.URIHandler"/>
<SettingHandler Type="htf:file" Class="java.io.FileInputStream" Handler="org.eclipse.higgins.configuration.xml.FileHandler"/>
<SettingHandler Type="htf:singleton" Class="java.lang.Object" Handler="org.eclipse.higgins.configuration.xml.SingletonHandler"/>
<SettingHandler Type="htf:instance" Class="java.lang.Object" Handler="org.eclipse.higgins.configuration.xml.InstanceHandler"/>
<SettingHandler Type="htf:classinstance" Class="java.lang.Object" Handler="org.eclipse.higgins.configuration.xml.ClassInstanceHandler"/>
<SettingHandler Type="htf:classsingleton" Class="java.lang.Object" Handler="org.eclipse.higgins.configuration.xml.ClassSingletonHandler"/>
</SettingHandlers>
<Setting Name="UserProfile" Type="htf:map">
<Setting Name="ComponentSettings" Type="htf:map">

<Setting Name="IdentityAttributeService" Type="htf:map">
<Setting Name="ContextFactoryInstancesList" Type="htf:list">
<Setting Name="HibernateContextFactory" Type="htf:map">
<Setting Name="Instance" Type="xsd:string">HibernateContextFactory</Setting>
<Setting Name="ContextTypes" Type="htf:list">
<Setting Name="JenaContextType" Type="xsd:string">$context+hibernate</Setting>
</Setting>
</Setting>
</Setting>
<Setting Name="ContextIdsList" Type="htf:list">
<Setting Name="urn:userProfileContext" Type="htf:map">
<Setting Name="ContextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="ContextTypes" Type="htf:list">
<Setting Name="LDAPContextType" Type="xsd:string">$context+hibernate</Setting>
</Setting>
<Setting Name="ContextUris" Type="htf:list">
<Setting Name="DefaultContextUri" Type="xsd:anyURI">urn:Higgins-LDAP-Server</Setting>
</Setting>
<Setting Name="context.performauthentication" Type="xsd:string">false</Setting>
<Setting Name="context.uri" Type="xsd:anyURI">urn:userProfileContext/</Setting>
<Setting Name="schema.url" Type="xsd:anyURI">http://www.eclipse.org/higgins/ontologies/2008/7/userProfile</Setting>
<Setting Name="schema.file" Type="xsd:string">/org/eclipse/higgins/userprofile/idas/userProfile.owl</Setting>
<Setting Name="hibernateConfig" Type="htf:map">
<Setting Name="hibernate.dialect" Type="xsd:string">org.hibernate.dialect.MySQLDialect</Setting>
<Setting Name="hibernate.connection.driver_class" Type="xsd:string">com.mysql.jdbc.Driver</Setting>

<Setting Name="hibernate.connection.url" Type="xsd:string">jdbc:mysql://localhost/higgins_up_20090115?autoReconnect=true</Setting>
<Setting Name="hibernate.connection.username" Type="xsd:string">root</Setting>
<Setting Name="hibernate.connection.password" Type="xsd:string">higgins</Setting>



<Setting Name="hibernate.show_sql" Type="xsd:string">true</Setting>

<Setting Name="hibernate.default_entity_mode" Type="xsd:string">dom4j</Setting>
<Setting Name="hibernate.connection.autocommit" Type="xsd:string">false</Setting>
<Setting Name="hibernate.format_sql" Type="xsd:string">true</Setting>


<Setting Name="connection.pool_size" Type="xsd:string">5</Setting>

</Setting>
</Setting>
</Setting>
</Setting>

<Setting Name="UserAccountService" Type="htf:map">
<Setting Name="contextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="user" Type="xsd:string">profile_user</Setting>
<Setting Name="password" Type="xsd:string">password</Setting>
</Setting>

<Setting Name="UserProfileService" Type="htf:map">
<Setting Name="contextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="user" Type="xsd:string">profile_user</Setting>
<Setting Name="password" Type="xsd:string">password</Setting>
</Setting>

<Setting Name="UserLoginService" Type="htf:map">

<Setting Name="LoginModules" Type="htf:list">
<Setting Name="UserNamePasswordModule" Type="htf:map">
<Setting Name="className" Type="xsd:string">org.eclipse.higgins.user.idas.loginModule.UserNamePasswordModule</Setting>

<Setting Name="controlFlag" Type="xsd:string">SUFFICIENT</Setting>
<Setting Name="options" Type="htf:map">
<Setting Name="contextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="user" Type="xsd:string">profile_user</Setting>
<Setting Name="password" Type="xsd:string">password</Setting>
</Setting>
</Setting>
<Setting Name="IsapMd5PasswordModule" Type="htf:map">
<Setting Name="className" Type="xsd:string">org.eclipse.higgins.user.idas.loginModule.IsapMd5PasswordModule</Setting>

<Setting Name="controlFlag" Type="xsd:string">SUFFICIENT</Setting>
<Setting Name="options" Type="htf:map">
<Setting Name="contextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="user" Type="xsd:string">profile_user</Setting>
<Setting Name="password" Type="xsd:string">password</Setting>
</Setting>
</Setting>
<Setting Name="PrivateUserINumberModule" Type="htf:map">
<Setting Name="className" Type="xsd:string">org.eclipse.higgins.user.idas.loginModule.PrivateUserINumberModule</Setting>

<Setting Name="controlFlag" Type="xsd:string">SUFFICIENT</Setting>
<Setting Name="options" Type="htf:map">
<Setting Name="contextId" Type="xsd:string">urn:userProfileContext</Setting>
<Setting Name="user" Type="xsd:string">profile_user</Setting>
<Setting Name="password" Type="xsd:string">password</Setting>
</Setting>
</Setting>
</Setting>
</Setting>
</Setting>
<Setting Name="HibernateContextFactory" Type="htf:classinstance">org.eclipse.higgins.idas.cp.hb.impl.ContextFactory</Setting>
<Setting Name="IdentityAttributeService" Type="htf:classsingleton">org.eclipse.higgins.idas.registry.IdASRegistry</Setting>
<Setting Name="UserLoginService" Type="htf:classinstance">org.eclipse.higgins.user.login.LoginService</Setting>
<Setting Name="UserAccountService" Type="htf:classinstance">org.eclipse.higgins.user.idas.account.AccountService</Setting>
<Setting Name="UserProfileService" Type="htf:classinstance">org.eclipse.higgins.user.idas.profile.ProfileService</Setting>
</Setting>
</Configuration>

<?xml version="1.0" encoding="UTF-8"?>

<Context path="/rpps-axis">


<Parameter name="CacheConfigurationBase" value="/usr/share/higgins/cache"/>
<Parameter name="CacheConfigurationFile" value="CacheConfiguration.xml" />


<Environment name="HigginsConfigurationBase" value="/usr/share/higgins" type="java.lang.String" override="false"/>
<Environment name="HigginsConfigurationFile" value="User.xml" type="java.lang.String" override="false"/>

<Environment name="AccessTokenMaxIdleTime" value="1800" type="java.lang.String" override="false" />
<Environment name="AccessTokenMaxLifeTime" value="86400" type="java.lang.String" override="false" />
<Environment name="AuthServiceEhcacheCnfUrl" value="/usr/share/higgins/cache/ehcache.xml" type="java.lang.String" override="false" />



<Resource name="rpps/cards" auth="Container" type="javax.sql.DataSource"
maxActive="150" maxIdle="30" maxWait="-1" removeAbandoned="true"
removeAbandonedTimeout="180" logAbandoned="true" username="higgins_rpps"
password="higginsRPPS" driverClassName="org.gjt.mm.mysql.Driver"
url="jdbc:mysql://rh152.sohosmart.net/higgins_TestCards?autoReconnect=true" />


<Resource name="rpps/up" global="rpps/up" auth="Container"
type="javax.sql.DataSource" username="higgins_rpps" password="higginsRPPS"
driverClassName="org.gjt.mm.mysql.Driver"
url="jdbc:mysql://rh152.sohosmart.net/higgins_up_rh156?autoReconnect=true&useUnicode=yes&characterEncoding=UTF-8"
removeAbandoned="true" removeAbandonedTimeout="180" logAbandoned="true"
maxActive="200" maxIdle="50" validationQuery="Select 1" />


<Resource name="cardsync/meta_hb" global="cardsync/meta_hb"
auth="Container" type="javax.sql.DataSource" username="higgins_cardsync"
password="password" driverClassName="org.gjt.mm.mysql.Driver"
url="jdbc:mysql://rh152.sohosmart.net/hcs_meta?autoReconnect=true&useUnicode=yes&characterEncoding=UTF-8"
maxActive="100" maxIdle="7" validationQuery="Select 1"
removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true" />

















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

[GTK Selector]Problem encountered under windows 7

2009-11-24T01:49:15Z

Hi,

I tested GTK Selector + Selector Switch under Windows 7 + IE8. I don’t look deeper but it seems that Identity Selector Switch is not able to call any selector through IE8 (tested with Card Space and GTK Selector). I think it’s not due to the switch selector itself but to the IE plug-in as everything works fine under Firefox 3.5.

Another point is that password are not saved under XP but are under windows 7 (using remember password on a card). Can it be due by the fact that a ‘Users repository’ is hard coded somewhere and does not exist on XP but does in Windows 7? In which file or registry are supposed to be stored password?

If you need more information I will be glade to provide it to you. Thanks in advance.

Best regards,

Thomas Pasquier
Gemalto

Tel: +33 1 55 01 60 69 - +33 6 81 59 85 83
6 rue de la Verriere
92197 Meudon Cedex

thomas.pasquier@...
www.gemalto.com

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

Re: IdAS changes proposal

2009-11-23T12:06:07Z

Re: [higgins-dev] IdAS changes proposal Sergey,

Since you, Valery and perhaps others think that having a model API would be much more convenient to use than directly navigating the entities/attributes, let’s keep the IModel interface (and related interfaces). But must align them with the underlying entities & attributes as described here [1]. I’ve updated [1] recently thus creating some mismatches. Please review [1] and let me know if anything is unclear as to what the semantics are supposed to be.

[BTW, I’m aware that the concept of display order is missing from [1] and it probably needs to be added. I’m thinking that it should be added as an attribute of a “class-scoped attribute class”].

--Paul

[1] http://wiki.eclipse.org/Higgins_Data_Model_1.1#Representation_of_Entity_and_Attribute_Classes

On 10/21/09 10:17 AM, "Sergey Lyakhov" <slyakhov@...> wrote:

Paul,

> What Jim and all of us talked about several months ago is to remove the special IModel interfaces completely,
> and just use the existing entities and attributes to describe entity classes and attribute definitions. In other words, recurse.

The main Jim's argument to rid IModel interfaces was to reuse alredy existent IEntity and IAttribute inerfaces. Actually, I already gave arguments a year ago, why the current model interfaces are more convenient:

1. The current model interfaces allow to represent many things obviously. Suppose, we need to expose the model of a simple value. If we used Jim's model, we'd represent simple value model via IEntity intrerface (which is confusing by itself). Than, to represent params of this simple value (there are many things in OWL1.1 like length, minLength, maxLength, pattern, etc.), this IEntity should contain an attribute for each of those params. In turn, the attribute should contain some ISimpleAttrValue with data of its parameter. From the other hand, the current IModel interface can reflect OWL in a more convenient way. If we need params of some simple value, we get an instance of ISimpleValueModel (either from IAttributeModel or from ISimpleAttrValue), and invoke its methods getLength(), getMinLength(), getMaxLength() etc.

2. IdAS interfaces (IEntity, IAttribute) have a lot of methods behind of getType() and getData() which are not used in Jim's model. I suppose these methods will confuse people which need to use a model.

3. Jim's model is flexible and could represent anything, but we do not need this, because we limited by OWL and need to describe things which OWL provides. IModel, in turn, could be disigned to reflect OWL constructs handy.

Thanks,
Sergey Lyakhov

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

From: Paul Trevithick <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...> ; Paul Trevithick <paul@...> ; Igor Tsinman <itsinman@...>

Sent: Monday, October 19, 2009 10:55 PM

Subject: Re: [higgins-dev] IdAS changes proposal

What Jim and all of us talked about several months ago is to remove the special IModel interfaces completely, and just use the existing entities and attributes to describe entity classes and attribute definitions. In other words, recurse.

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

> 1. We define a new .api2 that replaces the IFilter stuff with SPARQL.
<snip>... replaces IModel interfaces with something you were going to propose.

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

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

No Higgins call this week or Nov 26 (US Thanksgiving)

2009-11-19T05:51:29Z

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

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

Re: Normalize Authn Service 1.1 to WRAP?

2009-11-18T06:57:17Z

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@...> 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@...> 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@...
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>

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

Help invoking the RCP identity selector from a web browser

2009-11-17T19:34:33Z

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

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

updates to util.saml and util.saml.test

2009-11-13T14:41:29Z

Hello list,

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@...> 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@...]
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@...> wrote:

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

From: Markus Sabadello [mailto:markus.sabadello@...]
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@...> 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

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

No higgins-dev call today

2009-11-12T06:09:43Z

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

Re: Normalize Authn Service 1.1 to WRAP?

2009-11-09T05:16:16Z

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@...> 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@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Normalize Authn Service 1.1 to WRAP?

2009-11-05T20:43:49Z

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@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Project meta data is out of date for technology.higgins

2009-11-04T21:00:22Z

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/)

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

Re: IdAS changes proposal

2009-11-04T10:21:02Z

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 -----

From: slyakhov@...

To: higgins-dev@...

Cc: synakh@... ; paul@... ; itsinman@...

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 SPAR@... 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 -----

From: ptrevithick@...

To: higgins-dev@...

Cc: synakh@... ; paul@... ; itsinman@...

Sent: Thursday, October 15, 2009 9:58 PM

Subject: Re: [higgins-dev] IdAS changes proposal

Sergey,

Are you proposing that:

We define a new .api2 that replaces the IFilter stuff with SPARQL.
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.
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 were done from a raw functionality point of viewwe just have to adapt to the IdAS .api2]
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@...> 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 cant 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...> ; Paul Trevithick <paul@...>   ; Igor Tsinman <itsinman@...>

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 cant 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.

Im 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@...> 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...>   ; Paul Trevithick <paul@...>    ; Igor Tsinman <itsinman@...>

Sent: Thursday, October 15, 2009 4:31   PM

Subject: Re: [higgins-dev] IdAS changes   proposal

Sergey,

Hmmm, this is a tough one. We dont want to lose the investments in the existing CPs (the old .idas.api). Yet we dont 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 didnt want to support the .api2 (upper api) wouldnt 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 wed have XDI and SPARQL endpoints   for the Attribute Service. The Linked Object Data (LOD) semweb folks are creating lots of SPARQL endpointswed dovetail with these   efforts.

--Paul

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

Paul,

Sorry for   delay.

> 3. Jim Sermersheim invented IFilter because we needed something and SPARQL wasnt yet established. Now that it is, I wonder if we shouldnt 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 dont 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...>    ; Paul Trevithick <paul@...>     ; Igor Tsinman <itsinman@...>

Sent: Monday, September 28, 2009 3:11    AM

Subject: Re: [higgins-dev] IdAS changes   proposal

Sergey,

My   responses:

agree
agree
Jim   Sermersheim invented IFilter because we needed something and SPARQL wasnt yet established. Now that it is, I wonder if we shouldnt give it another look
(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 isnt 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 dont all break.

--Paul

On 9/23/09 12:07 PM, "Sergey Lyakhov" <slyakhov@...>    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@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

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

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

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

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

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

No Higgins call this week or next due to IIW

2009-10-28T08:19:59Z

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.

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

RE: UI Mockups for Authentication Service 1.1

2009-10-27T06:43:43Z

OK, changed mockups to show this approach - no CAPTCHA required for 'check availability' unless max_tries has been exceeded.

http://wiki.eclipse.org/Qt_Selector_Account_UI

-----Original Message-----
From: Alexander Yuhimenko [mailto:AYuhimenko@...]
Sent: Tuesday, October 27, 2009 9:07 AM
To: Higgins (Trust Framework) Project developer discussions
Cc: Tom Carroll
Subject: Re: [higgins-dev] UI Mockups for Authentication Service 1.1

Hello,

On Tue, 27 Oct 2009 05:43:36 -0700
Tom Carroll <TCarroll@...> wrote:

> >> But i think we have to use captcha with case #1 for "Check Availability" and "Confirm Email & Continue".
>
> Do we need to protect the "Check Availability" with a CAPTCHA, or just the "Confirm & Continue" transaction? If the former, then I think we need to break out CAPTCHA/Check Available into its own page. If the latter, then maybe we put it all into the one page.

I'd like to ask captcha for "Check Availability" every time, but it may irritate users. I guess, we may support "Check Availability" without captcha just few first times if server returns http status code 302 (user already exists), for example ask captcha each 3rd request.

>
> -----Original Message-----
> From: higgins-dev-bounces@... [mailto:higgins-dev-bounces@...] On Behalf Of Alexander Yuhimenko
> Sent: Monday, October 26, 2009 8:57 AM
> To: Higgins (Trust Framework) Project developer discussions
> Subject: Re: [higgins-dev] UI Mockups for Authentication Service 1.1
>
> Thanks Tom,
>
> But i think we have to use captcha with case #1 for "Check Availability" and "Confirm Email & Continue".
>
> Email is only one of possible ways (channel) to obtain one-time authentication code, but i couldn't find UI for using sms or something else.
>
> I believe we don't have to store passphrase on server, do we?
>
> --
> thanks,
> Alexander Yuhimenko
>
> ...
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@...
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>

--
thanks,
Alexander Yuhimenko

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

Re: UI Mockups for Authentication Service 1.1

2009-10-27T06:06:36Z

Hello,

On Tue, 27 Oct 2009 05:43:36 -0700
Tom Carroll <TCarroll@...> wrote:

> >> But i think we have to use captcha with case #1 for "Check Availability" and "Confirm Email & Continue".
>
> Do we need to protect the "Check Availability" with a CAPTCHA, or just the "Confirm & Continue" transaction? If the former, then I think we need to break out CAPTCHA/Check Available into its own page. If the latter, then maybe we put it all into the one page.

I'd like to ask captcha for "Check Availability" every time, but it may irritate users. I guess, we may support "Check Availability" without captcha just few first times if server returns http status code 302 (user already exists), for example ask captcha each 3rd request.

--
thanks,
Alexander Yuhimenko

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

Welcome Vitaliy as a new technology.higgins Committer

2009-10-27T05:59:03Z

technology.higgins Committers,
This automatically generated message marks the completion of all the legal
paperwork and webmaster provisioning for Vitaliy. Vitaliy is a new full
Committer on the technology.higgins project.

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

RE: UI Mockups for Authentication Service 1.1

2009-10-27T05:43:36Z

>> But i think we have to use captcha with case #1 for "Check Availability" and "Confirm Email & Continue".

Do we need to protect the "Check Availability" with a CAPTCHA, or just the "Confirm & Continue" transaction? If the former, then I think we need to break out CAPTCHA/Check Available into its own page. If the latter, then maybe we put it all into the one page.

-----Original Message-----
From: higgins-dev-bounces@... [mailto:higgins-dev-bounces@...] On Behalf Of Alexander Yuhimenko
Sent: Monday, October 26, 2009 8:57 AM
To: Higgins (Trust Framework) Project developer discussions
Subject: Re: [higgins-dev] UI Mockups for Authentication Service 1.1

Thanks Tom,

But i think we have to use captcha with case #1 for "Check Availability" and "Confirm Email & Continue".

Email is only one of possible ways (channel) to obtain one-time authentication code, but i couldn't find UI for using sms or something else.

I believe we don't have to store passphrase on server, do we?

--
thanks,
Alexander Yuhimenko

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

Re: UI Mockups for Authentication Service 1.1

2009-10-26T07:51:58Z

Re: [higgins-dev] UI Mockups for Authentication Service 1.1 Absolutely not. This passphrase is something that only the user knows and it never moves to the server. In that way even having access to the server is insufficient to gain access to the user’s data.

On 10/26/09 8:57 AM, "Alexander Yuhimenko" <AYuhimenko@...> wrote:

I believe we don't have to store passphrase on server, do we?

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

Re: UI Mockups for Authentication Service 1.1

2009-10-26T07:49:09Z

Re: [higgins-dev] UI Mockups for Authentication Service 1.1 Hi Tom,

I created this top-level solution page:

http://wiki.eclipse.org/Qt_Selector_1.1-Win

which has a link to:

http://wiki.eclipse.org/Qt_Selector_1.1_UI

which has a link to your new page (renamed):

http://wiki.eclipse.org/Qt_Selector_Account_UI

--Paul

On 10/24/09 8:11 PM, "Tom Carroll" <tcarroll@...> wrote:

Check ‘em out:

http://wiki.eclipse.org/Authentication_Service_1.1_UI

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

Re: UI Mockups for Authentication Service 1.1

2009-10-26T05:57:11Z

Thanks Tom,

But i think we have to use captcha with case #1 for "Check Availability" and "Confirm Email & Continue".

Email is only one of possible ways (channel) to obtain one-time authentication code, but i couldn't find UI for using sms or something else.

I believe we don't have to store passphrase on server, do we?

--
thanks,
Alexander Yuhimenko

On Sat, 24 Oct 2009 17:11:18 -0700
Tom Carroll <TCarroll@...> wrote:

> Check 'em out:
>
> http://wiki.eclipse.org/Authentication_Service_1.1_UI
>
>

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

UI Mockups for Authentication Service 1.1

2009-10-24T17:11:18Z

Draft Agenda for Higgins Developers call on Thursday, October 22 at Noon EDT

Check ‘em out:

http://wiki.eclipse.org/Authentication_Service_1.1_UI

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

Draft Agenda for Higgins Developers call on Thursday, October 22 at Noon EDT

2009-10-21T22:33:05Z

Draft Agenda for Higgins Developers call on Thursday, October 22 at Noon EDT LOGISTICS: Time: noon Eastern (16:00 UTC) U.S. Dial-in: 1-201-793-9022 passcode 7990866#

1) [Mary] “ABOUT THIS PROJECT” CLEANUP [1]

The description in the project summary [1] has been updated to align with the home page
Other project summary(about) page links have been updated where possible, and some committers marked as active.

2) [Paul, Alexander] AUTHENTICATION SERVICE [2]

Design review

3) [Paul, SergeyL] ATTRIBUTE SERVICE

Design review

[1] http://www.eclipse.org/projects/project_summary.php?projectid=technology.higgins
[2] http://wiki.eclipse.org/Authentication_Service_1.1
[3] http://wiki.eclipse.org/Attribute_Service_1.1

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

Commit rights for Maxim Kopeyka have been expired

2009-10-21T13:19:11Z

technology.higgins Committers,
Mary Ruddy has expired the commit rights for Maxim Kopeyka (mkopeyka). The
reason for this change is:

Maxim has been removed as he is no longer actively involved in the Higgins
project.

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

Mary Ruddy has been declared to be an active committer

2009-10-21T13:18:07Z

technology.higgins Committers,
Mary Ruddy has declared that Mary Ruddy (mruddy) is an active committer on
this project. The reason for this declaration is:

Mary continues to co-lead the Higgins project and contributes specifically
in the IPR, website and project management areas.
_______________________________________________
higgins-dev mailing list
higgins-dev@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Brian Walker has been declared to be an active committer

2009-10-21T13:13:06Z

technology.higgins Committers,
Mary Ruddy has declared that Brian Walker (bwalker) is an active committer
on this project. The reason for this declaration is:

Brian is actively managing the development of Higgins software.
_______________________________________________
higgins-dev mailing list
higgins-dev@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Re: IdAS changes proposal

2009-10-21T08:17:56Z

Re: [higgins-dev] IdAS changes proposal

Paul,

> What Jim and all of us talked about several months ago is to remove the special IModel interfaces completely,
> and just use the existing entities and attributes to describe entity classes and attribute definitions. In other words, recurse.

The main Jim's argument to rid IModel interfaces was to reuse alredy existent IEntity and IAttribute inerfaces. Actually, I already gave arguments a year ago, why the current model interfaces are more convenient:

1. The current model interfaces allow to represent many things obviously. Suppose, we need to expose the model of a simple value. If we used Jim's model, we'd represent simple value model via IEntity intrerface (which is confusing by itself). Than, to represent params of this simple value (there are many things in OWL1.1 like length, minLength, maxLength, pattern, etc.), this IEntity should contain an attribute for each of those params. In turn, the attribute should contain some ISimpleAttrValue with data of its parameter. From the other hand, the current IModel interface can reflect OWL in a more convenient way. If we need params of some simple value, we get an instance of ISimpleValueModel (either from IAttributeModel or from ISimpleAttrValue), and invoke its methods getLength(), getMinLength(), getMaxLength() etc.

2. IdAS interfaces (IEntity, IAttribute) have a lot of methods behind of getType() and getData() which are not used in Jim's model. I suppose these methods will confuse people which need to use a model.

3. Jim's model is flexible and could represent anything, but we do not need this, because we limited by OWL and need to describe things which OWL provides. IModel, in turn, could be disigned to reflect OWL constructs handy.

Thanks,
Sergey Lyakhov

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

From: ptrevithick@...

To: higgins-dev@...

Cc: synakh@... ; paul@... ; itsinman@...

Sent: Monday, October 19, 2009 10:55 PM

Subject: Re: [higgins-dev] IdAS changes proposal

What Jim and all of us talked about several months ago is to remove the special IModel interfaces completely, and just use the existing entities and attributes to describe entity classes and attribute definitions. In other words, recurse.

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

> 1. We define a new .api2 that replaces the IFilter stuff with SPARQL.
<snip>... replaces IModel interfaces with something you were going to propose.

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

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

IP CQs waiting on your team

2009-10-20T21:01:42Z

higgins-dev,
IPZilla records show that one or more of the projects on which you are
developer are in need of attention. The following CQs have been in the
'awaiting_project' status for over 3 weeks and need your team to take
action.

technology.higgins:

1098 Higgins OpenID Context Provider -- nonepl, 2 months ago
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1098

If you have any questions, please do not hesitate to contact your project
lead, PMC member, or the EMO <emo@...>

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

New IdAS Model Interfaces [WAS: Re: Improved i-card.owl checked in]

2009-10-20T18:27:09Z

New IdAS Model Interfaces [WAS: Re: Improved i-card.owl checked in] 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

Re: Improved i-card.owl checked in

2009-10-20T08:07:16Z

Re: Improved i-card.owl checked in

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 wont like it either, but well see. Ill 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 youve 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 notbut 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 wont like it either, but well see. Ill 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:

I presume that youve stayed entirely within the IMI specifications? It seems that you have. That was the intent.
WRT your #16: CDM does (in my mind) support polymorphism although I realize that the IdAS API does notbut we can fix this when we remove the Model APIs from IdAS
WRT your #18: I made these changes, thanks.
WRT your #17: Do you have ideas about how to represent these values?
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 Ill turn them into diagrams and Ill 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

Re: IdAS changes proposal

2009-10-19T12:55:37Z

Re: [higgins-dev] IdAS changes proposal What Jim and all of us talked about several months ago is to remove the special IModel interfaces completely, and just use the existing entities and attributes to describe entity classes and attribute definitions. In other words, recurse.

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

> 1. We define a new .api2 that replaces the IFilter stuff with SPARQL.
<snip>... replaces IModel interfaces with something you were going to propose.

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

Re: IdAS changes proposal

2009-10-16T08:49:04Z

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 SPAR@... 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 -----

From: ptrevithick@...

To: higgins-dev@...

Cc: synakh@... ; paul@... ; itsinman@...

Sent: Thursday, October 15, 2009 9:58 PM

Subject: Re: [higgins-dev] IdAS changes proposal

Sergey,

Are you proposing that:

We define a new .api2 that replaces the IFilter stuff with SPARQL.
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.
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 were done from a raw functionality point of viewwe just have to adapt to the IdAS .api2]
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@...> 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 cant 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...> ; Paul Trevithick <paul@...>   ; Igor Tsinman <itsinman@...>

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 cant 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.

Im 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@...> 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...>   ; Paul Trevithick <paul@...>    ; Igor Tsinman <itsinman@...>

Sent: Thursday, October 15, 2009 4:31   PM

Subject: Re: [higgins-dev] IdAS changes   proposal

Sergey,

Hmmm, this is a tough one. We dont want to lose the investments in the existing CPs (the old .idas.api). Yet we dont 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 didnt want to support the .api2 (upper api) wouldnt 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 wed have XDI and SPARQL endpoints   for the Attribute Service. The Linked Object Data (LOD) semweb folks are creating lots of SPARQL endpointswed dovetail with these   efforts.

--Paul

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

Paul,

Sorry for   delay.

> 3. Jim Sermersheim invented IFilter because we needed something and SPARQL wasnt yet established. Now that it is, I wonder if we shouldnt 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 dont 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...>    ; Paul Trevithick <paul@...>     ; Igor Tsinman <itsinman@...>

Sent: Monday, September 28, 2009 3:11    AM

Subject: Re: [higgins-dev] IdAS changes   proposal

Sergey,

My   responses:

agree
agree
Jim   Sermersheim invented IFilter because we needed something and SPARQL wasnt yet established. Now that it is, I wonder if we shouldnt give it another look
(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 isnt 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 dont all break.

--Paul

On 9/23/09 12:07 PM, "Sergey Lyakhov" <slyakhov@...>    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@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

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

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

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

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

Re: IdAS changes proposal

2009-10-15T11:58:58Z

Re: [higgins-dev] IdAS changes proposal Sergey,

Are you proposing that:

We define a new .api2 that replaces the IFilter stuff with SPARQL.
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.
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]
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@...> 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...> ; Paul Trevithick <paul@...>   ; Igor Tsinman <itsinman@...>

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@...> 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...>   ; Paul Trevithick <paul@...>    ; Igor Tsinman <itsinman@...>

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@...>   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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...>    ; Paul Trevithick <paul@...>     ; Igor Tsinman <itsinman@...>

Sent: Monday, September 28, 2009 3:11    AM

Subject: Re: [higgins-dev] IdAS changes   proposal

Sergey,

My   responses:

agree
agree
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.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@...>    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@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

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

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

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

Re: IdAS changes proposal

2009-10-15T09:16:42Z

Re: [higgins-dev] IdAS changes proposal

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 cant 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: ptrevithick@...

To: higgins-dev@...

Cc: synakh@... ; paul@... ; itsinman@...

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 cant 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.

Im 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@...> 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...> ; Paul Trevithick <paul@...>   ; Igor Tsinman <itsinman@...>

Sent: Thursday, October 15, 2009 4:31 PM

Subject: Re: [higgins-dev] IdAS changes proposal

Sergey,

Hmmm, this is a tough one. We dont want to lose the investments in the existing CPs (the old .idas.api). Yet we dont 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 didnt want to support the .api2 (upper api) wouldnt 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 wed have XDI and SPARQL endpoints for the Attribute Service. The Linked Object Data (LOD) semweb folks are creating lots of SPARQL endpointswed dovetail with these efforts.

--Paul

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

Paul,

Sorry for delay.

> 3. Jim Sermersheim invented IFilter because we needed something and SPARQL wasnt yet established. Now that it is, I wonder if we shouldnt 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 dont 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...>   ; Paul Trevithick <paul@...>    ; Igor Tsinman <itsinman@...>

Sent: Monday, September 28, 2009 3:11   AM

Subject: Re: [higgins-dev] IdAS changes   proposal

Sergey,

My responses:

agree
agree
Jim Sermersheim invented IFilter because we needed something and SPARQL wasnt yet established. Now that it is, I wonder if we shouldnt give it another look
(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 isnt 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 dont all break.

--Paul

On 9/23/09 12:07 PM, "Sergey Lyakhov" <slyakhov@...>   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@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

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

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

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

Revised agenda for Higgins developers call Thursday, October 15 at Noon EDT

2009-10-15T09:09:23Z

Revised agenda for Higgins developers call Thursday, October 15 at Noon EDT LOGISTICS: Time: noon Eastern (16:00 UTC) U.S. Dial-in: 1-201-793-9022 passcode 7990866#

AGENDA

1) [Mary, Paul] “ABOUT THIS PROJECT” CLEANUP [1]

We need volunteers to fix the following:

For end users: need to tweak text to align with home page
For developers: need to revise to align with home page; also formatting problems
Newsgroups section: “eclipse.technology.higgins” seems to point to the old newsgroups vs. the new forums
Mailing lists: should we retire higgins-announce (we never announce anything) at least for now
Source Repository: is this the way this should look?
Committers section: Weird to have IBM and Serena logos but no others
Committers: Vitaliy—when can he be added?
Committers: Tie Li —we should probably remove
Committers: Mary Ruddy —should be marked active
Committers: Maxim Kopeyka —should be removed
Releases: misunderstanding about “update site” --links to an ancient page
Bugs: links to an “old style” page [2]
Clicking on “these wiki pages” brings you to a wiki page [3] that has a bunch of old/obsolete links (e.g. [4])
Project plan is empty [5]

2) [Brian, Paul] DOWNLOADS CLEANUP [1]

More tweaks to download page [290659]
GTK Selector 1.1-Win links to [6] which is fine. But it lacks polish:
1. Should be Higgins-branded selector
2. It shouldn’t have the ABX2 browser extension
3. The about box shouldn’t only mention copyright Novell
4. The HBX shouldn’t be called TheBehavior it should be called HigginsBX or HBX or...
5. Need to fix at least the bug that you can’t create a p-card unless you add an image
6. Others?
We should nil out the AIR Selector 1.1-Win and AIR Selector 1.1-Mac links. Instead we should wait for Azigo to check in the latest AIR source

3) BUILD PAGES CLEANUP

Today: [8]
Proposal: [292334]
Need to update [10] to align with what we are currently doing in this area [292335]

4) [Paul] HOME PAGE CLEANUP

Updated home page [7]

5) [Paul] KANTARA ULX

ULX WG has posted first mockups of login to an NIH site using SAML, OpenID, Infocard [12]

[1] http://www.eclipse.org/projects/project_summary.php?projectid=technology.higgins
[2] http://www.eclipse.org/higgins/bugs.php
[3] http://wiki.eclipse.org/Higgins
[4] http://www.eclipse.org/higgins/about.php
[5] http://www.eclipse.org/projects/project-plan.php?projectid=technology.higgins
[6] http://www.azigo.com/company/dev/gtk-selector-1-1-for-windows/
[7] http://www.eclipse.org/higgins
[8] http://download.eclipse.org/technology/higgins/downloads/sync.meta/builds/S-S20090822-200908220210/index.html
[9] http://wiki.eclipse.org/Build_Result_Page
[11] http://wiki.eclipse.org/Automated_Solution-Level_Builds
[12] http://kantarainitiative.org/confluence/pages/viewpage.action?pageId=37749275
[290259] https://bugs.eclipse.org/bugs/show_bug.cgi?id=290659
[292334] https://bugs.eclipse.org/bugs/show_bug.cgi?id=292334
[292335] https://bugs.eclipse.org/bugs/show_bug.cgi?id=292335

------ End of Forwarded Message

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

ATT00001.c (214 bytes) Download Attachment

Re: IdAS changes proposal

2009-10-15T08:41:00Z

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@...> 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...> ; Paul Trevithick <paul@...>   ; Igor Tsinman <itsinman@...>

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@...> 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 <ptrevithick@...>

To: higgins-dev <higgins-dev@...>

Cc: Vadym Synakh <synakh@...>   ; Paul Trevithick <paul@...>    ; Igor Tsinman <itsinman@...>

Sent: Monday, September 28, 2009 3:11   AM

Subject: Re: [higgins-dev] IdAS changes   proposal

Sergey,

My responses:

agree
agree
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.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@...>   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@...
https://dev.eclipse.org/mailman/listinfo/higgins-dev

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

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