- From: Andrea Perego via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Jul 2020 22:37:08 +0000
- To: public-dxwg-wg@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