> Martynas Jusevičius [[log in to unmask]]
> RDF has
> some properties that turn out to be extremely helpful for data
> de-siloification and integration on a global scale.

I take your point that RDF has some unique properties as far as merging data from different sources together.

I guess I have doubts that this is a universally desirable thing, maybe this is not the primary use case of all the bibliographic universe.

> If you say you get
> JSON-LD, you should be able to get RDF, because that is just one of
> its serializations.

As I understand JSON-LD, it is more than simply a serialization of RDF.  It makes palatable my fundamental distaste of RDF in as much as it supports multiple framings of the directed graph, with frames that look much more like record documents rather than a series of triples.

It is as if the triples are the 5th normal form, but JSON-LD also supports de-normalized serialization.

http://json-ld.org/playground/index.html if you look here and compare the Compacted and the N-Quads you can see what I mean.

I think I basically get RDF, I've run SPARQL servers and written SPARQL queries.  If I look and the N-Quad or Normalized view I can't tell what is going on by looking at the serialization with my eyes, whereas some of the JSON-LD Frames, it seems like I can actually read and understand the record from the serialization.

My guess is that I might not be the only one who glazes over at triples, but can read some of the other JSON-LD frames.

As far as graphs, I find Tinkerpop's property graph model makes more sense to me than RDF.  It lets you put as many key value pairs as you want onto any edge or vertex of the graph.  When you load RDF into tinkerpop, the graph is all edges with no vertices and no properties.

There is a growing sense in the community that since BIBFRAME is RDF, and it is replacing MARC, then everything must be moved to RDF, and if we just move everything to RDF wonderful things will be enabled.  I think that RDF may be being oversold, and I don't think it is a magic bullet that will solve all problems.  "Go RDF triplestore or go home" is not a message of technotolerance -- but that is message I'm getting from various directions.  Yet, when I watched the NISO BIBFRAME webinar last week, it looked like things are still pretty early days with lots of experimentation and competing versions of vocabularies.

I know how to do websites with django/solr/XTF.  I know I can produce that.  Why do I need throw out what I've done to re-do it on the linked data platform, just because the cool kids are?  I'm not telling anybody they are doing it wrong for not using django.  People are telling me I'm doing it wrong because I'm not storing triples.  If it can be turned into triples, why do I need to store it as triples?

My experience is that people resist change to established workflows.  I propose that a "replacement for MARC" should support some transitional format that can easily drop in to traditional workflows.  The MARC workflows I've had experience with have involved receiving batches of records for indexing (or, once upon a time I created a batch of all valid library users in MARC patron records every quarter by doing an SQL query to the campus datawarehouse.)  I just can't picture a small or large public library sending me RDF dumps or providing me access to a SPARQL endpoint any time soon.  I also want granularity at the record level for indexing, not the triple level.

My experience is that sometimes people have to bust out into MARCedit and fix a MARC file "by hand".  YAML-LD with a cataloging IDE type editor (or even a simple text editor) might support this use case maybe, and be able to map back into RDF triples for interop use cases.

One day down the road, when there is a global SPARQL endpoint where I can just do EXPLAIN queries and get back all the metadata I want on a resource (and then re-frame it into something I can read with JSON-LD) it will be pretty cool, but this seems like maybe a 20 year project to me.

Have a nice day and link away.

-- Brian