- From: Phil Archer <phila@w3.org>
- Date: Thu, 27 Sep 2012 17:59:49 +0100
- To: Richard Cyganiak <richard@cyganiak.de>
- CC: Public GLD WG <public-gld-wg@w3.org>
On 27/09/2012 17:29, Richard Cyganiak wrote: > Phil, > > The first thing that needs to be said is: What kind of artefacts can conform to this specifications? > > For example, for the HTML specification, there can be conforming HTML documents, and conforming web browsers, and perhaps further kinds of software artefacts or documents. > > In the case of DCAT, we're really interested in two kinds of artefacts. One is data catalogs. The other is harvesting protocols based on DCAT, such as the one that OKFN wants to have. So I guess I'd propose something along these lines: > > [[ > A data catalog conforms to DCAT if: You're defining a class of application, which I don't think we should do in a vocabulary. The vocab should stand on its own. It is only an application that imposes constraints. If someone wants to use DCAT in something other than a data catalogue, weird though that may seem, why stop them? > > * It is organized into [[datasets]] and [[distributions]]. That is implied by the domains and ranges of the properties, but if an application says "all we want to dcat:keyword" - well, that's OK, no? > > * An [[RDF description]] of the catalog itself and its datasets and distributions is available (but the choice of > RDF syntaxes, access protocols, and access policies is not mandated by this specification). > > * The contents of all metadata fields that are held in the catalog, and that contain data about the catalog itself and its dataset and distributions, are included in this RDF description, expressed using the appropriate classes and properties from DCAT, except where no such class or property exists. We're getting closer. > > * All classes and properties defined in DCAT are used in a way consistent with the semantics declared in this specification. Yes, that's what Dave added and it's right. > > DCAT-compliant catalogs MAY include additional non-DCAT metadata fields and additional RDF data in the catalog's RDF description. That's the open world of RDF - does it need saying? > > A *DCAT profile* is a specification for data catalogs that adds additional constraints to DCAT. A data catalog that conforms to the profile also conforms to DCAT. Additional constraints in a profile MAY include: > > * A minimum set of required metadata fields > * Classes and properties for additional metadata fields not covered in DCAT > * Controlled vocabularies or URI sets as acceptable values for properties > * Requirements for specific access mechanisms (RDF syntaxes, protocols) to the catalog's RDF description > ]] That's covered, I think, in the application-specific bit of what I proposed. > > > On 27 Sep 2012, at 14:54, Phil Archer wrote: > >> Following my action item to "Tidy up the conformance language, preferably with bullet points", I suggest the following be included as the conformance statement for our vocabularies. >> >> ===Begins=== >> >> Conformance to this vocabulary means: >> - *using* its classes, properties and relationships; >> - *using* as many of the terms as possible, but not >> necessarily using every term; >> - *not using* terms from other vocabularies instead of ones defined >> in this vocabulary that could reasonably be used. >> >> Applications MAY: >> >> - specify a minimum set of terms that publishers must use if their >> data is to be processed by the application; >> - specify controlled vocabularies as acceptable values for >> properties. >> >> This specification treats such restrictions as application-specific. >> >> ===Ends=== >> >> My suggestion is that, modulo edits and improvements made by the WG, common wording is used on all GLD vocabularies. >> >> N.B. Re-spec includes the usual boiler plate text about RFC2119 keywords. i.e. >> >> "As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. >> >> The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [RFC2119]." >> >> Do we want to include this in a vocab? Probably, but we shouldn't be a slave to re-spec. >> >> >> -- >> >> >> Phil Archer >> W3C eGovernment >> http://www.w3.org/egov/ >> >> http://philarcher.org >> +44 (0)7887 767755 >> @philarcher1 >> > > > -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Received on Thursday, 27 September 2012 17:00:30 UTC