Hugh, you are correct and I would like to apologise for my part in that
as the main instigator.
On my side however, I found it difficult to see my statements
deconstructed and rearranged into various positions I never took and
that I very much disagree with [6], but yes, I still should have just
stated my position as clearly as possible and left it at that (why I
personally take exception to a claim like "SPARQL scales" is again
covered by [1-5]).
On the plus side though, perhaps some interesting discussion has arisen
out of this in various threads. (In particular, I found Leigh's comments
very much constructive.)
/Aidan
[1] http://en.wikipedia.org/wiki/Scalability
[2] http://en.wikipedia.org/wiki/Tractable_problem
[3] https://en.wikipedia.org/wiki/P-complete
[4] http://en.wikipedia.org/wiki/Graph_homomorphism
[5] Jorge Pérez, Marcelo Arenas, Claudio Gutierrez: Semantics and
complexity of SPARQL. ACM Trans. Database Syst. 34(3) (2009)
[6] "XPath can replace SPARQL" (I never said that), "XPath is better
than SPARQL" (I said it was more scalable in the general case being
tractable and parallelisable), "XYZ is scalable and can do what SPARQL
does" (obviously nonsense if I hold that SPARQL doesn't scale in the
general case), "because implementation X cannot do Y, this proves the
SPARQL doesn't scale" (I never took this position; I was directly asked
for /examples/ and I gave the simplest ones I could think of; the proof
that SPARQL is not scalable [1-3] is in [5] above) ... and again, I do
like SPARQL a lot and I'm personally not a fan of anything XML, let
alone XPath. So now I'll shut up. :)
On 18/04/2013 12:05, Kingsley Idehen wrote:
On 4/18/13 6:41 AM, Hugh Glaser wrote:
Someone starts a thread (in this case Luca and his Restpark), about
something they would like to get some feedback on.
In the very first reply, an issue arises that is at best tangential to
the thread subject, but (in my opinion) has no direct bearing on it:
issues around "SPARQL scales?" and perhaps in comparison with REST, etc.
40+ messages follow on "scaling", with the few on Restpark interspersed.
Only the hardiest souls interested in Restpark would have combed
through these messages to see the topic that interests them
(or people who are retired with nothing better to do because they
don't like gardening :-) )
This is no way to run a mailing list to get the widest engagement.
It was clear very early (third message?) that the scaling topic had
arisen - at that stage the discussion should have moved to a new
thread on scaling;
or simply changed the subject line to have "SPARQL Scaling - was
Restpark - Minimal…".
Then the people who might want to discuss Restpark can do so in their
own thread, and the scaling people can have their thread, without
being bothered by the Restpark discussion if they don't want to be.
Simples!
I wouldn't bother, but this seems to be the normal way this lists
works - check out the archive if you want!
It makes it quite dysfunctional.
Note that I did not simply add this message to the Restpark thread,
which is what usually happens in this list!
Best
Hugh
Hugh,
The Restpark thread diverged for two presumptive reasons:
1. REST and SPARQL are mutually exclusive
2. Strawman on "scale" -- the simple point was supposed to be that
consensus and adoption are mercurial pursuits due to pattern explosion.
For the record, I have nothing about attempting to layer RESTful
interactions for simplified interactions with Linked Data. There will
never be a time when I am against options, even when I know the path to
consensus and adoption has a high probability of becoming an odyssey.
I few weeks ago a similar discussion emerged on Twitter, without the
unfortunate "mutual exclusion" undertone, and a conversation developed
progressed to the point were we concluded that a post to this forum be
a nice route for seeking collaborators [1][2].
That all said, I should have forked the thread (with a new topic
heading) the moment the context for my use of "scale" was misunderstood.
Links:
1. https://twitter.com/stephanef/status/317650285470298112 -- a thread
about RESTful patterns for working with ontologies and vocabularies
2. https://twitter.com/kidehen/status/317661048486363138 -- scheduled
for implementation acknowledgement.
