StatDCAT-AP respects the conformance requirements defined for DCAT-AP version 1.1 (https://joinup.ec.europa.eu/release/dcat-ap-v11), which means that it will have, at least, the same mandatory classes and mandatory properties as DCAT-AP 1.1. StatDCAT-AP may extend DCAT-AP by specifying additional properties, as long as they are reused from existing RDF vocabularies.
During discussion with stakeholders, the following additional property was proposed:
‘Visualisation’ as a property for Dataset
This property is intended to provide a link to a page where the data can be seen in a graphical representation. The expected value for this property is a URL that opens the visualisation for this Dataset.
Participants in this activity are asked to respond to the following questions:
- Is the information for this property available in existing statistical systems and applications?
- How will exposing this information to general data portals enhance the discoverability of statistical datasets?
- Do you know of any property in existing RDF vocabularies that could hold this information?
Comments
The WG decided in the meeting of 13 May 2016 to further discuss the inclusion of a property that provides a link to a graphical or tabular representation of the dataset.
We are inviting the community to make suggestions for such a property, ideally from an existing RDF vocabulary.
Data visualisation is common in the geospatial domain, where this is dealt with by specific services ("view services"), which basically allow you to display a visualisation of a dataset as a layer on a map. Notably, view services can return layers in different formats - usually images (TIFF, JPEG, PNG), but some support JSON as well.
In GeoDCAT-AP we don't have a specific property for this. Rather, we use foaf:page to link a dataset to any related resource that it is not a distribution. Just to say that the solution adopted in StatDCAT-AP could be relevant to GeoDCAT-AP as well.
About the possible options, it may be worth considering how this is dealt with in the EU Open Data Portal, where data visualisation is modelled as documentation of type "visualisation". The OP's MDR has a code list exactly for this:
Yes, as far as I understand, we are talking scenario #2, but maybe the Publications Office can chime in here too.
My perspective on the two options is as follows:
a. foaf:page is a property that is already in DCAT-AP so it would not require a new property to be added for StatDCAT-AP. A point in its favour is that GeoDCAT-AP uses this approach. An argument against is that one could argue that the definition of foaf:page ("The page property relates a thing to a document about that thing") is a bit of a stretch for a visualisation; can a visualisation be considered a "document about a Dataset"? Furthermore, foaf:page is already used in DCAT-AP with the 'standard' semantics -- would duplicating the same property for a slightly different purpose create confusion?
b. foaf:depiction is a property not already in DCAT-AP so it is real extension. The point in its favour is that the definition is much closer to what a visualisation is: "The depiction property is a relationship between a thing and an Image that depicts it"; one could argue that a visualisation depicts a Dataset. An argument against it could be that it is not clear that the class foaf:Image includes things that are interactive.
From the perspective of simplicity, it appears that foaf:depiction is the simpler solution as Andrea's two RDF snippets show; in the foaf:depiction case, there is just one statement, for foaf:page there are two.
More opinions very welcome.
I think a visualization can be regarded as a document (after all, a foaf:Image is also a foaf:Document). Also, visualizations are not necessarily static, and quite often interactive, so foaf:Document would probably fit such a scenario better.
I do agree that foaf:depiction would be simpler, though.
I would suggest using foaf:page which is more permissive. For example, a publisher may want to just point to a webpage that includes one or more visualisations of a dataset. As Uros is also saying, foaf:Image is also a foaf:Document.
Hi,
The OP is currently reviewing the EU ODP data model in order to adapt it to the revised DCAT-AP.
Our idea is to have visualisations as a subclass of distribution and not documentation. We find visualisations semantically closer to distribution. Visualisations can often be exported in various formats and it's in fact just a different way of presenting the data while documentation is rather providing more information about the data, methodology, quality etc.
The creation of a subclass would allow us to add some properties that would discribe it: URI, access URL and Iframe for the embed codes.
The list of MDR codes (mentioned by Andrea https://joinup.ec.europa.eu/discussion/link-visualisation#comment-18317) that include visualisation reflect current ODP model and can be adapted accordingly.
Regards,
Agnieszka
Angieszka, the idea of modelling a visualisation as a Distribution is definitely an option. In this case, however, I would suggest not creating a subclass, but just using Distribution as is. The only thing that we won't be able to model in this case is the code for embedding, but I'm not sure if this is even a problem, or if this is enough motivation for defining a subclass.
I would like to point out that the range for foaf:depiction is foaf:Image. This means in principle that whatever foaf:depition points to is inferred to be a digital image (such as JPEG, PNG, GIF bitmaps, SVG diagrams etc.)
@Agnieszka, @Nikos,
I'm also supportive to the idea of modelling visualisations as distributions - and I like it more than using foaf:depiction or foaf:page. Notably, this would align with the approach currently under consideration in the "service-base data access" issue I mentioned in my earlier comment.
I agree with Nikos that we shouldn't define a subclass of dcat:Distribution for this. Rather, we can use dct:type - something like:
In other words, we can re-use the relevant documentation type code from the OP's MDR. Otherwise, since the OP's MDR already operates a code list for distribution types, this might be extended accordingly.
@Andrea,
The 'documentation-type' bit in that URI does seem a bit off putting, as documentation can/should be seen as metadata, rather than a distribution (unless we are talking about documentation distributions, of course).
As for the alternative, it appears that MDR's distribution types are merely an abstraction layer on top of IANA's MIME types, and dcat:mediaType is already a recommended property for dcat:Distribution. Do we need that layer?
@Uroš,
I agree that using a URI including "documentation-type" may be misleading - I just meant to provide an example by using an existing code list. The point is that, if we model data visualisation as distributions, we need to say somewhere what users will find.
About MDR's distribution types as generalisation of IANA MIME types, I'm not sure I agree. Agnieszka can correct me if I'm wrong, but they are meant to describe how a distribution gives you access to data. For instance, WEB_API can be used when data are behind an API, and its possible use was also discussed in Rome around the "service-based data access" issue. dct:format and dcat:mediaType are just meant to tell you which is the format of the data you finally get, and not to describe a data access protocol.
@Andrea,
Thanks for the clarification. I see your point with respect to the distribution types, and if that is actually the case, also why it's relevant for DCAT-AP in general. I'm currently leaning toward this solution (assuming the code list gets extended).
Proposed resolution: No extension necessary. Visualisation can be modelled as dcat:Distribution.
Statistical datasets may have associated visualisations. These include graphs, tables and interactive representations. As these can be considered distributions of the data, the proposal is to model a visualisation as dcat:Distribution with accessURL to link to the representation and dct:type of http://publications.europa.eu/resource/authority/documentation-type/VISUALIZATION. An alternative to the URI could be addition of ‘Visualisation’ to the MDR Distribution Type NAL.
The above propsoal needs to amended:
DCAT-AP does not currently include the property dct:type for Distribution. To support the proposal for the modelling of visualisations, the additional proposal is to add dct:type to Distribution.
This proposal was incorporated in Draft 4, section 6.2.3.