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.
+ * <p>
+ * An RDF syntax is uniquely identified by its {@link #mediaType()}, and
has a
+ * suggested {@link #fileExtension()}.
+ * <p>
+ * Some of the RDF syntaxes may {@link #supportsDataset()}, meaning they
can
+ * represent {@link Quad}s.
+ * <p>
+ * 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. <code>RDFSyntax.JSONLD</code>.
+ *
+ */
+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.
+ * <p>
+ * The name typically corresponds to the {@link Enum#name()} of for
+ * {@link OfficialRDFSyntax}, e.g. <code>JSONLD</code>.
+ *
+ * @return Short name for RDF syntax
+ */
+ public String name();
+
+ /**
+ * The title of the RDF Syntax.
+ * <p>
+ * This is generally the title of the corresponding standard,
+ * e.g. <em>RDF 1.1 Turtle</em>.
+ *
+ * @return Title of RDF Syntax
+ */
+ public String title();
+
+ /**
+ * The <a href="https://tools.ietf.org/html/rfc2046";>IANA media
type</a> for
+ * the RDF syntax.
+ * <p>
+ * The media type can be used as part of <code>Content-Type</code> and
+ * <code>Accept</code> for <em>content negotiation</em> in the
+ * <a href="https://tools.ietf.org/html/rfc7231#section-3.1.1.1";>HTTP
+ * protocol</a>.
+ */
+ 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. <code>Accept</code> 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 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
