Re: ACTION-76 Working for conformance of vocabularies

"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."

+1

This is the same argument I have with the Geonetwork crowd in the spatial / GIS activity space who poo-poo DC. Just because you can describe a publication with Geonetwork metadata, doesn't mean you should - it's not as fit for purpose as DC obviously is, or RDA if you want to get all librarian on it.

Same here: using DCAT to describe something that isn't a data catalogue is basically like using foaf to describe something that isn't a person. You might get close, but it will be an ill fit and you'll end up extending it into something bespoke anyway to fit the square peg in the round hole.

I guess that's my point about RADion as well - the fundamental principle of SemWeb (and by extension LD) is the thing described has a set of attributes that makes it unique compared to other things, and when you have enough of these unique attributes to make it essentially a full blown class in and of itself, it warrants its own vocab.

A repository is one thing. A data catalogue is another thing. A printed publication is another thing. And you may well get a printed publication of data in a catalogue format, which is held in a physical repository that we'll call a town library (for want of a better term ;) ) - now I can use DCAT to describe the printed book, the catalogue and the repository, but for the first and last, I won't do it well.

Additionally, +1 on Richards spec based prop vs an app based one. This is how everything else usually works in the real world - XML for instance, or X/HTML. Both are pretty loose and forgiving, but with out a schema/XSD or writing in Strict rather than Transitional, we happily label them "malformed", non-conforming or "sloppy code" aka not standards compliant.

IMHO, within my job, it's v. important that we include a DCAT profile, since Government, which will remain one of *the* primary and leading producer of datum, datasets and data catalogs for a long time to come - and Gov is quite obssesed with codifying things and being "standards compliant" in the ICT space as it fundamentally lets us hold vendors/service providers to a standard, and lets us swap data with each other easily.

And when you're writing that tender doc, tech doc or unit/UAT test plan, it makes life a lot simpler to say "thall shalt provide me a solution with endpoint and API that can be queried using a DCAT compliant protocol." then saying "make me something bespoke that I can't test against a standard before I give you this bucket of money". ;)

(Yes Bernadette - I'm pulling an all nighter btw...)



Sent from Samsung MobileRichard Cyganiak <richard@cyganiak.de> wrote: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