incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Carroll <jer...@topquadrant.com>
Subject Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Date Wed, 10 Nov 2010 23:28:59 GMT
> - The core API for (mutable) graphs in:
> http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html
http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/org/apache/clerezza/rdf/core/TripleCollection.html#filter(org.apache.clerezza.rdf.core.NonLiteral,%20org.apache.clerezza.rdf.core.UriRef,%20org.apache.clerezza.rdf.core.Resource)

Iterator<Triple>     filter(NonLiteral subject, UriRef predicate, 
Resource object)

vs

http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/graph/Graph.html#find(com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node)

ExtendedIterator<Triple>     find(Node s, Node p, Node o)

seems to be the fundamental choice.

The latter was the choice Chris Dollin and I made in 2002/2003 and I 
still find it preferable, for program uniformity, to the closer to the 
spec choice in Clerezza.
We were writing the spec at the same time, and I always saw it as a 
description of a Web exchange format, and not of a programming interface 
(for instance implementing RDF Semantics Rec is  hard with the Clerezza 
interface).

I am not quite sure what that means in terms of this discussion which is 
more procedural than technical.
Like in all things people make different choices and have different 
preferences, and a decision to all use the same libraries would be a 
restriction in design freedom, on such issues, which might be good, or 
might be bad.

===

On
http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201011.mbox/%3CAANLkTinwbvRUOeMFHh8ohdVvESGM09Z0aFFGSerbWiFZ@mail.gmail.com%3E
[[

- graph isomorphism code
]]

what are the goals of the Clerezza isomorphism code? The Jena code is 
essentially scoped to testing, so that I checked that small pathological 
cases were OK, and larger non-pathological cases, but it is not meant to 
have production level performance, particular on graphs for which 
something like nauty would be more appropriate.

Jeremy





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message