- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Thu, 27 Sep 2012 18:11:41 +0100
- To: Phil Archer <phila@w3.org>
- Cc: Public GLD WG <public-gld-wg@w3.org>
On 27 Sep 2012, at 17:59, Phil Archer wrote: >> [[ >> 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? What do you mean, stop them? This isn't stopping anybody. This is just preventing them from calling whatever they do a “DCAT-conforming data catalog”, which they shouldn't be too upset about, given that it's not a data catalog. People who want to use DCAT for other things than data catalogs can of course do that, they just can't claim DCAT conformance, because DCAT doesn't define what it means to conform if you're doing other things than catalogs. >> * 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? Sure, but just using dcat:keyword doesn't make a DCAT-conforming data catalog. >> * 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? Doesn't hurt, I think. >> 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. Yup, it's intended as an alternative to your proposal. Yours talks about *applications*. The proposal above talks about *specifications* that extend DCAT. That's more appropriate IMO. OKFN's planned DCAT-based harvesting protocol isn't really an application in itself; it's a protocol, it's a spec. The proposal above means that OKFN can say that their protocol is a DCAT profile. Best, Richard > > > > > >> >> >> 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:12:14 UTC