9

We have open data as a CSV file, about 200k lines, columns are mostly text.

In order to make it into Linked Data and be easily reusable by as many mashups/apps/etc as possible, we want to propose another format, not CSV.

I have found the following:

  • RDFa
  • RDF/XML
  • N3
  • Turtle
  • JSON-LD
  • I am sure there are many others

I guess the difficulty for generating is pretty similar for each of these (just a text template to fill), so the big question is:

Which of these formats makes most users happy, and will bring us the most re-users?

I don't care much about what easiest for us. I care 100% about what is the easiest for re-users. It is extremely important that the format can be read by almost all libraries/triplestores.

Improve this question

6 Answers 6

Reset to default
9

In addition to @enridaga's great answer, let me offer a few additional thoughts.

RDFa is (only) useful if you already have HTML content that you want to enrich with semantic data.

RDF/XML is very well readable for machines, but not so much for humans.

N-Triples, Turtle or N3 are currently pretty much the default formats for Linked Data dumps. For example, have a look at the recently released official Wikidata RDF exports. N-Triples are preferable for large files because they can be easily processed line by line.

JSON-LD is the new kid on the block with lots of potential and already some uptake. Its biggest advantage: Even programmers that have never heard of the Semantic Web can use it immediately.

As @enridaga mentioned, once you have your data in one of these formats, it can be converted automatically to any of the other formats. You can give it a quick try with the online RDF Translator.

If you only want to provide a simple dump of your data for the Semantic Web crowd, go with (gzipped) N-Triples. If your users prefer a different format, they can easily convert it themselves.

If you also want your data to be instantly accessible to regular programmers, make it JSON-LD.

Improve this answer
8

So you have a CSV file and you want to publish it as linked data in a RDF format, not CSV. The core part of the work here is the translation to RDF, that implies, as @andrew-opengeocode suggested in his answer, that you find one or more RDF ontologies/vocabularies that define terms you can reuse to model your data. The more popular are the terms you reuse, the more easy will be for developers to make sense of your data. You can search for popular terms at http://lov.okfn.org/dataset/lov/.

Once you have your data in RDF, you can use existing libraries to get the different serializations. The serialization format will be for-free if you use existing libraries (ARC2 in PHP, Apache Jena in Java, just to mention a couple of...).

If you do not want to maintain a triple store but you only want to publish single documents for each dereferencable URI, I still suggest you to offer at least the following formats, supporting content-negotiation:

  • RDF/XML: it's a classic, and legacy tools might assume it
  • Turtle: this is the most human readable syntax
  • JSON-LD: the new mood, you would be oldish if you don't have it
  • N-Triples: large data can be easily buffered cropping the file at any line without break consistency.

Hope this helps.

Improve this answer
4
  • Thanks for the first paragraph, my questions is about the next step though. We don't have a triplestore or much software at all, just an FTP server where we upload files. We would rather not have too many files, so I was thinking CSV+RDF/XML for instance. Is it important to also generate the other formats like JSON-LD? That would mean more disk space, upload time, and maintenance...
    – Nicolas Raoul ♦
    Commented Sep 17, 2014 at 8:38
  • If I was you, I won't materialize all files and syntaxes. I would do a single RDF version in N-Triple (very handy to buffer triples line by line...) stored aside your CSV. Then I would let a script (with PHP should not be hard) handle the content negotiation and make the syntactic translation on the fly. Being the input N-Triples you could read a bunch of triples, translate them, spit them out and go ahead until you have finished. It should be efficient.
    – enridaga
    Commented Sep 17, 2014 at 11:26
  • It is just a basic file server, no PHP. So if you had to choose only one you would choose N-Triple right?
    – Nicolas Raoul ♦
    Commented Sep 17, 2014 at 11:43
  • Personally yes, especially if they might be large. You can also provide the compressed versions, as also @patrick-hoefler suggested, wisely.
    – enridaga
    Commented Sep 17, 2014 at 11:52
5

