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