You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 18, 2024. It is now read-only.
This issue was originally discussed as part of #309 which was about defining the version of the schema being used. Since Project Open Data has relied on JSON Schema to define the schema in a machine readable way, it made sense to use URLs and resources associated with our JSON Schema definition to address this issue. While I think that is the simplest and most direct approach to specify the schema among those involved with Project Open Data, it's quite specific to our use and doesn't leverage existing definitions used by others - like those working with DCAT. Furthermore, it doesn't make it explicit that we are actually using the same properties and definitions used in DCAT. With JSON-LD, we can not only make it explicit that the schema is the JSON serialization of DCAT, but it should make interoperability with DCAT and associated vocabularies functionally possible rather than just notional.
In other words, it seems like there's value in both approaches, so I've broken this off as a separate issue from #309
Even while recognizing the long discussions about linked data that have occurred here as well as many ongoing discussions about the state of linked data in the broader community, it should be easy to address this in a straightforward manner. Because of the work that's already been done to align the schema with DCAT and the fact that JSON-LD requires a minimal amount of overhead with something modeled on established vocabularies, this is actually pretty trivial and shouldn't add much complexity to the existing schema and documentation.
That said, it is more to add. Since the additional fields to support JSON-LD can simply be appended to the existing schema and since we don't yet see a huge demand or critical need to support JSON-LD for current use cases, I don't think JSON-LD support should be a hard requirement as part of this revision to the schema. We can certainly still document all the necessary JSON-LD keywords here as optional fields and explain why they're useful. Tools provided by Data.gov can also automatically generate JSON-LD versions of the metadata which will guarantee that many agencies will be serving JSON-LD versions of the data.json file. Every six months we reassess these requirements, so if we see more interest and more value demonstrated by requiring JSON-LD we can consider it a strict requirement in the future. Please also note that Data.gov already aggregates all these data.json files and makes the metadata available using DCAT as RDF XML as well as Schema.org microdata.
There were already many comments provided in #309 to draft what was needed to make the schema work as JSON-LD and we can continue to revise those drafts here. I'll start with the last example provided by @philarcher1 as well as the more compact version of that. @amercader is also tracking this for more general CKAN implementations with ckan/ckanext-dcat#20
And then the more compact version where we put the body of @context in a .jsonld file hosted on the Project Open Data site. This is to demonstrate that all of @context can be condensed into a URL, but the use of the @type keywords would still be the same throughout each dataset
Thanks! All the JSON-LD keywords have been incorporated into the v1.1 branch and draft documentation, but I've indicated the contents of @context are still a draft. We can continue to work on refining it here
This issue was originally discussed as part of #309 which was about defining the version of the schema being used. Since Project Open Data has relied on JSON Schema to define the schema in a machine readable way, it made sense to use URLs and resources associated with our JSON Schema definition to address this issue. While I think that is the simplest and most direct approach to specify the schema among those involved with Project Open Data, it's quite specific to our use and doesn't leverage existing definitions used by others - like those working with DCAT. Furthermore, it doesn't make it explicit that we are actually using the same properties and definitions used in DCAT. With JSON-LD, we can not only make it explicit that the schema is the JSON serialization of DCAT, but it should make interoperability with DCAT and associated vocabularies functionally possible rather than just notional.
In other words, it seems like there's value in both approaches, so I've broken this off as a separate issue from #309
Even while recognizing the long discussions about linked data that have occurred here as well as many ongoing discussions about the state of linked data in the broader community, it should be easy to address this in a straightforward manner. Because of the work that's already been done to align the schema with DCAT and the fact that JSON-LD requires a minimal amount of overhead with something modeled on established vocabularies, this is actually pretty trivial and shouldn't add much complexity to the existing schema and documentation.
That said, it is more to add. Since the additional fields to support JSON-LD can simply be appended to the existing schema and since we don't yet see a huge demand or critical need to support JSON-LD for current use cases, I don't think JSON-LD support should be a hard requirement as part of this revision to the schema. We can certainly still document all the necessary JSON-LD keywords here as optional fields and explain why they're useful. Tools provided by Data.gov can also automatically generate JSON-LD versions of the metadata which will guarantee that many agencies will be serving JSON-LD versions of the data.json file. Every six months we reassess these requirements, so if we see more interest and more value demonstrated by requiring JSON-LD we can consider it a strict requirement in the future. Please also note that Data.gov already aggregates all these data.json files and makes the metadata available using DCAT as RDF XML as well as Schema.org microdata.
There were already many comments provided in #309 to draft what was needed to make the schema work as JSON-LD and we can continue to revise those drafts here. I'll start with the last example provided by @philarcher1 as well as the more compact version of that. @amercader is also tracking this for more general CKAN implementations with ckan/ckanext-dcat#20
From @philarcher1
And then the more compact version where we put the body of
@context
in a .jsonld file hosted on the Project Open Data site. This is to demonstrate that all of@context
can be condensed into a URL, but the use of the@type
keywords would still be the same throughout eachdataset
The text was updated successfully, but these errors were encountered: