[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/43 You may have better ideas on how to do something like [ParserConfigImpl](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/ParserConfigImpl.java) so it is serializable. For instance the [ParserSource](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/ParserSource.java) beans might or might not be serializable depending on the implementation. (Surely one that is just connected to an open InputStream is not serializable, but one that has just got an IRI should be serializable. I made the implementations package private: [IRIParserSource](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/IRIParserSource.java) which meant I had to make a new [IRIImpl](https://github.com/apache/commons-rdf/blob/fluent-parser/commons-rdf-api/src/main/java/org/apache/commons/rdf/api/io/IRIImpl.java) to avoid Simple dependency) --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable
Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/43
Thanks, @ajs6f !
I found some old code where I had tried to make a fluent interface.. I
managed to update it to the current master and sorted some issues.
I pushed it to the `fluent-parser` branch
See https://github.com/apache/commons-rdf/compare/fluent-parser
I haven't implemented the `Parser` yet or written any tests.
Basically the idea is this:
```java
Parsed<Dataset, IRI> p = rdf.parserBuilder()
.syntax(RDFSyntax.JSONLD)
.source("http://example.com/data.jsonld;)
.parse();
```
or:
```java
rdf.parserBuilder()
.syntax(RDFSyntax.TURTLE)
.target(quad -> System.out.println(quad.getSubject()))
.source(Paths.get("/tmp/file.ttl").
.async().parseAsync();
```
Now there is a set of interfaces, one for each step along the way, e.g.
`NeedTarget`, and
some internal `_` package interfaces to ensure consistency (but this can be
flattened). Note that it is easier in this code to explore this in Eclipse with
auto-complete as the interfaces have not been flattened yet.
It is implemented by a single `AbstractParserBuilder` which keeps all its
state (except async executor) in a `ParserConfig` bean. The builder can be made
immutable using `.build()` after which any change will make it mutable again.
While it's mutable it will mutate the bean without any copies.
There is also a more low-level `Parser` which takes a `ParserConfig` - this
is basically how the RDF implementations can be invoked.
I have not moved over the preflight checks in AbstractRDFParser there.
Feel free to use it as a starting ground or inspiration! It's quite hard to
do fluent interfaces..
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #49: Cleanup for FindBugs and PMD warnings in -simp...
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/49#discussion_r168274256
--- Diff:
commons-rdf-simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
---
@@ -58,8 +60,12 @@
*/
public abstract class AbstractRDFParser>
implements RDFParser, Cloneable {
-public static final ThreadGroup threadGroup = new ThreadGroup("Commons
RDF parsers");
-private static final ExecutorService threadpool =
Executors.newCachedThreadPool(r -> new Thread(threadGroup, r));
+public static final AtomicInteger threadCount = new AtomicInteger();
+private static Thread newThread(Runnable r) {
--- End diff --
A final ThreadGroup that is not thread safe.. The whole purpose of it is to
group threads?
It is true that they should not be used for security purpose, but that is
not why it is here. The ThreadGroup is mainly useful for debugging as people
might see these "Commons RDF Parser" tree grouped together in the debugger
(e.g. in Eclipse) rather than the generic no-name you get from the
ExecutorService.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/43 Picking up this - @ajs6f do you still think we should proceed along those lines? I am also reluctant to making the abstract factory (builder) serializable, but I can see the reasoning, particularly if you want to use this in Hadoop or something where you have a pre-made parser builder and then tell a different node to run it. One thing I feel I need to check more is that there is no reading of the now-usually-null fields beyond the getters - I might rename them to make that clear. I have put this PR into upstream branch COMMONSRDF-49 we can contribute to. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #49: Cleanup for FindBugs and PMD warnings in -simp...
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/49#discussion_r167732171
--- Diff:
commons-rdf-simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
---
@@ -58,8 +60,12 @@
*/
public abstract class AbstractRDFParser>
implements RDFParser, Cloneable {
-public static final ThreadGroup threadGroup = new ThreadGroup("Commons
RDF parsers");
-private static final ExecutorService threadpool =
Executors.newCachedThreadPool(r -> new Thread(threadGroup, r));
+public static final AtomicInteger threadCount = new AtomicInteger();
+private static Thread newThread(Runnable r) {
--- End diff --
I disagree on this style change, the previous code was much cleaner. Why is
a method-reference on 4 lines that is only used once better than a very small
lambda?
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #43: COMMONSRDF-49: Make AbstractRDFParser serializable
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/43 Agree with @afs that only the builder-factory bit should be serialized - obviously the actual parser which may be in progress of parsing is tricky to serialize. So we would need to perhaps clean up the class names/method to separate those conserns, without going too much towards a `AbstractBuilderFactorySingletonFactory`. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/27 I've merged this. Thanks for the help, @ansell! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/27 OK, so I added them as `Set` - it might be an ordered set (e.g. `LinkedHashSet`). I merged `RDFA_XHTML` and `RDFA_HTML` and made them return such a set to include both `text/html` and `application/xhtml`. Should we redefine `.equals()` and `hashCode()` to use `uri()` or would that be tricky then for arbitrary extra RDFSyntax-es? (They could use a `urn:uuid` or something if they don't know) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/27 Let's discuss the mutability etc. of the `RDFParser` factory separate on dev@commons - that's a general thing which anyway should not affect this pull request on `RDFSyntax`. This pull requests tries to address [COMMONSRDF-47](https://issues.apache.org/jira/browse/COMMONSRDF-47) which rightfully complains about `RDFSyntax` being an enum instead of interface. @ansell - would you change your `-1` (remember any committer has veto, and any ASF committer is Commons committer :-) ) if I add the plural `RDFSyntax.mediaTypes()` and `RDFSyntax.fileExtensions()` ? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/27#discussion_r100211712
--- Diff: api/src/main/java/org/apache/commons/rdf/api/RDFSyntax.java ---
@@ -22,6 +22,124 @@
import java.util.Optional;
/**
+ * An RDF syntax, e.g. as used for parsing and writing RDF.
+ *
+ * An RDF syntax is uniquely identified by its {@link #mediaType()}, and
has a
+ * suggested {@link #fileExtension()}.
+ *
+ * Some of the RDF syntaxes may {@link #supportsDataset()}, meaning they
can
+ * represent {@link Quad}s.
+ *
+ * An enumeration of the official RDF 1.1 syntaxes is available in
+ * {@link OfficialRDFSyntax} - for convenience they are also accessible
+ * as constants here, e.g. RDFSyntax.JSONLD.
+ *
+ */
+public interface RDFSyntax {
+
+public static OfficialRDFSyntax JSONLD = OfficialRDFSyntax.JSONLD;
+public static OfficialRDFSyntax TURTLE = OfficialRDFSyntax.TURTLE;
+public static OfficialRDFSyntax NQUADS = OfficialRDFSyntax.NQUADS;
+public static OfficialRDFSyntax NTRIPLES = OfficialRDFSyntax.NTRIPLES;
+public static OfficialRDFSyntax RDFA_HTML =
OfficialRDFSyntax.RDFA_HTML;
+public static OfficialRDFSyntax RDFA_XHTML =
OfficialRDFSyntax.RDFA_XHTML;
+public static OfficialRDFSyntax RDFXML = OfficialRDFSyntax.RDFXML;
+public static OfficialRDFSyntax TRIG = OfficialRDFSyntax.TRIG;
+
+/**
+ * A short name of the RDF Syntax.
+ *
+ * The name typically corresponds to the {@link Enum#name()} of for
+ * {@link OfficialRDFSyntax}, e.g. JSONLD.
+ *
+ * @return Short name for RDF syntax
+ */
+public String name();
+
+/**
+ * The title of the RDF Syntax.
+ *
+ * This is generally the title of the corresponding standard,
+ * e.g. RDF 1.1 Turtle.
+ *
+ * @return Title of RDF Syntax
+ */
+public String title();
+
+/**
+ * The https://tools.ietf.org/html/rfc2046;>IANA media
type for
+ * the RDF syntax.
+ *
+ * The media type can be used as part of Content-Type and
+ * Accept for content negotiation in the
+ * https://tools.ietf.org/html/rfc7231#section-3.1.1.1;>HTTP
+ * protocol.
+ */
+public String mediaType();
--- End diff --
So my suggestion was that `mediaType()` has "The IANA media type" and
similar for `fileExtension()`. Arbitrary "other" media types and extensions
would have to be in a different method - perhaps the plural `mediaTypes()` and
`fileExtensions()`?
There is nothing stopping a parser from supporting other media types and
file extensions, but I'm not sure why they also need to be present in the
`RDFSyntax` interface, which main purpose is to hard-code a syntax for reading
(and maybe more so writing).
The previously proposed
[RDFParser](https://github.com/apache/commons-rdf/blob/master/api/src/main/java/org/apache/commons/rdf/experimental/RDFParser.java)
interface - which I hope we can discuss in a separate pull request / Jira
Issue - supports both `contentType(String contentType)` and
`contentType(RDFSyntax rdfSyntax)`.
It also has for `source(IRI)`:
> * The {@link #contentType(RDFSyntax)} or {@link #contentType(String)}
MAY
> * be set before calling {@link #parse()}, in which case that type MAY
be
> * used for content negotiation (e.g. Accept header in
HTTP),
> * and SHOULD be used for selecting the RDFSyntax.
while for `source(Path)` (a file) it changes to SHOULD (as file extensions
are fragile)
> * The {@link #contentType(RDFSyntax)} or {@link #contentType(String)}
> * SHOULD be set before calling {@link #parse()}.
This hints that a parser is able to do file extension or file magic, but is
not required to. Both RDF4J and Jena implementations have different mechanisms
for this, e.g.
[RDF4JParser](https://github.com/apache/commons-rdf/blob/master/rdf4j/src/main/java/org/apache/commons/rdf/rdf4j/experimental/RDF4JParser.java#L140)
falls back to `Rio.getParserFormatForFileName()` based on path filename if no
content type is specified - which would use RDF4J's extended list of file
extensions and formats.
Obviously this would be easy to implement consistently for our hard-coded
w3c-standardized file extensions (and we could document that), but much harder
for arbitrary "other" extensions.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infr
[GitHub] commons-rdf pull request #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/27#discussion_r100209281
--- Diff: api/src/main/java/org/apache/commons/rdf/api/RDFSyntax.java ---
@@ -91,7 +148,30 @@
* Datasets.
*/
public boolean supportsDataset();
+
+/**
+ * Return the RDF 1.1 serialization syntaxes.
+ *
+ * This lists the W3C standardized RDF 1.1 syntaxes like {@link
#TURTLE} and
+ * {@link #JSONLD}. Note the existence of other RDF syntaxes that are
not
+ * included here, e.g. http://www.w3.org/TeamSubmission/n3/;>N3 and
+ * https://en.wikipedia.org/wiki/TriX_%28syntax%29;>TriX.
+ *
+ * The syntaxes returned only support the {@link #mediaType()}
+ * and {@link #fileExtension()} as defined in the corresponding
+ * W3C specification.
+ *
+ * @return
+ * A set of the official RDF 1.1 {@link RDFSyntax}es.
+ *
+ * @see https://www.w3.org/TR/rdf11-primer/#section-graph-syntax;>RDF
+ * 1.1 Primer
+ * @see org.apache.commons.rdf.experimental.RDFParser
+ */
+public static Set w3cSyntaxes() {
--- End diff --
`W3CRDFSyntax` is package-protected. It was moved it out followingyour
advice, but I don't see any win in making it `public` as it has no additional
methods (and shouldn't have).
If we make it public and remove `w3cSyntaxes()` , then there's not much
more any point to have the proxy constants `RDFSyntax.TURTLE` etc. as they
would also then be made public at `W3CRDFSyntax.TURTLE` etc - which - not
withstanding the CAPSISSUE - is not as accessible for the 95% use cases of
parsing/writing a RDF 1.1 syntax.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/27#discussion_r100208441
--- Diff: api/src/main/java/org/apache/commons/rdf/api/RDFSyntax.java ---
@@ -178,17 +206,62 @@ private RDFSyntax(final String name, final String
mediaType, final String fileEx
* The fileExtension is compared in lower case, therefore
it
* might not be equal to the {@link RDFSyntax#fileExtension} of the
returned
* RDFSyntax.
+ *
+ * The list of syntaxes supported is at least those returned by
+ * {@link #w3cSyntaxes()}.
*
* @param fileExtension
*The fileExtension to match, starting with .
* @return If {@link Optional#isPresent()}, the {@link RDFSyntax}
which has
- * a matching {@link RDFSyntax#fileExtension}, otherwise
+ * a matching {@link RDFSyntax#fileExtension()}, otherwise
* {@link Optional#empty()} indicating that no matching file
* extension was found.
*/
public static Optional byFileExtension(final String
fileExtension) {
-final String ext = fileExtension.toLowerCase(Locale.ENGLISH);
-return Arrays.stream(RDFSyntax.values()).filter(t ->
t.fileExtension.equals(ext)).findAny();
+final String ext = fileExtension.toLowerCase(Locale.ROOT);
+return w3cSyntaxes().stream().filter(t ->
t.fileExtension().equals(ext))
+.findAny();
+}
+
+/**
+ * Return the RDFSyntax with the specified {@link #name()}.
+ *
+ * The list of syntaxes supported is at least those returned by
--- End diff --
Changed to
> This method support all syntaxes returned by {@link #w3cSyntaxes()}
There is no good way from a static class method to allow user extension; at
least without having a discovery mechanism (classpath sensitive) or mutable
setters/registrations (initialization sensitive) - I would argue it is out of
scope for this particular method to support that, as Commons RDF only target
RDF 1.1.
If you want we could change these lookup method to take a variable/optional
list of `Iterable` as parameters?
(The parser/writer methods would with this PR support `RDFSyntax` from
"elsewhere" - e.g. we could return supported syntaxes from each `RDF` instance)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #32: COMMONSRDF-55: Handle Jena's urn:x-arq:DefaultGraph a...
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/32 I've added javadoc to this effect (commit 7bbff25) and will merge this now. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #32: COMMONSRDF-55: Handle Jena's urn:x-arq:DefaultGraph a...
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/32 Note that option (2) would also add potential inconsistency between Commons RDF `.getGraphName().isPresent()` and `asJenaQuad().isDefaultGraph()`, which is unfortunate, but only in that from-foreign `IRI` case. I've added option (2) now to the implementation and the [new tests](https://github.com/apache/commons-rdf/blob/COMMONSRDF-55/jena/src/test/java/org/apache/commons/rdf/jena/DefaultGraphInQuadTest.java) in this branch. OK to merge? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #32: COMMONSRDF-55: Handle Jena's urn:x-arq:DefaultGraph a...
Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/32
I guess it's a question of where we put the "inconsistency" barrier. We can
probably assume that in the odd case that `urn:x-arq:DefaultGraph` appear
literally in a non-Jena `IRI` or a non-Jena `Quad` then it must have leaked out
of Jena somehow, and will be treated as a real IRI. It would magically become
the default graph only if such a quad is added to a Jena dataset.
That would mean we let Commons RDF construction by component of a
Jena-based quad preserve `g` just as in other implementations.
With option **(2)** above we would add JenaRDF-specific recognition of the
magic IRI if it happens to be backed by a Jena `Node` (which might even be
because it was made from a string).
It would probably cleaner in Commons RDF for a Quad to magically change
only on insertion to a Jena-backed Dataset, than when making the Quad with a
particular back-end - e.g. you add one quad, but a slightly different one comes
back out, which will not be `.equals()` the inserted one. This is not very
different from stores with inferred rules or blank-node adaptions. (Commons
RDF Graph/Dataset contracts do not require the exact triple/quad to be returned
back again)
So I think that would be the semantically cleanest solution, where each
`RDF` implementation behaves the same, but each `Dataset` have slight variation.
However, it is not given that a `Quad` made with `JenaRDF` will be added to
a Jena-based `Dataset`, but that is probably most likely. It is not given that
a `Node` that is `urn:x-arq:DefaultGraph` was picked from the constant
`Node.defaultNode`, but it is likely. It is not given that a literal Graph IRI
`urn:x-arq:DefaultGraph` has leaked from Jena's `Node.defaultNode, but it is
likely.
Therefore the most pragmatic for Commons RDF users, if semantically
slightly unclean, would be the option (2) as @ajs6f says. It means there would
be only this inconsistency barrier:
```java
RDF simple = new SimpleRDF();
RDF jena = new JenaRDF();
IRI defaultS = simple.createIRI("urn:x-arq:DefaultGraph")
IRI defaultJ = jena.createIRI("urn:x-arq:DefaultGraph") // or
jena.asRDFTerm(Node.defaultGraph)
assertEquals(defaultS, defaultJ);
IRI ex = jena.createIRI("http://example.com/;);
Quad q1 = jena.createQuad(defaultS, ex, ex, ex);
assertFalse(q1.getGraphName().isPresent());
assertEquals(defaultS, q1.getGraphName().get()); // as-s
Quad q2 = jena.createQuad(defaultJ, ex, ex, ex);
assertFalse(q2.getGraphName().isPresent()); // INCONSISTENT with q1
assertFalse(q1.equals(q2)); // INCONSISTENT
```
(Adding either `q1` or `q2` to a Jena-backed Dataset would both be
transferred to q2-form with `Optional.empty()` on retrieving -- adding them to
any non-Jena Dataset implementation would look like two different quads).
This will technically break the [SHOULD
contract](https://github.com/apache/commons-rdf/blob/0.3.0-incubating/api/src/main/java/org/apache/commons/rdf/api/RDF.java#L234)
of `RDF.createQuad()` which says the parameters should be preserved.
> * The returned Quad SHOULD have a {@link Quad#getGraphName()} that
is equal
> * to the provided graphName, a {@link Quad#getSubject()} that is
equal to
> * the provided subject, a {@link Quad#getPredicate()} that is equal
to the
> * provided predicate, and a {@link Quad#getObject()} that is equal to
the
> * provided object.
but I think this is a valid breaking of SHOULD, particularly if we do it
only on "our own" Jena-backed IRIs.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #32: COMMONSRDF-55: Handle Jena's urn:x-arq:DefaultGraph a...
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/32 The thing is a Commons RDF `JenaQuad` has in a way two feet into Jena - the underlying Jena `Quad` as well as the underlying `Node` instances (which would be wrapped as `RDFTerm` instances). So the challenge is that it's also possible to make a Commons RDF `JenaQuad` using both adapting a quad from Jena (as when being retrieved from the Dataset), as well as composed from `RDFTerm` instances with the `JenaRDF.createQuad(g,s,p,o)` method -- such constructing will currently keep fields for the Commons RDF wrappers of the `RDFTerm`s optional(g),s,p,o, and only make the underlying Jena-backed `Quad` on-demand on first call to [asJenaQuad](https://github.com/apache/commons-rdf/blob/0.3.0-incubating/jena/src/main/java/org/apache/commons/rdf/jena/impl/AbstractQuadLike.java#L92). Commons RDF methods like `.equals()` and `.hashCode()` then use the individual graph/subject/predicate/object `RDFTerm` fields which are always initialized - thus from the Commons RDF side in a way the Quad object is ready-already, while it's Jena-nature might be incomplete until needed (e.g. being added to a Dataset). Currently the constructor from a JenaQuad will unwrap to create the [RDFTerm g/s/p/o](https://github.com/apache/commons-rdf/blob/0.3.0-incubating/jena/src/main/java/org/apache/commons/rdf/jena/impl/AbstractQuadLike.java#L74) -- with this PR this would check Quad.isDefaultGraph() before unwrapping the graph name. It could in theory be done the other way, to keep the Jena-backed org.apache.jena.sparql.core.Quad as the master backend field, and rather generate the `RDFTerm` wrappers on demand, in which case first call to `getGraphName()` would simply check `isDefaultGraph()` -- but it would make it trickier to keep `AbstractQuadLike` common for both `Quad` and `Triple`, as Jena's `Quad` does not have a common superclass with Jena's `Triple`, there would be two alternate fields for the master (or a more complicated abstract class hierarchy). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #32: COMMONSRDF-55: Handle Jena's urn:x-arq:DefaultGraph a...
Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/32
The Commons RDF marker for the default graph (as of today) is
`Optional.empty()` and not an `RDFNode` (and thus can only be used in the
`Quad.getGraphName()` position).
There are four boundaries that can create Commons RDF Quad instances from
Jena:
* **Retrieving:**
[Dataset.stream()](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/api/Dataset.html#stream--),
`.iterate()` and friends
* **Adapting:**
[JenaRDF.asQuad(jenaQuad)](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/jena/JenaRDF.html#asQuad-org.apache.jena.sparql.core.Quad-)
* **Creating:**
[JenaRDF](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/jena/JenaRDF.html#createQuad-org.apache.commons.rdf.api.BlankNodeOrIRI-org.apache.commons.rdf.api.BlankNodeOrIRI-org.apache.commons.rdf.api.IRI-org.apache.commons.rdf.api.RDFTerm-)
with a graph `IRI` adapted from a Node using
[JenaRDF.asRDFTerm(Quad.defaultGraph)](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/jena/JenaRDF.html#asRDFTerm-org.apache.jena.graph.Node-)
* ..in worst case, `IRI` from `RDF.createIRI("urn:x-arq:DefaultGraph")
* **Parsing:** JenaRDFParser - which uses JenaRDF.asQuad (experimental)
I think we MUST do the _Retrieving_ - triples in the default graph
according to the RDF 1.1 should still be in the default graph according to
[org.apache.commons.rdf.api.Quad](https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/api/Quad.html)
- importantly it must be `.equals()` an equivalent quad statement in a
different implementation. I think we all agree on this.
Similarly _Parsing_ we MUST handle - at least when it's no longer
experimental.
The question is how helpful we should be in the other cases. If someone is
_adapting_ a Jena Quad, then I think it also MUST convert to `Optional.empty()`
although it keeps the original Jena quad underneath, which can distinguish
between the two default variants, if needed.
Now that leaves _creating_ which is a bit more speculative - we don't know
where the graph `IRI` comes from, and other `RDF` implementations do of course
not do anything special with `urn:x-arq:DefaultGraph`. However it is unlikely
that such an IRI would be used in a non-Jena context.
So here are three options for what `RDF.createQuad(g,s,p,o) should do if g
is `urn:x-arq:DefaultGraph` or `urn:x-arq:DefaultGraphNode`:
1) Always recognize `urn:x-arq:DefaultGraph` and friends (either by
comparing of IRI string against the `Quad.defaultGraph` and
`Quad.defaultGraphNode` constants (this PR), or adapting/unwrapping to the
equivalent Jena `Node` and then checking with `Quad.isDefaultGraph(Node)`
(might be less efficient)
2) Only recognize if it is a `org.apache.commons.rdf.jena.JenaIRI` instance
by using `Quad.isDefaultGraph(iri.asJenaNode())`
3) Never recognize it, IRI will be left as-is. Insertion of such a `Quad`
to a Jena-backed Dataset will then have different semantics then in other
`Dataset`s
I think it's an edge-case with people creating it by hand from the IRI
string with `RDF.createIRI()` - particularly with a non-Jena `RDF` instance,
although that could be the case in queries against the union graph. (but that
would only be in SPARQL world, right?).
However it might be conceivable that `Node` from `Quad.defaultGraph` is
used in Jena-centric code that adds Commons RDF at the edge.
Boundaries from Commons RDF to Jena are simpler, as we just always use
`urn:x-arq:DefaultGraph` (not `null`!) except where there's a pre-existing Jena
`Quad` which is left as-is.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #32: COMMONSRDF-55: Handle Jena's urn:x-arq:DefaultGraph a...
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/32 Any comments from perhaps @afs or @ajs6f? I'm not sure exactly at what boundary we should replace `` and friends with `Optional.empty()` -- in the solution of this PR it happens for any Quad created with `JenaRDF` - but of course that would not happen in other `RDF` instances. This suggestion would also convert any "foreign" `IRI` instances of `` when given as a graph name. I'll admit there's potential for information loss if the alternate `` is used as a string IRI or Node when making a Commons RDF Quad - this PR will adapt it into ` when later making the Jena `Quad` instance from the field of Optional.empty(), however Jena's `DatasetGraph` also does that conversion. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #32: COMMONSRDF-55: Handle Jena's urn:x-arq:Default...
GitHub user stain opened a pull request: https://github.com/apache/commons-rdf/pull/32 COMMONSRDF-55: Handle Jena's urn:x-arq:DefaultGraph and friends This fixes [COMMONSRDF-55](https://issues.apache.org/jira/browse/COMMONSRDF-55) by adding special testing of Jena's `urn:x-arq:DefaultGraph` and friends when creating a Quad. It also fixes a NullPointerException as previously we wrongly did `Quad.create(null, s,p,o)` with Jena, but `null` is not a valid graph name - `Quad.defaultGraphIRI` should be used instead. Note that I did not hard-code `urn:x-arq:DefaultGraph` but use `IRI.equals()` against `Quad.defaultGraphIRI` and `Quad.defaultGraphNodeGenerated`. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/commons-rdf COMMONSRDF-55 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-rdf/pull/32.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #32 commit bb264738aa0e3c3a8e9ae8bba0d7109cfb59adaa Author: Stian Soiland-Reyes <st...@apache.org> Date: 2017-01-27T17:26:59Z COMMONSRDF-55: Handle Jena's urn:x-arq:DefaultGraph and friends --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #30: COMMONSRDF-51 language tags compared lower case
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/30 I propose now to merge this branch following COMMONSRDF-55 fixing. Thanks everyone! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #30: COMMONSRDF-51 language tags compared lower case
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/30 Thanks @afs , that makes sense, `JenaGraphImpl` was indeed using `graph.delete()`. I have fixed in both `JenaGraphImpl` and `JenaDatasetImpl`. See comment - do you think there is much performance gain from not splitting into pattern but passing the original Jena Triple (safe only when there's no Literal object with langtag) - or shall we always use the pattern? (e.g. would Jena TDB do things like get an internal Triple row ID out of the jena `Triple` for faster delete?) I added tests for Dataset that reveals that statements in default graph come back from Jena in the named graph `` - that's a separate bug in `JenaDatasetImpl` and the converters - we should represent that always as `Optional.empty()` in Commons RDF land. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #31: COMMONSRDF-54: overloads of RDF4J#asRDFTerm
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/31 Thanks, this looks sensible to me! Should we add unit test for each of the new `asRDFTerm` methods? They are in a way already tested through `createLiteral` etc.., but just so we don't break it later? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #30: COMMONSRDF-51 language tags compared lower case
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/30 I added equivalent tests for `Graph` add/contains/remove, and this fails for Jena: ``` java.lang.AssertionError at org.junit.Assert.fail(Assert.java:86) at org.junit.Assert.assertTrue(Assert.java:41) at org.junit.Assert.assertFalse(Assert.java:64) at org.junit.Assert.assertFalse(Assert.java:74) at org.apache.commons.rdf.api.AbstractGraphTest.containsLanguageTagsCaseInsensitive(AbstractGraphTest.java:415) ... ``` basically if I add `"Hello"@EN-GB` to a Jena Graph and then try to remove `"Hello"@en-GB` then the statement remains in the graph as `"Hello"@EN-GB`. How can we fix this? It would not be enough to just lowercase in all Commons RDF methods with Jena Literal language tags, as the Jena graph/model could be populated through other means (e.g. parsing a file). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #30: COMMONSRDF-51 language tags compared lower case
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/30 OK, so then it makes sense for the Commons RDF tests to only care about the value being preserved (whatever the case going in or out is upper or lower), and that our .equals and .hashCode is based on lowercase in the ROOT Locale. We don't have equivalent tests if datatyped floats etc preserve their specific syntactic value (e.g. "-.0"^^xsd:float) so we should not do that for langtags either. I'll modify the branch and merge. On 21 Jan 2017 9:39 pm, "Andy Seaborne" <notificati...@github.com> wrote: > RDF 1.1 mentions: > >1. Turtle parsing - there is a lang tag rule. >2. The text that conversion to a lowercase lexical is allowed. >3. Value-comparison is case insensitive. > > Which is that test for? Lexical or value? > > At least acknowledging that RDF's "lowercase" is not in keeping with BCP > 47 syntax canonicalization (the registry may change the characters) > whatever the spec makes sense to me and I suspect domain experts; it's > following the spec that "owns" language tags. Focus on the value comparison. > > â > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/apache/commons-rdf/pull/30#issuecomment-274290063>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAPd5Q9mhDWV3MwkRzl0QLO5FS7bVl6Wks5rUnsmgaJpZM4Lh1hF> > . > --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #30: COMMONSRDF-51 language tags compared lower case
Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/30
Right, BCP47 normalisation would make sense, but sadly that is not directly
permitted by RDF 1.1, only normalisation to lower case :-( - probably to
avoid dependency on the registry.
However I think we can try to make Commons RDF present a consistent RDF
1.1-compliant view, which I would think includes that creating a literal
with en-gb lowercase would return en-gb lowercase, also with RDF4J as back
end. (Would this require our wrapper LiteralImpl to always lowercase for
RDF4J?)
Can we extend the RDF4J test to also cover the other settings? How are they
provided? If the user is explicitly asking to go beyond the RDF standards,
then they should not be surprised if Commons RDF's view goes along with
that (or falls over), so then perhaps we don't need to worry about it here?
(e.g. Jena can be configured to support generalized RDF which don't work
well with the normal TripleImpl).
On 16 Jan 2017 9:52 pm, "Peter Ansell" <notificati...@github.com> wrote:
*@ansell* commented on this pull request.
Looks fairly good to me. I disagree with the test assertion that disallows
normalisation using the BCP47 conventions (e.g., en-GB) in their
constructors, but it is a minor issue.
--
In api/src/test/java/org/apache/commons/rdf/api/AbstractRDFTest.java
<https://github.com/apache/commons-rdf/pull/30#pullrequestreview-16887719>:
> @@ -194,6 +194,114 @@ public void testCreateLiteralLangISO693_3() throws
Exception {
assertEquals("\"Herbert Van de Sompel\"@vls",
vls.ntriplesString());
}
+public void testCreateLiteralLangCaseInsensitive() throws Exception {
Does this need @Test <https://github.com/Test> annotation?
--
In api/src/test/java/org/apache/commons/rdf/api/AbstractRDFTest.java
<https://github.com/apache/commons-rdf/pull/30#pullrequestreview-16887719>:
> @@ -194,6 +194,114 @@ public void testCreateLiteralLangISO693_3() throws
Exception {
assertEquals("\"Herbert Van de Sompel\"@vls",
vls.ntriplesString());
}
+public void testCreateLiteralLangCaseInsensitive() throws Exception {
+// COMMONSRDF-51: Literal langtag may not be in lowercase, but
+// must be COMPARED (aka .equals and .hashCode()) in lowercase
+// as the language space is lower case.
+final Literal lower = factory.createLiteral("Hello", "en-gb");
+final Literal upper = factory.createLiteral("Hello", "EN-GB");
+final Literal mixed = factory.createLiteral("Hello", "en-GB");
+
+
+assertEquals("en-gb", lower.getLanguageTag().get());
RDF4J may not follow this in some cases. It may use the BCP47 normalisation
conventions to obtain en-GB instead.
â
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/apache/commons-rdf/pull/30#pullrequestreview-16887719>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAPd5Zd7XV-563iLQNzvWAEI4dO7Hm4Qks5rS-aYgaJpZM4Lh1hF>
.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #30: COMMONSRDF-51 language tags compared lower case
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/30 There seems to be consensus on http://lists.w3.org/Archives/Public/public-rdf-comments/2017Jan/thread.html and http://lists.w3.org/Archives/Public/semantic-web/2017Jan/thread.html in the _Are literal language tags case sensitive?_ threads that it is not meant to be a change from RDF 1.0 - that language tags should still be compared case insensitively. That should be inline with what this PR suggests - case insensitive in `.equals()` and `.hashCode()` Do you agree on that line, @afs and @ansell ..? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #30: COMMONSRDF-51 language tags compared lower case
Github user stain commented on the issue:
https://github.com/apache/commons-rdf/pull/30
This pull request returns `getLanguageTag()` in whatever case the
underlying platform does (e.g. I think RDF4J and JSONLD-Java preserves casing,
while Jena and Simple converts to lowercase.
I think it is only in `.equals()` and `.hashCode()` we need case
insensitivity.
There's arguments both ways if we should provide a consistent view across
the implementations (e.g. always lowercase); or if we should provide a
consistency with what the underlying implementation does (e.g. if it is
preserves casing for presentation purposes).
Commons RDF don't have any value handling mechanisms now for say
converting`"13.37"^^xsd:float` to a Java float `13.37f` (without going through
the underlying implementations and related methods); or determining value
equality, so I think it is not too weird if Commons RDF doesn't do anything
clever about language tags either (beyond spec compliance).
But if someone were to add a Common RDF API for such literal value
handling, it could be natural to also add "utils" methods for presenting or
parsing language tags (e.g. `isLanguageTagEqual("en-us", "en-US")` as well as
hierarchical comparisons, something like `isSameLanguageTagFamily("en-us",
"en-GB")`
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/27#discussion_r95843235
--- Diff:
simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
---
@@ -240,7 +240,7 @@ public T rdfTermFactory(RDF rdfTermFactory) {
public T contentType(RDFSyntax rdfSyntax) throws
IllegalArgumentException {
AbstractRDFParser c = clone();
c.contentTypeSyntax = Optional.ofNullable(rdfSyntax);
-c.contentType = c.contentTypeSyntax.map(syntax ->
syntax.mediaType);
+c.contentType = c.contentTypeSyntax.map(syntax ->
syntax.mediaType());
return c.asT();
--- End diff --
It's just a generics trick so that subclasses of `AbstractRDFParser` can
return their own type in all the setter methods rather than `RDFParser` or
`AbstractRDFParser`, which would hide any additional methods they specialize
with.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/27#discussion_r95843006
--- Diff:
simple/src/main/java/org/apache/commons/rdf/simple/experimental/AbstractRDFParser.java
---
@@ -240,7 +240,7 @@ public T rdfTermFactory(RDF rdfTermFactory) {
public T contentType(RDFSyntax rdfSyntax) throws
IllegalArgumentException {
AbstractRDFParser c = clone();
--- End diff --
No, but cloning means the `RDFParser` is immutable and can be reused in a
thread-safe manner, e.g. if parsing many Turtle files in the same folder. So
what is worse..:
* a) Creating 1000 RDFParser instances, setting all parameters every time,
and remember not to reuse/share in multiple threads.
* b) Create a single base RDFParser instance with the common settings, then
specialize only what is needed for each file to use in any thread at any time.
(e.g. called from a within a `Stream.parallell().map()`
I think the overhead of cloning here is pretty much equivalent, e.g. `1000`
instances, or `1005` instances.
If you are parsing just a single file then I don't think the inefficiency
of the cloning makes a big difference - that is unless you are making a very
snappy UI or something.
Let's change this to mutable only if benchmark numbers show a problem?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/27#discussion_r95841290
--- Diff: api/src/main/java/org/apache/commons/rdf/api/RDFSyntax.java ---
@@ -34,7 +152,7 @@
* 1.1 Primer
* @see org.apache.commons.rdf.experimental.RDFParser
*/
-public enum RDFSyntax {
+ public enum OfficialRDFSyntax implements RDFSyntax {
--- End diff --
I also wanted to list the `IRI` identifying the syntaxes, but then I would
need a complete `IRIImpl` within `api/` .. or move `W3CRDFSyntax` to `simple/`.
(or.. awkwardly.. ask for an `RDF` instance :))
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/27#discussion_r95841065
--- Diff: api/src/main/java/org/apache/commons/rdf/api/RDFSyntax.java ---
@@ -22,6 +22,124 @@
import java.util.Optional;
/**
+ * An RDF syntax, e.g. as used for parsing and writing RDF.
+ *
+ * An RDF syntax is uniquely identified by its {@link #mediaType()}, and
has a
+ * suggested {@link #fileExtension()}.
+ *
+ * Some of the RDF syntaxes may {@link #supportsDataset()}, meaning they
can
+ * represent {@link Quad}s.
+ *
+ * An enumeration of the official RDF 1.1 syntaxes is available in
+ * {@link OfficialRDFSyntax} - for convenience they are also accessible
+ * as constants here, e.g. RDFSyntax.JSONLD.
+ *
+ */
+public interface RDFSyntax {
+
+public static OfficialRDFSyntax JSONLD = OfficialRDFSyntax.JSONLD;
+public static OfficialRDFSyntax TURTLE = OfficialRDFSyntax.TURTLE;
+public static OfficialRDFSyntax NQUADS = OfficialRDFSyntax.NQUADS;
+public static OfficialRDFSyntax NTRIPLES = OfficialRDFSyntax.NTRIPLES;
+public static OfficialRDFSyntax RDFA_HTML =
OfficialRDFSyntax.RDFA_HTML;
+public static OfficialRDFSyntax RDFA_XHTML =
OfficialRDFSyntax.RDFA_XHTML;
+public static OfficialRDFSyntax RDFXML = OfficialRDFSyntax.RDFXML;
+public static OfficialRDFSyntax TRIG = OfficialRDFSyntax.TRIG;
+
+/**
+ * A short name of the RDF Syntax.
+ *
+ * The name typically corresponds to the {@link Enum#name()} of for
+ * {@link OfficialRDFSyntax}, e.g. JSONLD.
+ *
+ * @return Short name for RDF syntax
+ */
+public String name();
+
+/**
+ * The title of the RDF Syntax.
+ *
+ * This is generally the title of the corresponding standard,
+ * e.g. RDF 1.1 Turtle.
+ *
+ * @return Title of RDF Syntax
+ */
+public String title();
+
+/**
+ * The https://tools.ietf.org/html/rfc2046;>IANA media
type for
+ * the RDF syntax.
+ *
+ * The media type can be used as part of Content-Type and
+ * Accept for content negotiation in the
+ * https://tools.ietf.org/html/rfc7231#section-3.1.1.1;>HTTP
+ * protocol.
+ */
+public String mediaType();
+
+/**
+ * The https://tools.ietf.org/html/rfc2046;>IANA-registered
+ * file extension.
+ *
+ * The file extension includes the leading period, e.g.
.jsonld
+ */
+public String fileExtension();
+
+/**
+ * Indicate if this RDF syntax supports
+ * https://www.w3.org/TR/rdf11-concepts/#section-dataset;>RDF
+ * Datasets.
+ */
+public boolean supportsDataset();
+
+
+/**
+ * Return the RDFSyntax with the specified media type.
+ *
+ * The mediaType is compared in lower case, therefore it
might
+ * not be equal to the {@link RDFSyntax#mediaType} of the returned
+ * RDFSyntax.
+ *
+ * For convenience matching of media types used in a
+ * Content-Type header, if the mediaType
contains
+ * the characters ;, , or white space, only
the
+ * part of the string to the left of those characters are considered.
+ *
+ * @param mediaType
+ *The media type to match
+ * @return If {@link Optional#isPresent()}, the {@link RDFSyntax}
which has
+ * a matching {@link RDFSyntax#mediaType}, otherwise
+ * {@link Optional#empty()} indicating that no matching syntax
was
+ * found.
+ */
+public static Optional byMediaType(String mediaType) {
+final String type =
mediaType.toLowerCase(Locale.ENGLISH).split("\\s*[;,]", 2)[0];
+return Arrays.stream(OfficialRDFSyntax.values()).filter(t ->
t.mediaType().equals(type))
--- End diff --
Changed `OfficialRDFSyntax` to a package-protected class `W3CRDFSyntax`
and referred to its instances.
`values()` renamed to `w3cSyntaxes()` which return a `Set`. I
don't think we need to make a `HashMap` from media type/extension to
`RDFSyntax` as there's only 8 instances to iterate over anyway.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/27#discussion_r95840655
--- Diff: api/src/main/java/org/apache/commons/rdf/api/RDFSyntax.java ---
@@ -22,6 +22,124 @@
import java.util.Optional;
/**
+ * An RDF syntax, e.g. as used for parsing and writing RDF.
+ *
+ * An RDF syntax is uniquely identified by its {@link #mediaType()}, and
has a
+ * suggested {@link #fileExtension()}.
+ *
+ * Some of the RDF syntaxes may {@link #supportsDataset()}, meaning they
can
+ * represent {@link Quad}s.
+ *
+ * An enumeration of the official RDF 1.1 syntaxes is available in
+ * {@link OfficialRDFSyntax} - for convenience they are also accessible
+ * as constants here, e.g. RDFSyntax.JSONLD.
+ *
+ */
+public interface RDFSyntax {
+
+public static OfficialRDFSyntax JSONLD = OfficialRDFSyntax.JSONLD;
+public static OfficialRDFSyntax TURTLE = OfficialRDFSyntax.TURTLE;
+public static OfficialRDFSyntax NQUADS = OfficialRDFSyntax.NQUADS;
+public static OfficialRDFSyntax NTRIPLES = OfficialRDFSyntax.NTRIPLES;
+public static OfficialRDFSyntax RDFA_HTML =
OfficialRDFSyntax.RDFA_HTML;
+public static OfficialRDFSyntax RDFA_XHTML =
OfficialRDFSyntax.RDFA_XHTML;
+public static OfficialRDFSyntax RDFXML = OfficialRDFSyntax.RDFXML;
+public static OfficialRDFSyntax TRIG = OfficialRDFSyntax.TRIG;
+
+/**
+ * A short name of the RDF Syntax.
+ *
+ * The name typically corresponds to the {@link Enum#name()} of for
+ * {@link OfficialRDFSyntax}, e.g. JSONLD.
+ *
+ * @return Short name for RDF syntax
+ */
+public String name();
+
+/**
+ * The title of the RDF Syntax.
+ *
+ * This is generally the title of the corresponding standard,
+ * e.g. RDF 1.1 Turtle.
+ *
+ * @return Title of RDF Syntax
+ */
+public String title();
+
+/**
+ * The https://tools.ietf.org/html/rfc2046;>IANA media
type for
+ * the RDF syntax.
+ *
+ * The media type can be used as part of Content-Type and
+ * Accept for content negotiation in the
+ * https://tools.ietf.org/html/rfc7231#section-3.1.1.1;>HTTP
+ * protocol.
+ */
+public String mediaType();
+
+/**
+ * The https://tools.ietf.org/html/rfc2046;>IANA-registered
+ * file extension.
+ *
+ * The file extension includes the leading period, e.g.
.jsonld
+ */
+public String fileExtension();
+
+/**
+ * Indicate if this RDF syntax supports
+ * https://www.w3.org/TR/rdf11-concepts/#section-dataset;>RDF
+ * Datasets.
+ */
+public boolean supportsDataset();
+
+
+/**
+ * Return the RDFSyntax with the specified media type.
+ *
+ * The mediaType is compared in lower case, therefore it
might
+ * not be equal to the {@link RDFSyntax#mediaType} of the returned
+ * RDFSyntax.
+ *
+ * For convenience matching of media types used in a
+ * Content-Type header, if the mediaType
contains
+ * the characters ;, , or white space, only
the
+ * part of the string to the left of those characters are considered.
+ *
+ * @param mediaType
+ *The media type to match
+ * @return If {@link Optional#isPresent()}, the {@link RDFSyntax}
which has
+ * a matching {@link RDFSyntax#mediaType}, otherwise
+ * {@link Optional#empty()} indicating that no matching syntax
was
+ * found.
+ */
+public static Optional byMediaType(String mediaType) {
+final String type =
mediaType.toLowerCase(Locale.ENGLISH).split("\\s*[;,]", 2)[0];
--- End diff --
I changed it to only support the media type format as @acoburn suggests,
not the content type which can list multiple types (parsing a `Content-Type`
header properly requires more work!)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/27#discussion_r95840484
--- Diff: api/src/main/java/org/apache/commons/rdf/api/RDFSyntax.java ---
@@ -22,6 +22,124 @@
import java.util.Optional;
/**
+ * An RDF syntax, e.g. as used for parsing and writing RDF.
+ *
+ * An RDF syntax is uniquely identified by its {@link #mediaType()}, and
has a
+ * suggested {@link #fileExtension()}.
+ *
+ * Some of the RDF syntaxes may {@link #supportsDataset()}, meaning they
can
+ * represent {@link Quad}s.
+ *
+ * An enumeration of the official RDF 1.1 syntaxes is available in
+ * {@link OfficialRDFSyntax} - for convenience they are also accessible
+ * as constants here, e.g. RDFSyntax.JSONLD.
+ *
+ */
+public interface RDFSyntax {
+
+public static OfficialRDFSyntax JSONLD = OfficialRDFSyntax.JSONLD;
+public static OfficialRDFSyntax TURTLE = OfficialRDFSyntax.TURTLE;
+public static OfficialRDFSyntax NQUADS = OfficialRDFSyntax.NQUADS;
+public static OfficialRDFSyntax NTRIPLES = OfficialRDFSyntax.NTRIPLES;
+public static OfficialRDFSyntax RDFA_HTML =
OfficialRDFSyntax.RDFA_HTML;
+public static OfficialRDFSyntax RDFA_XHTML =
OfficialRDFSyntax.RDFA_XHTML;
+public static OfficialRDFSyntax RDFXML = OfficialRDFSyntax.RDFXML;
+public static OfficialRDFSyntax TRIG = OfficialRDFSyntax.TRIG;
+
+/**
+ * A short name of the RDF Syntax.
+ *
+ * The name typically corresponds to the {@link Enum#name()} of for
+ * {@link OfficialRDFSyntax}, e.g. JSONLD.
+ *
+ * @return Short name for RDF syntax
+ */
+public String name();
+
+/**
+ * The title of the RDF Syntax.
+ *
+ * This is generally the title of the corresponding standard,
+ * e.g. RDF 1.1 Turtle.
+ *
+ * @return Title of RDF Syntax
+ */
+public String title();
+
+/**
+ * The https://tools.ietf.org/html/rfc2046;>IANA media
type for
+ * the RDF syntax.
+ *
+ * The media type can be used as part of Content-Type and
+ * Accept for content negotiation in the
+ * https://tools.ietf.org/html/rfc7231#section-3.1.1.1;>HTTP
+ * protocol.
+ */
+public String mediaType();
+
+/**
+ * The https://tools.ietf.org/html/rfc2046;>IANA-registered
+ * file extension.
+ *
+ * The file extension includes the leading period, e.g.
.jsonld
+ */
+public String fileExtension();
+
+/**
+ * Indicate if this RDF syntax supports
+ * https://www.w3.org/TR/rdf11-concepts/#section-dataset;>RDF
+ * Datasets.
+ */
+public boolean supportsDataset();
+
+
--- End diff --
I think that is out of scope for now, as Commons RDF does not specify
namespace preservation yet anywhere else.
Let's revisit that when we make `RDFWriter` where it might be a bit more
natural than in `RDFParser` (although I know RDF4J can preserve parsed
namespaces)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/27#discussion_r95840249
--- Diff: api/src/main/java/org/apache/commons/rdf/api/RDFSyntax.java ---
@@ -22,6 +22,124 @@
import java.util.Optional;
/**
+ * An RDF syntax, e.g. as used for parsing and writing RDF.
+ *
+ * An RDF syntax is uniquely identified by its {@link #mediaType()}, and
has a
+ * suggested {@link #fileExtension()}.
+ *
+ * Some of the RDF syntaxes may {@link #supportsDataset()}, meaning they
can
+ * represent {@link Quad}s.
+ *
+ * An enumeration of the official RDF 1.1 syntaxes is available in
+ * {@link OfficialRDFSyntax} - for convenience they are also accessible
+ * as constants here, e.g. RDFSyntax.JSONLD.
+ *
+ */
+public interface RDFSyntax {
+
+public static OfficialRDFSyntax JSONLD = OfficialRDFSyntax.JSONLD;
+public static OfficialRDFSyntax TURTLE = OfficialRDFSyntax.TURTLE;
+public static OfficialRDFSyntax NQUADS = OfficialRDFSyntax.NQUADS;
+public static OfficialRDFSyntax NTRIPLES = OfficialRDFSyntax.NTRIPLES;
+public static OfficialRDFSyntax RDFA_HTML =
OfficialRDFSyntax.RDFA_HTML;
+public static OfficialRDFSyntax RDFA_XHTML =
OfficialRDFSyntax.RDFA_XHTML;
+public static OfficialRDFSyntax RDFXML = OfficialRDFSyntax.RDFXML;
+public static OfficialRDFSyntax TRIG = OfficialRDFSyntax.TRIG;
+
+/**
+ * A short name of the RDF Syntax.
+ *
+ * The name typically corresponds to the {@link Enum#name()} of for
+ * {@link OfficialRDFSyntax}, e.g. JSONLD.
+ *
+ * @return Short name for RDF syntax
+ */
+public String name();
+
+/**
+ * The title of the RDF Syntax.
+ *
+ * This is generally the title of the corresponding standard,
+ * e.g. RDF 1.1 Turtle.
+ *
+ * @return Title of RDF Syntax
+ */
+public String title();
+
+/**
+ * The https://tools.ietf.org/html/rfc2046;>IANA media
type for
+ * the RDF syntax.
+ *
+ * The media type can be used as part of Content-Type and
+ * Accept for content negotiation in the
+ * https://tools.ietf.org/html/rfc7231#section-3.1.1.1;>HTTP
+ * protocol.
+ */
+public String mediaType();
+
+/**
+ * The https://tools.ietf.org/html/rfc2046;>IANA-registered
+ * file extension.
+ *
+ * The file extension includes the leading period, e.g.
.jsonld
+ */
+public String fileExtension();
--- End diff --
No :-)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #27: COMMONSRDF-47 RDFSyntax as an interface
Github user stain commented on a diff in the pull request:
https://github.com/apache/commons-rdf/pull/27#discussion_r95840179
--- Diff: api/src/main/java/org/apache/commons/rdf/api/RDFSyntax.java ---
@@ -22,6 +22,124 @@
import java.util.Optional;
/**
+ * An RDF syntax, e.g. as used for parsing and writing RDF.
+ *
+ * An RDF syntax is uniquely identified by its {@link #mediaType()}, and
has a
+ * suggested {@link #fileExtension()}.
+ *
+ * Some of the RDF syntaxes may {@link #supportsDataset()}, meaning they
can
+ * represent {@link Quad}s.
+ *
+ * An enumeration of the official RDF 1.1 syntaxes is available in
+ * {@link OfficialRDFSyntax} - for convenience they are also accessible
+ * as constants here, e.g. RDFSyntax.JSONLD.
+ *
+ */
+public interface RDFSyntax {
+
+public static OfficialRDFSyntax JSONLD = OfficialRDFSyntax.JSONLD;
+public static OfficialRDFSyntax TURTLE = OfficialRDFSyntax.TURTLE;
+public static OfficialRDFSyntax NQUADS = OfficialRDFSyntax.NQUADS;
+public static OfficialRDFSyntax NTRIPLES = OfficialRDFSyntax.NTRIPLES;
+public static OfficialRDFSyntax RDFA_HTML =
OfficialRDFSyntax.RDFA_HTML;
+public static OfficialRDFSyntax RDFA_XHTML =
OfficialRDFSyntax.RDFA_XHTML;
+public static OfficialRDFSyntax RDFXML = OfficialRDFSyntax.RDFXML;
+public static OfficialRDFSyntax TRIG = OfficialRDFSyntax.TRIG;
+
+/**
+ * A short name of the RDF Syntax.
+ *
+ * The name typically corresponds to the {@link Enum#name()} of for
+ * {@link OfficialRDFSyntax}, e.g. JSONLD.
+ *
+ * @return Short name for RDF syntax
+ */
+public String name();
+
+/**
+ * The title of the RDF Syntax.
+ *
+ * This is generally the title of the corresponding standard,
+ * e.g. RDF 1.1 Turtle.
+ *
+ * @return Title of RDF Syntax
+ */
+public String title();
+
+/**
+ * The https://tools.ietf.org/html/rfc2046;>IANA media
type for
+ * the RDF syntax.
+ *
+ * The media type can be used as part of Content-Type and
+ * Accept for content negotiation in the
+ * https://tools.ietf.org/html/rfc7231#section-3.1.1.1;>HTTP
+ * protocol.
+ */
+public String mediaType();
--- End diff --
No, only the official media type and extension should be used in this
interface - however subtypes might add `mediaTypes()` and similar, or list
several `RDFSyntax` instances (which would then not be `.equal()`).
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf pull request #30: COMMONSRDF-51 language tags compared lower cas...
GitHub user stain opened a pull request: https://github.com/apache/commons-rdf/pull/30 COMMONSRDF-51 language tags compared lower case This fixes [COMMONSRDF-51](https://issues.apache.org/jira/browse/COMMONSRDF-51) - at least from `Literal.equals()` and `Literal.hashCode()` Further test might be needed to verify consistent behaviour in `Graph` and `Dataset` if underlying framework does not correctly do langtag comparison in lower case (e.g. Turkish locale problem). Please comment on the fixes and the suggested updated javadoc: * [Literal.equals(Object)](http://stain.github.io/commons-rdf/COMMONSRDF-51/org/apache/commons/rdf/api/Literal.html#equals-java.lang.Object-) * [Literal.hashCode()](http://stain.github.io/commons-rdf/COMMONSRDF-51/org/apache/commons/rdf/api/Literal.html#hashCode--) * [Literal.getLanguageTag()](http://stain.github.io/commons-rdf/COMMONSRDF-51/org/apache/commons/rdf/api/Literal.html#getLanguageTag--) For code improvements of this PR, feel free to push to the `COMMONSRDF-51-langtag-lcase` branch at https://git-wip-us.apache.org/repos/asf/commons-rdf.git or use the "Start review" mechanism in GitHub. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/commons-rdf COMMONSRDF-51-langtag-lcase Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-rdf/pull/30.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #30 commit 3064d219606cbe42c0150d81dbf6cdbc74bf7491 Author: Stian Soiland-Reyes <st...@apache.org> Date: 2017-01-12T14:51:26Z COMMONSRDF-51: compare language tags in lower case --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-rdf issue #28: COMMONSRDF-52 set distinct Bundle-SymbolicName values
Github user stain commented on the issue: https://github.com/apache/commons-rdf/pull/28 Thanks! Merged. I also added you as a `` to be shown on https://commons.apache.org/proper/commons-rdf/team-list.html - hope that's OK. Any other OSGi issues? How do you do the equivalent of `ServiceLoader` of `RDF` instances? Do we need to make OSGi service annotations/XML? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-lang pull request: README.md - avoid 404 links
Github user stain closed the pull request at: https://github.com/apache/commons-lang/pull/62 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GitHub] commons-lang pull request: README.md - avoid 404 links
GitHub user stain opened a pull request: https://github.com/apache/commons-lang/pull/62 README.md - avoid 404 links You can merge this pull request into a Git repository by running: $ git pull https://github.com/stain/commons-lang patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/62.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #62 commit 9ef9ada5862023566b83b55990205cdcbd9cb6b4 Author: Stian Soiland-Reyes st...@apache.org Date: 2015-04-08T23:55:14Z README.md - avoid 404 links --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
