Re: 2nd draft of DCAT

Dear Yves,

As agreed, I'm cc'ing the DXWG mailing list, as the points you raise are very much relevant to the use of one of the new properties defined in the revised version of DCAT.

I include below my reply to your questions, but other WG members may complement / correct my response:

Property dcat:endpointDescription is meant to have as object the (possibly machine-actionable) description of the relevant service / API. The reference to the service / API description can be done by specifying its URI, or by including it "inline" (typically, as a set of RDF statements). The latter option matches your case, as far as I can see.

One thing that it may be worth adding to your example is the service / API URL, by using property dcat:endpointURL - this, despite whether this URL is or not already  included in the service description. Example 49 in the DCAT specification illustrates how this property can be used together with dcat:endpointDescription:

https://w3c.github.io/dxwg/dcat/#ex-service-eea

Cheers,

Andrea

----
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/

----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.


________________________________________
From: Yves Coene <Yves.Coene@spacebel.be>
Sent: 22 May 2019 11:17
To: PEREGO Andrea (JRC-ISPRA)
Cc: Christophe Noel
Subject: RE: 2nd draft of DCAT

Dear Andrea,

I'm sorry for the late reply.  We only started our work for ESA (OGC Testbed-15 EOPAD) recently and I'm working an two documents OGC 17-084 (Collection Metadata) and OGC 19-020 (OGC Testbed-15 Catalogue and Discovery Engineering Report) which I try to align to the maximum extent with DCAT, GeoDCAT-AP....

We are using (Geo)JSON and JSON-LD representations (linked through a normative @context document) and ESA has a preference for using OGC OWS Context OGC14-055r2 iwhich you can find at https://docs.opengeospatial.org/is/14-055r2/14-055r2.html in the (Geo)JSON representation:

I have a question related to the use of the new property "dcat:endpointDescription".  I'm considering using it in the following way.  Could you comment on that ?  All examples I have seen about its use are with URL to remote files, but I have not seen an "embedded" example, which may be useful for discovery in a catalog.

{
        "@context": {
                "owc": "http://www.opengis.net/ont/owc/1.0/",
                "dcat": "http://www.w3.org/ns/dcat#"
        },
        "@type": "dcat:DataService",
        "dcat:endpointDescription": {
                "@type": "owc:Offering",
                "@id": "http://www.spacebel.be/offering/0001",
                "owc:code": "http://www.opengis.net/spec/eopad-geojson/1.0/req/docker/image",
                "owc:contents": [
                        {
                                "owc:type": "text/plain",
                                "owc:content": "xxx/yyy/ZZZ:latest"
                        }
                ]
        }
}


Is this a valid approach to embed any OGC "Offering" object in this way in a DCAT description using the dcat:endpointDescription property?

I also am considering embedding a WPS DescribeProcess response (of the RESTful WPS with JSON response) in this way...

{
        "@context": {
                "owc": "http://www.opengis.net/ont/owc/1.0/",
                                "wps":"http://www.opengis.net/wps/2.0",
                "dcat": "http://www.w3.org/ns/dcat#"
        },
        "@type": "dcat:DataService",
        "dcat:endpointDescription": {
                "@type": "wps:ProcessOffering",
                "@id": "http://fedeo.esa.int/services/NdviCalculation",
                ...
        }
}

The intention is to define a GeoJSON encoding which maps as well as possible to DCAT when a normative @context is applied.  The "dcat:endPointDescription" seems a good candidate to use instead of the OGC specific owc:offerings property defined in OGC 14-055r2.  Your feedback would be very much appreciated.

Thanks in advance.

Regards,

Yves.

[snip]

Received on Thursday, 23 May 2019 13:36:37 UTC