- From: Rob Atkinson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 May 2018 05:04:35 +0000
- To: public-dxwg-wg@w3.org
+1 a profile just needs a URI it only needs to be dereferenceable if there is a need to understand it, or some aspects of it, for example to perform validation, form generation or conformance with more general profiles. (If we write a piece of software which hard-codes all the assumptions and only needs to recognise the profile, then it isnt necessary to dereference, and the software writer can possibly use a text description). I dont think we should care about this trivial case in the guidance, but it does apply to negotiation. The key thing to remember is that profiledesc is explicitly motivated as a means to meet the requirements of profile guidance that cannot be easily satisfied by any other identified vocabulary. So - there are a few choices 1) dont attempt to satisfy these requirements 2) publish profiledesc as a Rec in the "cleanest" form (standalone) if the W3C process allows this 3) publish profiledesc as a Note and point to it from the GuidanceDoc with a SHOULD and a clause that a Rec that superseded this SHOULD be used if available. 4) treat profiledesc as a normative part of the Guidance Doc 5) align ProfileDesc as a module of DCAT defining a subclass of dcat:Resource under the Rec process 2) is the best given the scope, but revisiting 5 may be the easiest and most appropriate from a process perspective. The cases I have seen where we can implement profiledesc will be able implement DCAT profiles anyway, so we end up with profiles as intrinsically catalogued resources, which is not incompatible with the need to have stable URIs for these things. -- GitHub Notification of comment by rob-metalinkage Please view or discuss this issue at https://github.com/w3c/dxwg/issues/242#issuecomment-392419955 using your GitHub account
Received on Monday, 28 May 2018 05:04:38 UTC