Re: issues related to DCAT

Thanks Fadi for this comprehensive list.  I hope the other vocab editors will comment, as has Dave R already.

George and I just had a planning session for Thursday's call.  We decided we should stay with the vocab focus.  I move to get ORG vocab issues and any remaining DCAT suggestions addressed during this Thursday's call (27-Sept).

If we get ORG and DCAT ready for LC in October, we'll have made real progress.


Cheers,

Bernadette Hyland, co-chair 
W3C Government Linked Data Working Group
Charter: http://www.w3.org/2011/gld/

On Sep 25, 2012, at 10:58 AM, Fadi Maali wrote:

> 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 https://www.w3.org/2011/gld/track/products/2 and the ones we received via email mainly by Rufus from OKFN http://lists.w3.org/Archives/Public/public-gld-comments/2012May/0017.html
> 
> 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  https://www.w3.org/2011/gld/track/issues/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 https://www.w3.org/2011/gld/track/issues/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 https://www.w3.org/2011/gld/track/issues/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  https://www.w3.org/2011/gld/track/issues/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 https://www.w3.org/2011/gld/track/issues/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: http://lists.w3.org/Archives/Public/public-gld-wg/2012Mar/0080.html
> 
> ISSUE 9 https://www.w3.org/2011/gld/track/issues/9
>  summary: dcat:Distribution and its subclasses are unnecessary
>  suggestion: no suggestion
>  reason: same as issue 8
> 
> ISSUE 10  https://www.w3.org/2011/gld/track/issues/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 data.gov 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  https://www.w3.org/2011/gld/track/issues/11
>  summary: Is dcat:CatalogRecord related to Named Graphs?
>  suggestion: close no action
>  reason: no implication on the vocabulary design
> 
> ISSUE 12  https://www.w3.org/2011/gld/track/issues/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 https://www.w3.org/2011/gld/track/issues/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  https://www.w3.org/2011/gld/track/issues/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 https://www.w3.org/2011/gld/track/issues/29
>  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