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