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
|