Accept 'RDF' module that uses RDF4J?

[The-Alchemist]

We're thinking of writing a jackson-dataformats-rdf that uses http://rdf4j.org, akin to jackson-dataformat-yaml which uses SnakeYAML.

What are the odds that it would be accepted? (If not, that's OK, instead of forking jackson-dataformats-text we'll just create our own repo.)

Thanks!

[cowtowncoder]

In general I am always happy to see inter-operability support via new format modules.
From practical standpoint it may make sense to first create stand-alone repo, see how things work out, and then possibly merge them (for example, XML module is still separate one).

So I think it might be good idea to create separate one first, just to make sure everything goes smoothly and then I can help get it merged when time comes.
There are also related questions of how to manage things; I am happy to give write access to things you write (sort of goes without saying :) ), but github access controls are not very general within repo.

As to RDF, I assume this is the mature XML thing from late -90s?
If so, I'd be curious to know how well that fits in as dataformat module, compared to maybe datatype module? (which exist for things like JSON object model of org.json package)

[The-Alchemist]

Thank you for the quick reply, @cowtowncoder .

Nowadays, RDF/XML isn't very popular. I'm thinking more of the Turtle format.

<http://example.org/person/Mark_Twain>
    <http://example.org/relation/author>
    <http://example.org/books/Huckleberry_Finn> .

Or JSON-LD, which also falls under the umbrella of RDF:

{
  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/workplaceHomepage",
      "@type": "@id"
    },
    "Person": "http://xmlns.com/foaf/0.1/Person"
  },
  "@id": "http://me.example.com",
  "@type": "Person",
  "name": "John Smith",
  "homepage": "http://www.example.com/"
}

Full list of formats that RDF4J supports is here.

I'm actually not familiar with the difference between the datatype and dataformat modules. If it helps, RDF4J doesn't have a streaming/incremental parsing/writing API.

Perhaps it's worth pointing our the RDFBeans project, which we're basically hoping to "port" to Jackson, if possible.

[cowtowncoder]

Ah. Yes, makes sense, there isn't much need/benefit for XML as the underlying format.

As to separation of format modules vs datatypes:

• dataformat for something exposed via Streaming API (parser, generator), which can then use standard databinding (and possibly Tree Model, if similar enough to JSON logical model). This works well for a large number of different encodings (Avro, BSON, CBOR, CSV, MsgPack, Properties, Protobuf, Smile, XML, YAML)
• datatype for 3rd party datatype libraries (like Joda, Guava etc) as well as some of format-specific models (org.json, JSON-P). It builds on core streaming and databinding, extending latter but using abstractions (parser, generator) from former.
  • datatype libraries, like databinding, is format-agnostic and should work without knowing details of format

On the other hand, if Jackson is simply used as low-level parser/generator, there may not be need/benefit in trying to make a library fit these approaches. There are many projects that do this for JSON processing at least.

Brief look at RDFBeans suggests that dataformat probably will not match very well, as annotation processing (for example) is databinding-level functionality.
But then a related question is whether there is need to support multiple formats (encodings) with their idiosyncracies. Jackson sort of assumes that this is not done, that is, higher level functionality (like datatypes) does not try to (or need to) customize lower level aspects. I suspect this might be problematic with RDF.

So... I don't know. If there is a canonical set of objects ("Object Model") that can represent logical RDF graphs regardless of encoding it would seem like a fit for datatype module. If aspects are intertwined then Jackson abstractions are probably not a good fit.

[cowtowncoder]

One other note: looking at Turtle, TriG, those would almost make sense as format modules, except that they may try to add semantics that muddle line between general-purpose format and DSL. So question is whether they would map clearly to JSON-influenced token-stream model.

If they do, the next question would be whether there is benefit there; if mapping to token streams is clean enough perhaps higher level abstractions could and would work nicely.

Not sure if my thinking out loud here helps. :)

[The-Alchemist]

Thanks, @cowtowncoder . Your thinking out loud was super helpful. I realize now that I was kind of headed in the wrong direction, as I'm not trying to rewrite RDF4J. I was just hoping to take advantage of the bean binding facilities provided by Jackson to allow usage of Jackson's standard annotations.