RE: Best practice for a loosely-structured catalog?

 

Simon,

 

This is indeed an issue that came up in the development of DCAT-AP. In
particular, CKAN is quite liberal in what it accepts as "Resource" related
to a Dataset. The discussion was whether you could map CKAN Resource to DCAT
Distribution, and it was clear that such mapping would have unwanted
effects. This is also related to my earlier question on how "similar"
distributions need to be, which led to a statement that they need to be
"informationally equivalent" (https://github.com/w3c/dxwg/issues/52).

 

I support your proposed solution to use  dct:relation as a catch-all and to
allow for further specialisation whenever necessary and possible. 

 

Makx.

 

From: Simon.Cox@csiro.au <Simon.Cox@csiro.au> 
Sent: 08 June 2018 03:38
To: public-dxwg-wg@w3.org
Cc: Jonathan.Yu@csiro.au
Subject: Best practice for a loosely-structured catalog?

 

Catalogueers: 

 

I've been doing some investigations of some local repositories and
catalogues, and have uncovered that in many cases 'datasets' are 'just a bag
of files'. There is no distinction made between part/whole, distribution
(representation), and other kinds of relationship (e.g. documentation,
schema, supporting documents). So while the precision we are aiming for in
DCAT is clearly valuable in terms of semantics, it is difficult to implement
on these legacy systems. Mostly I see people using the
Dataset-distribution-> relationship for everything . which is clearly
incorrect in many cases. But I doubt if we are unusual in this. 

 

I'm thinking about how to advise on this, while not actually breaking DCAT. 

 

If we made dcat:distribution a sub-property of dct:relation 

 

dcat:distribution rdfs:subPropertyOf dct:relation .

 

then I think we can have a reasonable recommendation to the simple
repositories. 

We could tell repositories that use the 'just a bag of files' approach to
say 

 

               :Dataset987 a dcat:Dataset ; 

                              dct:relation <file1> , <file2> , <file3> ,
<file4> , <file5> , <file6> , <file7> . . 

 

which would not be inconsistent with a later reclassification to 

 

               :Dataset987 a dcat:Dataset ; 

                              dct:hasPart <file1> , <file2> ; 

                              dcat:distribution <file3> , <file4> ; 

                              dct:conformsTo <file5> ; 

                              dct:requires <file6> ;

dct:references <file7> .  

 

If this is not all mad, I will add a new use-case - something like 'Mapping
from simple repository model' - as justification, and propose this tiny
enhancement. 

 

Simon 

 

Simon J D Cox 

Research Scientist - Environmental Informatics

Team Leader - Environmental Information Infrastructure

 <http://www.csiro.au/Research/LWF> CSIRO Land and Water 

 

E  <mailto:simon.cox@csiro.au> simon.cox@csiro.au T +61 3 9545 2365 M +61
403 302 672

   Mail: Private Bag 10, Clayton South, Vic 3169

   Visit: Central Reception, Research Way, Clayton, Vic 3168

   Deliver: Gate 3, Normanby Road, Clayton, Vic 3168

 <http://people.csiro.au/Simon-Cox> people.csiro.au/Simon-Cox 

 <http://orcid.org/0000-0002-3884-3420> orcid.org/0000-0002-3884-3420

 <https://www.researchgate.net/profile/Simon_Cox3>
researchgate.net/profile/Simon_Cox3 

 <https://github.com/dr-shorthair> github.com/dr-shorthair

lov.okfn.org/dataset/lov/agents/Simon%20Cox
<http://lov.okfn.org/dataset/lov/agents/Simon%20Cox>  

Twitter @dr_shorthair <https://twitter.com/dr_shorthair> 

Skype dr_shorthair <skype:dr_shorthair> 

https://xkcd.com/1810/ 

 

PLEASE NOTE

The information contained in this email may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
email in error, please delete it immediately and notify the sender by return
email. Thank you. To the extent permitted by law, CSIRO does not represent,
warrant and/or guarantee that the integrity of this communication has been
maintained or that the communication is free of errors, virus, interception
or interference. 

 

Please consider the environment before printing this email.