Very glad you've started such a uniformications discussion on the jena mailing list. I think it would be good to have such an API adopted by Jena as well. I think it would be important for such an API to be based on standards and not specifically on triple-stor design as to allow exposing other object structures as well as RDF through this API.
A couple of thoughts: - To keep the API simple I think it should either be quads or datasets. I'd go for DataSets as this is part of Standards (Sparql) and see quads as a way this can be implemented. - Given a DataSet, why not allow Sparql queries against it? (With an abstract implementation that locates a query engine and if no such engine is found throws a NoQueryEngineFoundException) Apart from the above differences, is there any part of the clerezza rdf api you would implement fundamentally different (I agree the naming should be revisited) than in the Clerezza api [1]? Cheers, Reto http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html On Thu, Nov 22, 2012 at 4:04 PM, Andy Seaborne <a...@apache.org> wrote: > Rob's comments on inverting the reader process [2] suggest to me pulling > out an API and I wonder if we can identify a portability layer that enables > some (not all) interoperability and mix-n-match. > > The term "API" is creating some confusion in the discussions triggered by > the Clerezza incubator project being noted [1][3] as "low activity" > > To some, it's what the application sees -- a presentation API. To others > it is some kind of abstraction between machinery like storage, inference, > parsing and writing. They don't have to be the same. > > Even if the only outcome if parser and stream processing mouldarity, I > think it is worth doing. Just being able to add an external "parser" to > Jena in a cleaner way that is currently possible is useful. > > ** Apache Portable Uniform RDF Runtime (PURR) ** > > (OK - the "U" is a bit forced :-) > > To me, what we need is an abstraction that allows multiple implementations > by swapping the jars (or OGSi bundles). So PURR is a set of interfaces. > No state. c.f. SLJ4J. > > There would be many presentation APIs: Model-like, RDF-ORM, Ontology, and > also for natural use in other JVM-based languages - Scala, Clojure, > whatever is the next JVM language de jour. > > It's not a full application library. It's rather low level. Writing much > code directly at the interface may not be pretty. > > This is not the Jena graph SPI although that was trying to preform that > purpose but has wider coverage of functionality. I think we can go more > minimal yet. > > The Jena Graph SPI has a number of handlers - events, stats, transactions > - which seem to make the problem too large. These would be part of another > subsystem ("extends PURR") and be different in different providers. One of > those would be Jena Graph. > > PURR would provide the basic concepts from RDF: > > Terms: IRIs, Literals, bNodes > Triples and Quads > Graph, Dataset > Factories for each. > > and for each be quite vanilla. > > e.g. a literal is a lexical form, a datatype and an optional language tag. > Immutable with getters. Structural equality. No value, XSD or otherwise. > > (I'll do a quick sketch in another message - but don't read it as fixed, > just a concrete discussion point) > > Parsers: > > Parsers, and in the general sense of anything that produced RDF from > whatever input, be it an RDF syntax or mapping another data format (a > conversion process), need and input stream and a factory, and emits > Triples, Quads comprising of terms. That don't need a full "graph" - they > need a destination to send Triples/Quads (or be pull parsers). > > Writers: > > Writing is not the reverse of parsing - parsers produce a stream, writers > for Turtle etc need to poke around the graph to decide what will "look > nice". Even N-triples written clustered by subject can be useful. > > Negatives: > > 1/ It's wildly ambitious and impractical to even consider portability and > abstraction. Too much time has passed. Waste of effort. > > 2/ The portability layer is so narrow that it is not helpful. > > 3/ No SPARQL. > (counter: (1) SPARQL is a remote protocol - this is same-JVM). > (counter: (2) develop a SPARQL API using PURR basic terms) > > > Opinions? > > Andy > > > [1] > http://wiki.apache.org/**incubator/November2012<http://wiki.apache.org/incubator/November2012> > > [2] http://s.apache.org/KCv > --> > http://mail-archives.apache.**org/mod_mbox/jena-dev/201210.**mbox/%** > 3CC0B6979A3CA668458B697E4EA907**CA940A01AF5C%40CFWEX01.** > americas.cray.com%3E<http://mail-archives.apache.org/mod_mbox/jena-dev/201210.mbox/%3CC0B6979A3CA668458B697E4EA907CA940A01AF5C%40CFWEX01.americas.cray.com%3E> > > [3] http://s.apache.org/lK > --> > http://mail-archives.apache.**org/mod_mbox/incubator-** > clerezza-dev/201211.mbox/%**3CCAEWfVJ%3DcKATgo32u-AZDQKq%** > 2BmsaVM_CWRnLo_OLdTYP1jFVzAw%**40mail.gmail.com%3E<http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201211.mbox/%3CCAEWfVJ%3DcKATgo32u-AZDQKq%2BmsaVM_CWRnLo_OLdTYP1jFVzAw%40mail.gmail.com%3E> >