Here's my 2 cents. Since your data is already in CSV format, the fastest way to add semantic context is to use ODI's 'Linked CSV' format: (http://jenit.github.io/linked-csv/).

You will need to pick a vocabulary. Without knowing about your data, I would start by looking at existing [semi]standardized data vocabularies. For example, a large number of datasets and corresponding vocabularies have been published in the Link Open Data (LOD) project: http://linkeddata.org/

I am a co-founder of OpenGeoCode.Org. We too have a published vocabulary for linked data (no surprise - haha). You can find it at: http://www.opengeocode.org/cude1.1/LinkedCSV-Vocab.php

Improve this answer
1
  • 1
    I don't care much about what easiest for me. I care 100% about what is the easiest for re-users. I suspect not many libraries/triplestores can read from Linked CSV.
    – Nicolas Raoul ♦
    Commented Sep 17, 2014 at 7:13
5

In order to make it into Linked Data and be easily reusable by as many mashups/apps/etc as possible..

It seems you are talking about RDF dumps, but there are other ways to provide access to RDF data, at least the following:

  • SPARQL endpoint,
  • URI dereferencing.

These ways are more convenient for the goals you are trying to achieve.

We have open data as a CSV file, about 200k lines, columns are mostly text.

I hope all these strings are implicit things. You should make them explicit. Otherwise, it doesn't make much sense to "convert" your data to RDF.

It is extremely important that the format can be read by almost all libraries/triplestores.

Now, after 3 years, there is no problem with tool support. Anyway, it is possible to convert RDF from one serialization format to another using well known tools (e.g. Jena RIOT) or even online converters. The main criteria should be human readability.

UPDATE

As for related standard recommendations:

A note about JSON-LD

I'm a JSON-LD hater for two reasons:

  • JSON-LD is based on JSON approximately in the same way that RDF/XML is based on XML.
    It is impossible to work with JSON-LD using dot as bracket notation — as well as it is impossible to work with RDF/XML having XML parser only. RDF/JSON was much better in that sense.

  • The JSON-LD authors said that the RDF data model is overcomplicates, but now they produce things like this:

    If the expanded term definition contains the @container keyword, its value MUST be either @list, @set, @language, @index, @id, @graph, @type, or be null or an array containing exactly any one of those keywords, or a combination of @set and any of @index, @id, @graph, @type, @language in any order. @container may also be an array containing @graph along with either @id or @index and also optionally including @set.

A note about RDF HDT

RDF HDT looks really interesting.

HDT (Header, Dictionary, Triples) is a compact data structure and binary serialization format for RDF that keeps big datasets compressed to save space while maintaining search and browse operations without prior decompression. This makes it an ideal format for storing and sharing RDF datasets on the Web.

One of the authors is Claudio Gutierrez. There exists a GUI tool, see demo on YouTube.

From A More Decentralized Vision for Linked Data:

… a ”fifth Linked Data principle”:

  1. Publish your dataset as an HDT dump, including VoID metadata as part of its header and declaring (i) the (authoritatively) owned namespaces, (ii) links to previous and most current versions of the dataset, (iii) and – whenever you use namespaces owned by other datasets or ontologies – the links to specific versions of these other datasets.
Improve this answer
2
  • What do you mean with implicit/explicit? If you have a link to a page explaining these terms that would be great thanks :-)
    – Nicolas Raoul ♦
    Commented Apr 10, 2018 at 12:00
  • 1
    I mean, If these strings are natural keys, you should use respective URIs instead. E. g. :row-wikivoyage-10 :column-wikivoyage-type :type-buy . :type-buy rdfs:label "buy" instead of :row-wikivoyage-10 :column-wikivoyage-type "buy". BTW, I don't know how to easily model in RDF things like "€ 2.05 for one pastry" etc. Perhaps you don't need to model them in RDF -- as well as RDF itself.
    – Stanislav Kralin
    Commented Apr 10, 2018 at 12:44
5

First off, you can use CSV as a Linked Open Data (LOD) serialization format. This has been the case since 2009 (early days of LOD cloud, demonstrated via DBpedia; just look in the footer of DBpedia's entity description pages). There's even a Linked CSV draft spec in regard to this matter (there are even CSV Browsers). The only downside is that existing LOD consumer apps/services expect N-Triples, Turtle, JSON-LD (of late), or RDF/XML etc.

If you seek a productivity tool based approach for quickly converting CSV to Linked Open Data, consumable by a majority of existing consumer apps and services, you should consider using a tool like OpenRefine or the LOD Refine derivative to achieve this goal. In either case, you will have the ability to leverage existing vocabularies and ontologies when mapping CSV records to actual entities (class instances), entity types (classes), and relationship types (properties associated with a Property Domain (class) and expected values or objects ranges [class instances or typed literals].

If you want to achieve this goal by hand, you should consider the following, in order of ascending complexity:

  1. N-Triples
  2. Turtle (N-Triples plus a few shorthand tricks for statement brevity)
  3. JSON-LD (if you are a Web Programmer conversant with Javascript and conversant with Entity-Attribute-Value based data representation)
  4. RDF/XML (if you are a Web Programmer conversant with XML and RDF Language Semantics).

Hope this helps.

Improve this answer
2

I would suggest just uploading it to https://data.world (disclaimer: I work there, but it's free). It's easy for other users to get it in a few different ways (whether it's a download, API, or a SPARQL endpoint) without you having to do a thing. This should give re-users ultimate flexibility without you having to do anything but drag-and-drop.

If you have any questions feel free to hit me @scuttlemonkey at https://slack.data.world or https://forum.data.world. Hope that helps!

Even if the data is uploaded as a CSV file, a SPARQL endpoint seems to be created automatically for you, which sounds very convenient:

enter image description here

Improve this answer
1
  • Cool! I added my experience, feel free to edit again of course.
    – Nicolas Raoul ♦
    Commented Apr 9, 2018 at 8:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.