- From: Fadi Maali <fadi.maali@deri.org>
- Date: Thu, 30 May 2013 12:11:36 +0100
- To: Christopher Gutteridge <cjg@ecs.soton.ac.uk>
- Cc: John Erickson <olyerickson@gmail.com>, public-gld-comments@w3.org, Makx Dekkers <makx@makxdekkers.com>
Hi Christopher, DCAT adopted the contactPoint property from ADMS. Thanks for Makx, Phil and other people involved in ADMS. I hope this address your comment. https://dvcs.w3.org/hg/gld/raw-file/default/dcat/index.html#Property:dataset_contactPoint Thanks again for the feedback! -------------------------------------------------- Fadi Maali PhD student @ DERI Irish Research Council Embark Scholarship holder http://www.deri.ie/users/fadi-maali On 9 Apr 2013, at 14:16, Christopher Gutteridge <cjg@ecs.soton.ac.uk> wrote: > Great, but doesn't solve the "closing the loop" on open data catalogues. It's important that the consumer can identify where to send error reports to, and this really should be in the metadata. > > On 08/04/13 13:04, John Erickson wrote: >> An adopter could for example use (optional) elements from the DataCite >> schema <http://bit.ly/DataCiteSchema> to reference a contributor and >> contributorType. >> >> >> On Mon, Apr 8, 2013 at 6:35 AM, Fadi Maali <fadi.maali@deri.org> wrote: >>> Hello Christopher, >>> >>> Thanks for your feedback! >>> >>> I agree that it is helpful to have a contact associated with each dataset >>> for corrections and queries. This is currently not part of DCAT as it didn't >>> occur frequently in existing catalogues. >>> It should be possible however for a profile to include extra properties. The >>> conformance section states that a DCAT profile may include classes and >>> properties for additional metadata fields not covered in DCAT ( >>> http://www.w3.org/TR/vocab-dcat/#conformance ) >>> >>> Regards, >>> Fadi >>> >>> On 5 Apr 2013, at 16:24, Christopher Gutteridge <cjg@ecs.soton.ac.uk> wrote: >>> >>> Hi, sorry to leave it so close to the line on giving feedback. >>> >>> I work with datasets which are frequently changing and being updated, such >>> as our staff directory, list of buildings etc. >>> >>> These have errors, and when it's open data people spot these errors and want >>> them fixed. >>> >>> We have been working on the principle that it's good practice to include a >>> contact for every dataset and a URL or email address for suggesting >>> corrections. For this we use the terms: >>> >>> http://purl.org/openorg/contact >>> http://purl.org/openorg/corrections >>> >>> I've just been told by the Europe dcat application profile group that they >>> will only consider terms for the application profile which are considered >>> "part of dcat" and so I would very strongly like to see these terms >>> included, or equivalent terms added. >>> >>> Getting feedback from the consumers of your open data is really key in >>> getting the best value out of it, and should be best practice in all >>> non-static datasets. >>> >>> An example of this in practice is equipment.data.ac.uk -- each dataset from >>> each university has an associated "corrections" email or URL so that when >>> someone views a record and spots an error they can email the correct person >>> at the right organisation rather than asking me (I am only an aggregator, >>> and don't clean the data). >>> >>> -- >>> Christopher Gutteridge -- http://users.ecs.soton.ac.uk/cjg >>> >>> University of Southampton Open Data Service: http://data.southampton.ac.uk/ >>> You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/ >>> >>> Would you recommend the software you use to another institution? >>> http://uni-software.ideascale.com/ >>> >>> >>> >> >> > > -- > Christopher Gutteridge -- http://users.ecs.soton.ac.uk/cjg > > University of Southampton Open Data Service: http://data.southampton.ac.uk/ > You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/ > > Would you recommend the software you use to another institution? > http://uni-software.ideascale.com/ >
Received on Thursday, 30 May 2013 11:12:06 UTC