W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > July 2020

Re: [dxwg] Question: how to catalog relational database data in DCAT? (#1240)

From: Andrea Perego via GitHub <sysbot+gh@w3.org>
Date: Fri, 03 Jul 2020 22:37:08 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-653689970-1593815827-sysbot+gh@w3.org>
@zeginis , @dominik-s0 , I would recommend against the use of `dct:identifier` for this purpose. As @dr-shorthair noted, it can work if you are going to have a `dcat:DataService` per table. However, one could argue that the table is the data available via the service, not the service itself (which is what `dct:identifier` is meant to be about), and this may lead to misunderstanding. To avoid any ambiguity, you'd better define a specific property for this - e.g., `ex:tableName` - whose value could be used, e.g., in an SQL query "template".

About whether to use `dcat:endpointURL` or `dcat:endpointDescription` for the connection string / DSN, the latter looks more fit, based on its purpose. But, again, you should consider defining a specific extension, as discussed in https://github.com/w3c/dxwg/issues/1240#issuecomment-653265382. I understand that this may hinder interoperability, especially if you expect to have your dataset records harvested by other catalogues. However, in that case,  your `dcat:endpointURL` / `dcat:endpointDescription` is not going to be actionable, unless is used in a specific environment with a given configuration (e.g., an environment where a client triggers a JDBC connection when a JDBC connection string is detected).

@zeginis , just a caveat about your example in https://github.com/w3c/dxwg/issues/1240#issuecomment-653395645: `dcat:endpointURL` and `dcat:endpointDescription` are both object properties, so they are not taking a literal as value.

-- 
GitHub Notification of comment by andrea-perego
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1240#issuecomment-653689970 using your GitHub account
Received on Friday, 3 July 2020 22:37:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 3 July 2020 22:37:12 UTC