Hello,
I commited a new IdAS API, implementation of a new
model and a new RDF CP into Eclipse SVN. The following projects were
added:
1. org.eclipse.higgins.idas.api2 - new IdAS/model API; main changes -
eleminating of BlankEntity, entityId (attribute of Entity) and IFilter
interfaces.
2. org.eclipse.higgins.idas.cp.model2 and
org.eclipse.higgins.idas.cp.model2.test -
implementation of a new model;
3.
org.eclipse.higgins.idas.cp.rdf2 and org.eclipse.higgins.idas.cp.rdf2.test
- implementation of new IdAS API.
4. org.eclipse.higgins.idas.common2 and
org.eclipse.higgins.idas.registry2 - duplicates of the same previous
projects which need to be used with a new API. IdAS registry was duplicated to
provide the possibility to use both IdAS API in the same application.
Thanks, Sergey Lyakhov
----- Original Message -----
Sent: Friday, October 16, 2009 5:49
PM
Subject: Re: [higgins-dev] IdAS changes
proposal
Paul,
> 1. We define a new .api2 that replaces the IFilter
stuff with SPARQL.
Yes,
replaces IFilter, removes IBlankEntity, and (perhaps) replaces IModel
interfaces with something you were going to propose.
> 2. We define
a sub-set of SPARQL that could be used with .api2 for purposes of creating an
adaptor CP, yet would still have acceptable performance.
Yes. Also, because SPARQL allows to query literals, I suppose it would
be useful to query as full Entities as separate attribute values. I
suppose we should add two methods to IContext:
a) Iterator getEntities(String sparql) -
returns iterator of IEntity;
a) Iterator
getValues(String sparql) - returns iterator of List, where list
contains data objects;
> We would
implement the full new .api2 in any new CPs that are based on RDF technology
directly (e.g. Jena) or on something like RDF (e.g. XDI).
Yes.
> We will inform Mary Ruddy ASAP about any new tech
(e.g. ARQ or newer versions of Jena) we want to use for this new CP so we can
get the Eclipse legal process going.
Yes, of course.
Thanks, Sergey Lyakhov
----- Original Message -----
Sent: Thursday, October 15, 2009 9:58
PM
Subject: Re: [higgins-dev] IdAS changes
proposal
Sergey,
Are you proposing
that:
- 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@xxxxxxxxxxxxxx>
wrote:
Paul,
Actually, I did
mean the following: 1. Main point - it is difficult to
implement full SPARQL specification in Upper CP because it is really
difficult task. In other words, we can implement "restricted" SPARQL
functionality where some queries will not work. 2. (as you
understood) some semantics 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 <mailto:ptrevithick@xxxxxxxxx>
To: higgins-dev <mailto:higgins-dev@xxxxxxxxxxx>
Cc: Vadym Synakh <mailto:synakh@xxxxxxxxxxxxxx>
; Paul Trevithick <mailto:paul@xxxxxxxxxxxxx>
; Igor Tsinman <mailto:itsinman@xxxxxxxxxxxxx>
Sent: Thursday, October 15, 2009 6:41
PM Subject: Re: [higgins-dev] IdAS changes
proposal
Sergey,
Let me see if I
understand what you are saying. Are you saying
this:
- We could
implement the .api2 CP as shown below, but it will be difficult
to implement in it many aspects of SPARQL because the semantics
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@xxxxxxxxxxxxxx>
wrote:
Paul,
> Do you think it is
practical to implement this: >
+----------------------------------------+ > | Upper CP
that implements .idas.api2 | > | SPARQL
api but read/writes raw
| > |
entities/attributes from lower CP
| >
+----------------------------------------+ >
+----------------------------------------+ > | Lower CP
implements existing .idas.api | >
+----------------------------------------+
I think we are able to implement basic aspects of SPARQL
which will satisfy our requirements. However it will be
difficult to implement many aspects of SPARQL such as FILTER
functions in WHERE clause (moreover, there is no any equivalent
of those functions in idas.api.IFilter). For example, if I want
to use regex(..) SPARQL FILTER function in Upper
CP, I'll need first select all entities from old
CP, and than make additional check selecting entities which
conform to the regexp.
Thanks, Sergey
Lyakhov
----- Original Message -----
From: Paul Trevithick <mailto:ptrevithick@xxxxxxxxx>
To: higgins-dev <mailto:higgins-dev@xxxxxxxxxxx>
Cc: Vadym Synakh <mailto:synakh@xxxxxxxxxxxxxx>
; Paul Trevithick <mailto:paul@xxxxxxxxxxxxx>
; Igor Tsinman <mailto:itsinman@xxxxxxxxxxxxx>
Sent: Thursday, October 15, 2009
4:31 PM Subject: Re: [higgins-dev]
IdAS changes
proposal
Sergey,
Hmmm, this is a
tough one. We 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@xxxxxxxxxxxxxx>
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 <mailto:ptrevithick@xxxxxxxxx>
To: higgins-dev <mailto:higgins-dev@xxxxxxxxxxx>
Cc: Vadym Synakh <mailto:synakh@xxxxxxxxxxxxxx>
; Paul Trevithick <mailto:paul@xxxxxxxxxxxxx>
; Igor Tsinman <mailto:itsinman@xxxxxxxxxxxxx>
Sent: Monday, September
28, 2009 3:11 AM Subject:
Re: [higgins-dev] IdAS changes
proposal
Sergey,
My
responses:
- 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@xxxxxxxxxxxxxx>
wrote:
Paul,
I suppose,
cdm:entityId is redundant and we can use rdf:ID
instead. As a result:
1.1. In this
case IEntity.getEntityID() will retun
rdf:ID. 1.2. In case of blank entity
(previously known as a complex value) it should
return null. 1.3. entityId attribute will be
eliminated.
I suppose we
need to do the following changes to IdAS
interfaces to be compatible with
CDM:
2.1. BlankEntity class has been
eliminated from cdm.owl. So, I suppose we need to do the
same for IdAS interfaces and replace
IBlankEntity with IEntity (eliminate IBlankEntity
interface). Because there is no
any difference between entity and complex value,
we can define the following:
2.2. If Entity
has been created by
IContext.addEntity(entityType, entityID) method,
it should always have entityID (should not be a
blank entity). In other words, a unique value
should be generated by a context and used as
entityId, if no entityId passed. 2.3. If
Entity has been created by
IAttribute.addValue(URI) method, it should be a
blank entity. 2.4. If Entity has been added by
IAttribute.addValue(IAttributeValue) it
should be the same type as passed entity. If
passed entity is a blank entity, new blank entity
should be created as a copy of passed, otherwise a
reference to the existent (non blank) entity
should be created. 2.5. When Entity is deleted,
all its subentities which are a blank entity
should be deleted too. Also we
need more flex IFilter API: 3.1.
IFilter should be able to query both types
of entities as blank as usual. 3.2.
IFilter should be able to query a separate value
(entity or simple value) of any nesting
level, not only direct attributes of
Entity. Also I have some notes
about CDM: 4.1. CDM.owl
contains entityRelation and contextRelation object
properties. Do we need to reflect them in
IdAS interfaces? 4.2. Namespase of cdm.owl http://www.eclipse.org/higgins/ontologies/2008/6/cdm.owl
ends with .owl. Is it
correct?
Thanks, Sergey
Lyakhov
_______________________________________________ higgins-dev
mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________ higgins-dev
mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________ higgins-dev
mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________ higgins-dev
mailing
list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________ higgins-dev mailing
list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev
|