Author: reto
Date: Mon Jan 12 16:28:49 2015
New Revision: 1651131
URL: http://svn.apache.org/r1651131
Log:
COMMONSSITE-80: added some QAa to the Readme.
Added:
commons/sandbox/rdf/trunk/README.md
- copied, changed from r1646739, commons/sandbox/rdf/trunk/README
Removed:
commons/sandbox/rdf/trunk/README
Copied: commons/sandbox/rdf/trunk/README.md (from r1646739,
commons/sandbox/rdf/trunk/README)
URL:
http://svn.apache.org/viewvc/commons/sandbox/rdf/trunk/README.md?p2=commons/sandbox/rdf/trunk/README.md&p1=commons/sandbox/rdf/trunk/README&r1=1646739&r2=1651131&rev=1651131&view=diff
==============================================================================
--- commons/sandbox/rdf/trunk/README (original)
+++ commons/sandbox/rdf/trunk/README.md Mon Jan 12 16:28:49 2015
@@ -1,13 +1,72 @@
+## Building
-o Building
+Build using Apache Maven with
-To build, you must have Maven 2 installed. Maven can be downloaded from
+ mvn install
-http://maven.apache.org/.
+## Documentation
+You can build the documentation with:
-o Documentation
+ mvn site
+
+## FAQ
+
+Some more advanced questions focused on showing the differences to other
proposed APIs.
+
+### Can I add RdfTerms from one implementation to another?
+
+Yes, any compliant implementation of BlankNode, Iri or Literal as well as
Triple
+can be added to any implemenation of Graph, as long the Graph supports adding
triples. Implementation
+may not require the nodes to be of a particular implementation of having been
+created with a specific factory.
+
+### How does it work?
+
+Implementation might need to map instances of BlankNode to their internal
+implementation. This should be done in a way that when there is no more
reference
+to the BlankNode object (i.e. when the object can be garbage collected) the
mapping
+to the internal implementation is removed from memory to. This can be achieved
+by using a java.util.WeakHashMap
+
+### Do I get back the same object that I added?
+
+For instances of Iri or Literals you get back an object that result equal to
the
+originally added object, i.e. an object with the same HashCode and of which the
+equals method return true when compared with the originally added object. Ther
+is no guarantee that the same instance will be returned.
+For instances of BlankNode the above in only guaranteed as long as the
original
+object is referenced. When the original object becomes eligible for garbage
+collection the implementation may start returning a different (an not equal)
+object. In practice this means BlankNode objects cannot safely be serialized
+(using Java serialization) or passed around via RMI.
+
+### Can an implementation remove redundant information from a Graph?
+
+Yes, as long as this doesn't affect any BlankNode instance that is currently
+reachable (i.e. the Java object is in memory and is not eligible for garbage
+collection).
+
+For example given the non-lean graph:
+
+ ex:a ex:p _:x .
+ _:y ex:p _:x .
+
+As long as there is no BlankNode instance referencing _:y the implementation
can
+reduce the graph to:
+
+ ex:a ex:p _:x .
+
+removing the redundancy. If however there is a reachable BlankNode instance
for
+_:y the implementation must not remove the redundancy as the code which has
+access to the object can go on adding a triple:
+
+ _:y ex:p2 ex:b .
+
+Thus creating a graph that doesn't contain any internal redundancy, namely:
+
+ ex:a ex:p _:x .
+ _:y ex:p _:x .
+ _:y ex:p2 ex:b .
-You can build the documentation with:
-mvn site
