DCAT JSON structure

[mhogeweg]

I've been looking at implementing DCAT support in Geoportal Server (https://github.com/Esri/geoportal-server) and have a question on the expected JSON structure.

the examples+templates for DCAT JSON suggest the following structure:

{ [ catalog info, catalog item 1, catalog item 2, … ] }

all in 1 json array.

this structure seems to be what is intended (by looking at the RDF and W3C specs for DCAT):

{ catalog info, [catalog item 1, catalog item 2, ...] }

Subtle but important difference. Can someone clarify?

also, the array appears to be an unnamed JSON object. I'd suggest to assign a name to further clarify the role of different JSON elements.

{
"info" : {catalog info here},
"items" : [catalog items here]
}

this follows typical approaches in ATOM/RSS formats.

[rufuspollock]

I note http://spec.datacatalogs.org/ has a suggested serialization of DCAT.

[mhogeweg]

thanks for providing that link. what I'm not finding in the DCIP spec is the serialization of the dcat:Catalog class itself (what I labeled above as the 'info' entry). the DCAT working draft doc at W3C (https://dvcs.w3.org/hg/gld/raw-file/default/dcat/index.html) does include an example of this in n3.

[jpmckinney]

Couldn't you use JSON-LD to serialize DCAT (and any other RDF ontology) as JSON? Here is the JSON-LD of the DCAT RDF example:

// A catalog
{
  "@context": "http://an-appropriate-json-file-defining-the-properties-below.tld",
  "@id": "http://example.org/catalogs/1.json",
  "@type": "http://www.w3.org/ns/dcat#Catalog",
  "title": "Imaginary Catalog",
  "label": "Imaginary Catalog",
  "homepage": "http://example.org/catalog",
  "publisher": "http://example.org/publishers/1.json",
  "language": "http://id.loc.gov/vocabulary/iso639-1/en",
  "dataset": ["http://example.org/datasets/1.json", "http://example.org/datasets/2.json"]
}

// A publisher
{
  "@context": "http://an-appropriate-json-file-defining-the-properties-below.tld",
  "@id": "http://example.org/publishers/1.json",
  "@type": "http://xmlns.com/foaf/0.1/Organization",
  "label": "Transparency Office"
}

// A dataset
{
  "@context": "http://an-appropriate-json-file-defining-the-properties-below.tld",
  "@id": "http://example.org/datasets/1.json",
  "@type": "http://www.w3.org/ns/dcat#Dataset",
  "title": "Imaginary dataset",
  "keyword": ["accountability", "transparency", "payments"],
  "issued": "2011-12-05",
  "modified": "2011-12-05",
  "publisher": "http://example.org/publishers/2.json",
  "language": "http://id.loc.gov/vocabulary/iso639-1/en",
  "distribution": "http://example.org/distributions/1.json"
}

// A distribution
{
  "@context": "http://an-appropriate-json-file-defining-the-properties-below.tld",
  "@id": "http://example.org/distributions/1.json",
  "@type": "http://www.w3.org/ns/dcat#Distribution",
  "downloadURL": "http://www.example.org/files/001.csv",
  "title": "CSV distribution of imaginary dataset 001",
  "mediaType": "text/csv",
  "byteSize": "5120"
}

I appreciate that datacatalogs.org may be older than JSON-LD, but let's please use what's most likely to become the standard (and generic) way of representing linked data in JSON.

[jpmckinney]

Hopefully the above serves as a good example of how easy it is to turn semantically meaningless JSON into Linked Data, with just the addition of three properties (@context, @id and @type). FYI, the @context document will just need to be defined once per class (Catalog, Publisher, Dataset, Distribution), not once per instance/document, so very little overhead in creating that file.

[mhogeweg]

+1 seems to fit very nicely in the semantic web objectives at Data.gov.

[jpmckinney]

Going back to the OP's question, I think adding @type fields to mark some items as catalogs and others as datasets or distributions is a better, standards-compliant approach than adding info and items fields.

[akuckartz]

By using an appropriate context

"publisher": "http://example.org/publishers/2.json",
"language": "http://id.loc.gov/vocabulary/iso639-1/en"

can be simplified to something like

"publisher": "pub:2.json",
"language": "lang:en"

The first one could be improved if "http://example.org/publishers/" offers content negotiation:

"publisher": "pub:2"

(Content negotiation could then result in "http://example.org/publishers/2.rdf" ;-)

"language" can also be improved further. See http://json-ld.org/spec/latest/json-ld/#string-internationalization for details.

[gbinal]

Thanks for fleshing this question out. In the Implementation Guide, agencies are directed to include the data.json catalog file itself as an entry in the data.json file. Though it is a deviation from DCAT, it is hoped to help keep agency implementation as straightforward as possible.