W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > March 2019

Re: [dxwg] Rename Resource Descriptor class (#573)

From: Stephen Richard via GitHub <sysbot+gh@w3.org>
Date: Thu, 21 Mar 2019 17:42:11 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-475333057-1553190130-sysbot+gh@w3.org>
What I was thinking is that the prof:hasArtifact/dcat:Distribution is about the specific representation (as a resource, or rdf-triple-object) of a resource describing the profile in some role (what prof:ResourceDescriptor does). The dcat:accessURL is the location where that representation can be 'GET'ed on the web.  The dcat:Distribution value for the prof:hasArtifact can be a blank node (as in the example I posted); it could be assigned an identifier if that is useful. 
I think a possible source of confusion here is that the current approach links from a profile, which I view as a resource (FRBR work), to related resource (resourceDescription) representations (hasArtifact) directly, instead of linking the profile resource to a description resource, recognizing that both of these might have one or more representations (realized as dcat:Distributions, which are resources of a different type, that conform to some specification and have some representation format). I'm fully aware of the issue that different representations of a resource can be accessed at different distribution:accessURL, or via content negotiation.  It is a profile WG issue about how to communicate the content negotiation (http accept header syntax) options in the metadata, saving clients from feeling around with HEAD requests and guessing what the response means. Using different distribution:accessURL can avoid the problem by using dct:conformsTo and dct:format for each distribution.

-- 
GitHub Notification of comment by smrgeoinfo
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/573#issuecomment-475333057 using your GitHub account
Received on Thursday, 21 March 2019 17:42:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:15 UTC