Re: issues related to DCAT

On 25 Sep 2012, at 16:59, Ghislain Atemezing wrote:
> Re interoperability issue between DCAT and VoID [1], I guess it will be specified somewhere in the spec document or have I missed something?

DCAT is going to be a W3C Rec, while VoID is only an IG Note. A Rec shouldn't depend on a Note, if possible.

It seems more appropriate that the WG formulates a position on the issue (in email or wiki page), and pass that on to the VoID editors, so that the VoID editors can include a section addressing the issue in a future revision of the spec. (Such a revision is likely to happen in 2013.)


> Best,
> [1]
>> Dear all,
>> Continuing with the group's current spirit of getting things done, I am summarizing all current issues related to DCAT and *my* related suggestions.
>> The issues are those on the W3C product tracker and the ones we received via email mainly by Rufus from OKFN
>> I intentionally avoided putting the comments in the issue tracker as most of them have been thoroughly discussed and I don't want to alert people with many emails again.
>> I suggest using the list below to guide discussion during a telco dedicated to DACT.
>> ISSUE 4
>>   summary: Should we define ranges for other people's vocabularies?
>>   suggestion: close issue with no actions
>>   reason: based on the related discussion it seems that this doesn't make big difference. My preference (and Phil's as in the issue description) is to provide usage note without stating assertions about external properties
>> ISSUE 5
>>   summary: Implications of the domain of dcterms:accrualPeriodicity
>>   suggestion: close with no actions
>>   reason: the implication of inferring dcat:Dataset as dcterms:Collection is fine
>> ISSUE 6
>>   summary: How should dcat publishers figure out good URIs for properties with non-literal ranges?
>>   suggestion: close with no action
>>   reason: out of scope. We can provide some pointers in the usage note for values that have some general consensus but without making this part of the vocabulary specification
>> ISSUE 7
>>   summary: Drop dcat:accessUrl, use the URI of the dcat:Download resource instead
>>   suggestion: close with no actions
>>   reason: dcat:accessURL is needed especially when a dataset has multiple distributions (see the related emails on the issue page for details)
>> ISSUE 8
>>   summary: add a property to distinguish direct and indirect access of dcat:Distribution
>>   suggestion: no suggestion
>>   reason: need some further discussions. I summarized three possible options here at:
>> ISSUE 9
>>   summary: dcat:Distribution and its subclasses are unnecessary
>>   suggestion: no suggestion
>>   reason: same as issue 8
>> ISSUE 10
>>   summary: Refine dcat:granularity to dcat:spatialGranularity and dcat:temporalGranularity
>>   suggestion: close with no actions
>>   reason: dcat:granularity is not much used in practice now (but still used by for example and therefore I don't support dropping it). It is hard to suggest refinement to it. suggest keeping it as a general property in case people want to use it.
>> --> close no action
>> ISSUE 11
>>   summary: Is dcat:CatalogRecord related to Named Graphs?
>>   suggestion: close no action
>>   reason: no implication on the vocabulary design
>> ISSUE 12
>>   summary:What values to use to describe formats of dcat:Distribution?
>>   suggestion:adding a property dcat:mimetype to dcat:Distribution as suggested by Rufus. There will be two properties then, dc:format and dcat:mimetype. The former can contain any value even a textual description while the latter states a MIME type value if applicable
>>   reason: caveats- additional property and possible querying complications but serves all cases. looks like a good compromise to me
>> ISSUE 13
>>   summary:attach specific properties to dcat:Distribution and not to dcat:Dataset. Was also raised in Rufus comments
>>   suggestion: the properties of dcat:Dataset are needed however for some cases they need to be attached to the dcat:Distribution instances (like the case of different licenses for different distributions). While that is possible without a change to the vocabulary I suggest making it explicit in the vocabulary specification by adding some properties to dcat:Distribution (dc:modified, dc:created, dc:title)
>>   reason:
>> ISSUE 14
>>   summary: add dcat:permanentIdentifier property
>>   suggestion: close, no action
>>   reason: this is helpful when collecting multiple catalogs. However, a combination of source and dc:identifier is enough (assuming dc:identifier is not globally unique). This looks like an application requirement rather than a vocabulary
>> ISSUE 26
>>   summary:Range of dcterms:language is a resource, not literal
>>   suggestion: using literal formatted as xsd;language
>>   reason: as Richard Cyganiak said in his reply: "And AFAIK, dct:LinguisticSystem could be a datatype."
>> This leaves the following comments from Rufus's email:
>> 1. Remove dcat:dataQauality, dcat:granularity, dcat:dataDictionary
>>   suggestion: disagree
>>   reason: used by some catalogs
>> 2. Designate optional/required
>>    suggestion: no suggestion
>> 3. rename dcat:Distribution to Resource
>>    suggestion: disagree.
>>    reason: Resource is already overloaded and too general
>> 5. instead of dcat:size and dcat:bytes use dcat:size dcat:sizeString
>>     suggestion: agree. drop dcat:bytes and define dcat:sizeString
>>     reason: instead of having :ds dcat:size [rdfs:label "1kb"; dcat:bytes 1024] we have :ds dcat:sizeString "1kb"; dcat:size 1024 .
>>     looks better to me than having an intermediate  resource (either a blank node or with one more URI to manage)
>> Regards,
>> Fadi
>> Sincere apology for the long email
> -- 
> Ghislain Atemezing
> EURECOM, Multimedia Communications Department
> 930, route des Colles, 06903 SophiaTech, Biot, France.
> e-mail: &
> Tel: +33 (0)4 - 9300 8178
> Fax: +33 (0)4 - 9000 8200
> Web:

Received on Thursday, 27 September 2012 17:17:19 UTC