issues related to DCAT

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. 

  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  

  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

  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

  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)

  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:

  summary: dcat:Distribution and its subclasses are unnecessary
  suggestion: no suggestion
  reason: same as issue 8

  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

  summary: Is dcat:CatalogRecord related to Named Graphs?
  suggestion: close no action
  reason: no implication on the vocabulary design

  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

  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)

  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  

  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)

Sincere apology for the long email

Received on Tuesday, 25 September 2012 15:00:37 UTC