[jira] [Commented] (MARMOTTA-513) JAX-RS Doclet is not compatible with the javadoc from JDK8
[
https://issues.apache.org/jira/browse/MARMOTTA-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14073069#comment-14073069
]
ASF subversion and git services commented on MARMOTTA-513:
--
Commit 42f5db0588112ab17974e42142a9c280dc729dcf in marmotta's branch
refs/heads/MARMOTTA-499 from [~wikier]
[ https://git-wip-us.apache.org/repos/asf?p=marmotta.git;h=42f5db0 ]
MARMOTTA-513: preparing the build for the transition towards a jax-doclets
release which solves the issue
JAX-RS Doclet is not compatible with the javadoc from JDK8
--
Key: MARMOTTA-513
URL: https://issues.apache.org/jira/browse/MARMOTTA-513
Project: Marmotta
Issue Type: Bug
Components: Build Environment
Affects Versions: 3.2.1
Reporter: Sergio Fernández
Assignee: Sergio Fernández
Labels: doclet, javadoc, jdk8
Fix For: 3.3.0
Original Estimate: 1h
Remaining Estimate: 1h
A user has reported issues generating the javadoc with JDK8:
http://mail-archives.apache.org/mod_mbox/marmotta-users/201407.mbox/%3C2D26C375-2602-49EF-BFC0-8801EA13C6A5%40vrtx.com%3E
{quote}
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 35.621 s
[INFO] Finished at: 2014-07-07T12:32:48-04:00
[INFO] Final Memory: 104M/265M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (restapi) on
project marmotta-core: An error has occurred in REST API report generation:
[ERROR] Exit code: 1 - javadoc: error - In doclet class
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet, method start has thrown an
exception java.lang.reflect.InvocationTargetException
[ERROR] java.lang.NullPointerException
[ERROR] at
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.init(JAXRSDoclet.java:84)
[ERROR] at
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.start(JAXRSDoclet.java:78)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:483)
[ERROR] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
[ERROR] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
[ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
[ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:219)
[ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:205)
[ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:64)
[ERROR] at com.sun.tools.javadoc.Main.main(Main.java:54)
[ERROR]
[ERROR] Command line was: /app/java/jdk1.8.0_05/jre/../bin/javadoc @options
@packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'/home/dunham/marmotta-src/marmotta/platform/marmotta-core/target/classes/web/doc/rest'
dir.
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (restapi) on
project marmotta-core: An error has occurred in REST API report generation:
Exit code: 1 - javadoc: error - In doclet class
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet, method start has thrown an
exception java.lang.reflect.InvocationTargetException
java.lang.NullPointerException
at
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.init(JAXRSDoclet.java:84)
at
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.start(JAXRSDoclet.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
at com.sun.tools.javadoc.Start.begin(Start.java:219)
at com.sun.tools.javadoc.Start.begin(Start.java:205)
at com.sun.tools.javadoc.Main.execute(Main.java:64)
at com.sun.tools.javadoc.Main.main(Main.java:54)
Command line was: /app/java/jdk1.8.0_05/jre/../bin/javadoc @options @packages
Refer to the generated Javadoc files in
'/home/dunham/marmotta-src/marmotta/platform/marmotta-core/target/classes/web/doc/rest'
dir.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
[jira] [Commented] (MARMOTTA-513) JAX-RS Doclet is not compatible with the javadoc from JDK8
[
https://issues.apache.org/jira/browse/MARMOTTA-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14073070#comment-14073070
]
ASF subversion and git services commented on MARMOTTA-513:
--
Commit d5241ed9f6f88598f0973d0bfda75c6add2fca9b in marmotta's branch
refs/heads/MARMOTTA-499 from [~wikier]
[ https://git-wip-us.apache.org/repos/asf?p=marmotta.git;h=d5241ed ]
MARMOTTA-513: updated to com.lunatech.jax-doclets.doclets:doclets:0.10.1
JAX-RS Doclet is not compatible with the javadoc from JDK8
--
Key: MARMOTTA-513
URL: https://issues.apache.org/jira/browse/MARMOTTA-513
Project: Marmotta
Issue Type: Bug
Components: Build Environment
Affects Versions: 3.2.1
Reporter: Sergio Fernández
Assignee: Sergio Fernández
Labels: doclet, javadoc, jdk8
Fix For: 3.3.0
Original Estimate: 1h
Remaining Estimate: 1h
A user has reported issues generating the javadoc with JDK8:
http://mail-archives.apache.org/mod_mbox/marmotta-users/201407.mbox/%3C2D26C375-2602-49EF-BFC0-8801EA13C6A5%40vrtx.com%3E
{quote}
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 35.621 s
[INFO] Finished at: 2014-07-07T12:32:48-04:00
[INFO] Final Memory: 104M/265M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (restapi) on
project marmotta-core: An error has occurred in REST API report generation:
[ERROR] Exit code: 1 - javadoc: error - In doclet class
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet, method start has thrown an
exception java.lang.reflect.InvocationTargetException
[ERROR] java.lang.NullPointerException
[ERROR] at
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.init(JAXRSDoclet.java:84)
[ERROR] at
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.start(JAXRSDoclet.java:78)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:483)
[ERROR] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
[ERROR] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
[ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
[ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:219)
[ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:205)
[ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:64)
[ERROR] at com.sun.tools.javadoc.Main.main(Main.java:54)
[ERROR]
[ERROR] Command line was: /app/java/jdk1.8.0_05/jre/../bin/javadoc @options
@packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'/home/dunham/marmotta-src/marmotta/platform/marmotta-core/target/classes/web/doc/rest'
dir.
[ERROR] - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (restapi) on
project marmotta-core: An error has occurred in REST API report generation:
Exit code: 1 - javadoc: error - In doclet class
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet, method start has thrown an
exception java.lang.reflect.InvocationTargetException
java.lang.NullPointerException
at
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.init(JAXRSDoclet.java:84)
at
com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.start(JAXRSDoclet.java:78)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
at com.sun.tools.javadoc.Start.begin(Start.java:219)
at com.sun.tools.javadoc.Start.begin(Start.java:205)
at com.sun.tools.javadoc.Main.execute(Main.java:64)
at com.sun.tools.javadoc.Main.main(Main.java:54)
Command line was: /app/java/jdk1.8.0_05/jre/../bin/javadoc @options @packages
Refer to the generated Javadoc files in
'/home/dunham/marmotta-src/marmotta/platform/marmotta-core/target/classes/web/doc/rest'
dir.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
at
[jira] [Commented] (MARMOTTA-499) CSS not working
[ https://issues.apache.org/jira/browse/MARMOTTA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14073072#comment-14073072 ] ASF subversion and git services commented on MARMOTTA-499: -- Commit 0d3bdf8cfc11dc047603fbd306aed338f2efd4d3 in marmotta's branch refs/heads/MARMOTTA-499 from [~wikier] [ https://git-wip-us.apache.org/repos/asf?p=marmotta.git;h=0d3bdf8 ] Merge branch 'develop' into MARMOTTA-499 CSS not working --- Key: MARMOTTA-499 URL: https://issues.apache.org/jira/browse/MARMOTTA-499 Project: Marmotta Issue Type: Bug Components: Admin Interface Affects Versions: 3.2.0 Environment: Mac OS X Reporter: Alvaro Graves Assignee: Sergio Fernández Priority: Trivial Labels: easyfix No CSS seems to work in the interface. I downloaded marmotta 3.2.0 and it is running on a Mac OS X Mavericks machine. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MARMOTTA-499) CSS not working
[ https://issues.apache.org/jira/browse/MARMOTTA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14073068#comment-14073068 ] ASF subversion and git services commented on MARMOTTA-499: -- Commit 1dd77c478c1c8771af966e4e0352c94213e6154c in marmotta's branch refs/heads/MARMOTTA-499 from [~wikier] [ https://git-wip-us.apache.org/repos/asf?p=marmotta.git;h=1dd77c4 ] MARMOTTA-499: remove debug logging CSS not working --- Key: MARMOTTA-499 URL: https://issues.apache.org/jira/browse/MARMOTTA-499 Project: Marmotta Issue Type: Bug Components: Admin Interface Affects Versions: 3.2.0 Environment: Mac OS X Reporter: Alvaro Graves Assignee: Sergio Fernández Priority: Trivial Labels: easyfix No CSS seems to work in the interface. I downloaded marmotta 3.2.0 and it is running on a Mac OS X Mavericks machine. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MARMOTTA-499) CSS not working
[ https://issues.apache.org/jira/browse/MARMOTTA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14073071#comment-14073071 ] Sergio Fernández commented on MARMOTTA-499: --- No [~dunham], in the MARMOTTA-499 we already moved out from mime-utils in favor of Apache Tika, which is a well maintained and reliable library. Anyway, the unit tests work fine with both Java7 and Java8, so we can discard an issue from Tika. I'll update to users@tomcat.a.o with our latest inquiries, and come back with the conclusions. CSS not working --- Key: MARMOTTA-499 URL: https://issues.apache.org/jira/browse/MARMOTTA-499 Project: Marmotta Issue Type: Bug Components: Admin Interface Affects Versions: 3.2.0 Environment: Mac OS X Reporter: Alvaro Graves Assignee: Sergio Fernández Priority: Trivial Labels: easyfix No CSS seems to work in the interface. I downloaded marmotta 3.2.0 and it is running on a Mac OS X Mavericks machine. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MARMOTTA-499) CSS not working with JRE 8
[ https://issues.apache.org/jira/browse/MARMOTTA-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergio Fernández updated MARMOTTA-499: -- Summary: CSS not working with JRE 8 (was: CSS not working) CSS not working with JRE 8 -- Key: MARMOTTA-499 URL: https://issues.apache.org/jira/browse/MARMOTTA-499 Project: Marmotta Issue Type: Bug Components: Admin Interface Affects Versions: 3.2.0 Environment: Mac OS X Reporter: Alvaro Graves Assignee: Sergio Fernández Priority: Trivial Labels: easyfix No CSS seems to work in the interface. I downloaded marmotta 3.2.0 and it is running on a Mac OS X Mavericks machine. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [GSoC] less 1 month left
Dear Sergio, Thanks for your reminder! I've been watching the marmotta's branch refs/heads/develop (not much changes related to ldp service these days). As you pointed out, I just checked the ldp branch and updated my LdpServiceSPARQLImpl accordingly [1]. Now both LdpServiceSPARQLImpl and LdpServiceImpl passed my unit tests as expected. I'll keep a close eye on both the develop and ldp branches in the coming weeks. With previous experience in the first half part of the project, I think it's not difficult to translate the remaining changes to the SPARQL implementations. I'll check and translate the changes everyday. After the GSoC project, I can also offer contribution related to this work. In the meanwhile, I'll work on the documentations and the tests (performance, w3c test suite, etc), as you mentioned in the mid-term evaluation. I've been studying JMeter, TestNG and Rest-Assured. I'll have a try in the next week and keep you posted. Best, Qihong Lin [1] https://github.com/confidencesun/marmotta/commit/cff11e06c0c13bd8d8a10fea5e9eccf8d31f86ba On Wed, Jul 23, 2014 at 3:45 PM, Sergio Fernández wik...@apache.org wrote: According the official time-line: http://www.google-melange.com/gsoc/events/google/gsoc2014 August 18th is the official 'pencils down' date for GSoC this year. Please, Qihong Lin, remember to continue pushing hard. I did not see some much activity or reporting in the last weeks, and you still have so much to do for achieving the goals of the project. We had been working at the ldp branch, fixing details discovered by the W3C test suite. They mainly affect the web service layer, but I think we extended the service api with some new methods. Next week Jakob and myself we plan to continue working on that, with the idea of merging stable changes back to develop during the week. Please, stay tune to the changes, and decide whether you can afford or not to adopt them at this stage. Personally I'll offline 6th to 20th, so everything that you deliver before would make my final evaluation much easier. Thanks for your contribution to the Apache Marmotta project. Cheers, -- Sergio Fernández Partner Technology Manager Redlink GmbH m: +43 660 2747 925 e: sergio.fernan...@redlink.co w: http://redlink.co
Fwd: SPARQL subset as a PATCH format for LDP
LDPath as influence to LDPatch?
Well, I'm still awaiting what it contributes for what RDF Patch already does...
-- Forwarded message --
From: Alexandre Bertails alexan...@bertails.org
Date: Jul 24, 2014 8:30 PM
Subject: SPARQL subset as a PATCH format for LDP
To: public-ldp...@w3.org public-ldp...@w3.org
Cc:
All,
I have been thinking a lot about the SPARQL subset idea and I would
like to share some thoughts. As you could have expected from the last
call, I am not in favor of it, so I have taken the time to document my
issues with the approach.
First, let me remind you the scope of LD Patch. It is PATCH format for
partial updates of LDP-RS. So it's only about RDF graphs. It is not
intended for updating quad stores, nor named graphs. Also, it is not
meant to be a high-level language but rather an assembly one. For that
reason, the editors challenged themselves for not adding higher-level
features.
Skolemization is not used. The assumption is that bnodes form tree
structures. The idea is that most of those trees (and the bnodes in
them) can be distinguished by filtering on sub-components of those
trees. I recommend [1] for a recent and thorough analysis confirming
those assumptions.
That is the very reason behind the LD Path (no 'c') algebra, which
shares some similarities with XPath. They are applied left-to-right,
and recursively for path constraints. The semantics formally specifies
the order in which those operations must be evaluated. So LDP
application writers can rely on that semantics for runtime
characteristics, for example by restraining the node sets as early as
possible in the path, by probably starting from the leaves of the
tree, and then moving up in the tree, until reaching the bnode.
So, SPARQL. Yes, you can consider a subset with similar expressive
power. People seem to think that defining the concrete syntax would be
enough, and that it would be as easy if not easier than LD Patch. I
disagree. First, the two concrete syntaxes would share a lot of the
production rules, basically all the ones borrowed from Turtle. The
additional ones are no issue in both cases.
Then, I have heard people saying that we wouldn't need to write down
the operational semantics, because we could say it's the same than
SPARQL Update, but for that subset of the syntax. I disagree. Because
as a developer and as a user, I would have to be sure I understand
well the SPARQL semantics to either implement LD Patch (if I don't
want to depend on an existing SPARQL implementation), or to use it. So
I'd argue that the semantics _has_ to be written. And I'd have to
reject valid SPARQL Update queries which are not in the subset.
Another issue is that we will still need Basic Graph Patterns, the (S
P O .)-s in the WHERE clause, which rely on intermediate ResultSet-s
for their semantics.
For example:
Bind ?event http://conferences.ted.com/TED2009/
/-schema:url[/schema:startDate=2009-02-04]/schema:location[/schema:name=Long
Beach, California][/schema:geo[/schema:latitude][/schema:longitude]]
would be equivalent to something like that:
WHERE {
?event schema:url http://conferences.ted.com/TED2009/ .
?event schema:startDate 2009-02-04 .
?event schema:location ?loc .
?loc schema:name Long Beach, California .
?loc schema:geo ?geo .
?geo schema:latitude [] .
?geo schema:longitude [] .
}
If we want the same performance characterics (mainly, predictability),
we would have to refine the SPARQL semantics so that the order of the
clauses matters (ie. no need to depend on a query optimiser). And we
would need to do some static analysis on the query to make sure that
ResultSet-s are not needed. In any case, it goes beyond the idea of
using subset of the syntax + a pointer to SPARQL Update semantics.
Another problem is the support for rdf:list. I have just finished
writing down the semantics for UpdateList and based on that
experience, I know this is something I want to rely on as a user,
because it is so easy to get it wrong, so I want native support for
it. And I don't think it is possible to do something equivalent in
SPARQL Update. That is a huge drawback as list manipulation (eg. in
JSON-LD, or Turtle) is an everyday task.
So to summarize my issues with the approach:
1. semantics is not that easy to define
2. performance characteristics
3. no native support for rdf:list
4. needs to explain to the user how it differs from existing SPARQL
Update
SPARQL Update is good at doing what it was designed for, but there is
little interest in being syntax compatible with it.
Regards,
Alexandre
[1] http://www.websemanticsjournal.org/index.php/ps/article/view/365
Re: Fwd: SPARQL subset as a PATCH format for LDP
On 24/07/14 19:58, Sergio Fernández wrote:
LDPath as influence to LDPatch?
Well, I'm still awaiting what it contributes for what RDF Patch already does...
RDF Patch is certainly at the lower level, machine level with a slant to
processing issues over readability. It combines with binary RDF [1],
which in my experiments parses at 560K triples/s, or x3 faster than I
can get N-triples to go.
But these engineering issues are less in the sight of LDP which,
realistically, is slanted to smaller data as the unit of change.
Andy
[1] https://github.com/afs/rdf-thrift
-- Forwarded message --
From: Alexandre Bertails alexan...@bertails.org
Date: Jul 24, 2014 8:30 PM
Subject: SPARQL subset as a PATCH format for LDP
To: public-ldp...@w3.org public-ldp...@w3.org
Cc:
All,
I have been thinking a lot about the SPARQL subset idea and I would
like to share some thoughts. As you could have expected from the last
call, I am not in favor of it, so I have taken the time to document my
issues with the approach.
First, let me remind you the scope of LD Patch. It is PATCH format for
partial updates of LDP-RS. So it's only about RDF graphs. It is not
intended for updating quad stores, nor named graphs. Also, it is not
meant to be a high-level language but rather an assembly one. For that
reason, the editors challenged themselves for not adding higher-level
features.
Skolemization is not used. The assumption is that bnodes form tree
structures. The idea is that most of those trees (and the bnodes in
them) can be distinguished by filtering on sub-components of those
trees. I recommend [1] for a recent and thorough analysis confirming
those assumptions.
That is the very reason behind the LD Path (no 'c') algebra, which
shares some similarities with XPath. They are applied left-to-right,
and recursively for path constraints. The semantics formally specifies
the order in which those operations must be evaluated. So LDP
application writers can rely on that semantics for runtime
characteristics, for example by restraining the node sets as early as
possible in the path, by probably starting from the leaves of the
tree, and then moving up in the tree, until reaching the bnode.
So, SPARQL. Yes, you can consider a subset with similar expressive
power. People seem to think that defining the concrete syntax would be
enough, and that it would be as easy if not easier than LD Patch. I
disagree. First, the two concrete syntaxes would share a lot of the
production rules, basically all the ones borrowed from Turtle. The
additional ones are no issue in both cases.
Then, I have heard people saying that we wouldn't need to write down
the operational semantics, because we could say it's the same than
SPARQL Update, but for that subset of the syntax. I disagree. Because
as a developer and as a user, I would have to be sure I understand
well the SPARQL semantics to either implement LD Patch (if I don't
want to depend on an existing SPARQL implementation), or to use it. So
I'd argue that the semantics _has_ to be written. And I'd have to
reject valid SPARQL Update queries which are not in the subset.
Another issue is that we will still need Basic Graph Patterns, the (S
P O .)-s in the WHERE clause, which rely on intermediate ResultSet-s
for their semantics.
For example:
Bind ?event http://conferences.ted.com/TED2009/
/-schema:url[/schema:startDate=2009-02-04]/schema:location[/schema:name=Long
Beach, California][/schema:geo[/schema:latitude][/schema:longitude]]
would be equivalent to something like that:
WHERE {
?event schema:url http://conferences.ted.com/TED2009/ .
?event schema:startDate 2009-02-04 .
?event schema:location ?loc .
?loc schema:name Long Beach, California .
?loc schema:geo ?geo .
?geo schema:latitude [] .
?geo schema:longitude [] .
}
If we want the same performance characterics (mainly, predictability),
we would have to refine the SPARQL semantics so that the order of the
clauses matters (ie. no need to depend on a query optimiser). And we
would need to do some static analysis on the query to make sure that
ResultSet-s are not needed. In any case, it goes beyond the idea of
using subset of the syntax + a pointer to SPARQL Update semantics.
Another problem is the support for rdf:list. I have just finished
writing down the semantics for UpdateList and based on that
experience, I know this is something I want to rely on as a user,
because it is so easy to get it wrong, so I want native support for
it. And I don't think it is possible to do something equivalent in
SPARQL Update. That is a huge drawback as list manipulation (eg. in
JSON-LD, or Turtle) is an everyday task.
So to summarize my issues with the approach:
1. semantics is not that easy to define
2. performance characteristics
3. no native support for rdf:list
4. needs to explain to the user how it differs from existing SPARQL
Update
SPARQL Update is good at doing what it was designed for, but there is
