Re: issues related to DCAT

Fadi,

Great work on getting the ball rolling again. Below some comments on the issues we haven't decided in today's call.

On 25 Sep 2012, at 15:58, Fadi Maali wrote:
> 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

I don't feel good about this. If we admit that we simply don't know how it's going to be used, then we have no evidence that the current design is any better than the proposed alternative design.

PROPOSAL: Drop dcat:granularity.

Is dcat:granularity deployed somewhere at the moment that prevents this course of 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

PROPOSAL: For now, leave the issue open, and add an “issue box” to dcat:CatalogRecord with the following text: “dcat:CatalogRecord is related to the notion of “named graphs” found in various RDF-related specifications and implementations. This notion is currently being standardized in the RDF Working Group. We may clarify the relationship once RDF-WG has published a candidate 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

The proper term is “media type”. I guess dcat:mediaType would be a subproperty of dc:format? It should be stressed that dcat:mediaType is preferred over dc:format when possible.

> 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:

A reasonable direction. We'd need a list of the properties that are considered for dcat:Distributions. In some cases this may have implications for the domain of the property?

> 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  

dcat:permanentIdentifier is needed to address UC1 and UC2. Specifically, Requirement 4.3 “Persistent URIs for catalog entries” asks for this property. dc:identifier does not satisfy this.

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

+1 obviously

> This leaves the following comments from Rufus's email:
> 
> 1. Remove dcat:dataQauality, dcat:granularity, dcat:dataDictionary
>  suggestion: disagree
>  reason: used by some catalogs

I agree with removing dataQuality and granularity, because they are not useful for any kind of interoperability without further specification.

dataDictionary would be a “resource” in Rufus' terms, but I guess it wouldn't be a “distribution” the way we see it.

The fact that some catalogs have these metadata fields doesn't in itself constitute a reason for having it in a standard.

> 2. Designate optional/required
>   suggestion: no suggestion

PROPOSAL: Define the notion of a “DCAT Profile” in the Conformance section (as proposed in ISSUE-76 thread). Others can then define optional/required restrictions for properties as DCAT profiles.

> 3. rename dcat:Distribution to Resource
>   suggestion: disagree. 
>   reason: Resource is already overloaded and too general

I agree that Resource isn't a good term, for the stated reason.

But note that Resource as Rufus understands it is broader than dcat:Distribution, because it can include things like example links, documentation, and so on.

I suggest raising an explicit ISSUE for this, as it probably requires more discussion.

> 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)

-1 to dcat:sizeString, that's just horrible. The 1024 and the "1kb" are fundamentally related -- they are different representations of the same thing. Splitting it into two unrelated properties is bad.

Perhaps compromise: Replace dcat:size and dcat:bytes with a single property dcat:byteSize, range is xsd:decimal, stating that the value can be approximate.

Best,
Richard

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