You mean to add unwrap() to the implementation classes? So it would just do a cast? But we have an operator for that in Java... :-)
If you mean to add it to RDFTermFactory as a different name/style for the many asSomething() methods, perhaps just as the name as()? That is how Jena does it, to hide instanceof and casting: https://jena.apache.org/documentation/javadoc/jena/org/apache/jena/rdf/model/RDFNode.html#as-java.lang.Class- Btw, the "factory" methods might both wrap or unwrap, e.g. JenaRdfTermFactory.asJenaNode(rdfterm) would unwrap a JenaRDFTerm implementation directly, but still recognise a "foreign" RDFTerm which is instead wrapped/converted to a new JenaNode instance. I'm still worried by an API that takes "any" class, it is not too useful if you don't know what classes are actually supported, as you see Jena therefore also added canAs() in addition to more specific asLiteral() and asResource(). Perhaps Andy Seaborne have views on those kind of convenience methods? They could be added to the RDFTerm interface with a default implementation that just tries to cast. On 13 Sep 2016 2:00 a.m., "Matt Sicker" <boa...@gmail.com> wrote: Couldn't you do the JDBC Wrapper style interface and have a generic method like: <T> T unwrap(Class<T> cls); Or make more specific unwrap methods like: <T extends Statement> T unwrap(Class<T> cls); If this is for implementation-specific casts and such. On 12 September 2016 at 19:56, Stian Soiland-Reyes <st...@apache.org> wrote: > [[ Cross-post - prefer replies to dev@commons ]] > > Each of the Common RDF implementations come with a RDFTermFatory > > http://stain.github.io/incubator-commonsrdf/integration/org/apache/ > commons/rdf/api/RDFTermFactory.html > > On a classical flat classloader the implementations of this factory > can be discovered with java.util.ServiceLoader > > > So if you have say a JsonLdRDFTermFactory you can call .createTriple() > etc - and it would be backed by that implementation. As mentioned the > marker interfaces will allow you to later on get hold of the wrapped > object, e.g. to do some RDFS reasoning on a Jena Model or to parse it > to a serializer. > > > But what if you already have a 'native' object, e.g. a > org.eclipse.rdf4j.model.Statement - and you want to convert it/adapt > it to the corresponding Commons RDF API Triple? > > Obviously there would not be a general interface for this (without > using ?-generics) as each backend implementation would have different > (so far unrelated) types - but we can at least agree on the common > style? > > In > > http://stain.github.io/incubator-commonsrdf/integration/org/apache/ > commons/rdf/rdf4j/RDF4JTermFactory.html > > I suggests as*() adapter methods like: > > > RDF4JQuad asQuad(org.eclipse.rdf4j.model.Statement > > RDF4JTriple asTriple(org.eclipse.rdf4j.model.Statement statement) > > RDF4JTerm asRDFTerm(org.eclipse.rdf4j.model.Value value) > > RDF4JDataset asRDFTermDataset(org.eclipse.rdf4j.repository.Repository > repository) > > RDF4JGraph asRDFTermGraph(org.eclipse.rdf4j.model.Model model) > > RDF4JGraph asRDFTermGraph(org.eclipse.rdf4j.repository.Repository > repository) > > > but also the inverse converters: > > org.eclipse.rdf4j.model.Value asValue(RDFTerm term) > > org.eclipse.rdf4j.model.Statement > asStatement(TripleLike<BlankNodeOrIRI,IRI,RDFTerm> tripleLike) > > > (These will unpack the wrapped value if it's an RDF4JTerm - or create > a new RDF4J native instance if it's a "foreign" class) > > > Questions: > > > a) Do these adapter methods belong in the RDFTermFactory or should > there be a new family of 'adaptor factories'? (e.g. the Jena Factory > > > b) What should we call these methods? Is as*() appropriate or should > they more closely match the createTriple() etc methods from > RDFTermFactory? > > With asSomething() I wanted to hint of adaptation - rather than > 'convert' or 'create' - but without having to commit to adaptation > with adapt() or wrap(). > > > Now sometimes the implementations use the same class name as Commons > RDF (e.g. Quad or Graph). Code-wise this is not too hard to deal with > (avoid importing either), but it means it can get more confusing for > downstream API users who do auto-complete and then don't know what > direction they are adapting. > > > c) Should the adapter methods have short names (e.g. asGraph()) - > distinguished by type polymorphism and javadocs - or more verbose to > show which particular return-type you get? (e.g. asJenaGraph() and > asCommonsRDFGraph()) ) > > > d) Do we need to rename RDFTermFactory to RDFFactory (or just RDF) ? > > > > -- > Stian Soiland-Reyes > http://orcid.org/0000-0001-9842-9718 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker <boa...@gmail.com>
