Skip to content
This repository has been archived by the owner on Jun 18, 2024. It is now read-only.

DCAT JSON structure #23

Closed
mhogeweg opened this issue May 11, 2013 · 8 comments
Closed

DCAT JSON structure #23

mhogeweg opened this issue May 11, 2013 · 8 comments

Comments

@mhogeweg
Copy link
Contributor

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
Copy link

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

@mhogeweg
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

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

@jpmckinney
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

gbinal commented Aug 9, 2013

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants