IdAS changes proposal

[Sergey Lyakhov]

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

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

[Markus Sabadello]

Hi,

- I like everything you say under 1.X and 2.X. I love the idea of removing IBlankEntity.

- If I understand correctly, entityRelation isn't needed, because everything is an entityRelation.

Sergey, do you have an opinion on how one Attribute can have a Value which points to an Entity in a different Context (by using a UDI)?

Should IAttribute.getValues() return a string which holds the UDI and which can be manually resolved to another Entity, or should getValues() return an IEntity "proxy" object which gets properly resolved once you access it? Like in Hibernate.. If you fetch a row which has a parent-child relationship to a row in another table, Hibernate will return a proxy object and only fetch the row in the other table when you really need it..

Markus

2009/9/23 Sergey Lyakhov <slyakhov@...>

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

[Paul Trevithick-3]

Sergey,

My responses:

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

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

--Paul

On 9/23/09 12:07 PM, "Sergey Lyakhov" <slyakhov@...> 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

[Sergey Lyakhov]

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

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

To: higgins-dev@...

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

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

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

Sergey,

My responses:

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

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

--Paul

On 9/23/09 12:07 PM, "Sergey Lyakhov" <slyakhov@...> 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

[Paul Trevithick-3]

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:
 

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

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

--Paul

On 9/23/09 12:07 PM, "Sergey Lyakhov" <slyakhov@...>  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

[Sergey Lyakhov]

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

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

To: higgins-dev@...

Cc: synakh@... ; paul@... ; 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:
 

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

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

--Paul

On 9/23/09 12:07 PM, "Sergey Lyakhov" <slyakhov@...>  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

[Paul Trevithick-3]

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:
 
 

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

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

--Paul

On 9/23/09 12:07  PM, "Sergey Lyakhov" <slyakhov@...>   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

[Sergey Lyakhov]

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

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

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

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

--Paul

On 9/23/09 12:07  PM, "Sergey Lyakhov" <slyakhov@...>   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

[Paul Trevithick-3]

Sergey,

Are you proposing that:

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

--Paul

On 10/15/09 12:16 PM, "Sergey Lyakhov" <slyakhov@...> 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:
 
 
 

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

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

--Paul

On 9/23/09 12:07  PM, "Sergey  Lyakhov" <slyakhov@...>    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

[Sergey Lyakhov]

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

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:

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

--Paul

On 10/15/09 12:16 PM, "Sergey Lyakhov" <slyakhov@...> 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:
 
 
 

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

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

--Paul

On 9/23/09 12:07  PM, "Sergey  Lyakhov" <slyakhov@...>    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

[Paul Trevithick-3]

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

[Sergey Lyakhov]

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

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

[Sergey Lyakhov]

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

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:

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

--Paul

On 10/15/09 12:16 PM, "Sergey Lyakhov" <slyakhov@...> 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:
 
 
 

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

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

--Paul

On 9/23/09 12:07  PM, "Sergey  Lyakhov" <slyakhov@...>    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

[Paul Trevithick-3]

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