Re: [BP - MET] - Best Practices - Guidance on the Provision of Metadata

Hi Laufer, all,
Thanks for this great starting discussion. Find below my 2 cents ...
> I created a page on the wiki, "Best Practices – Guidance on the
> Provision of Metadata", where we can put the information about this
> topic. I took the liberty to define a prefix in the subject of the
> e-mails related to these discussions: [BP- MET].
>
> I would like to expose some thoughts that I think are related to the
> data on the web ecosystem. I see a kind of data architecture that has
> three big roles: a data Publisher, a data Consumer and a data Broker.
> The Broker is the one that has information that can be used by the
> Consumer to find data published by the Publisher.
>
> As an example of Brokers we can think about implementations of CKAN,
> used by data.gov <http://data.gov>, dados.gov.br <http://dados.gov.br>,
> etc. CKAN has metadata (provided by Publishers) that are useful for
> Consumers to find data. CKAN is a registry and can also be a repository
> for the data to be consumed. Almost all use cases of DWBP WG are
> examples of Brokers.
>
> At the same time, data published in CKAN implementations can have
> multiple formats, as CSV, for example. Once a Consumer chooses some data
> to use from a Publisher, she needs another kind of metadata to
> understand how to access the data and its semantics.
>
> I propose to create categories and types of metadata. I see two
> categories: metadata for search and metadata for use. Each of these
> categories would have types of metadata. For example:
>
+1. I could consider also metada "computed" based on some provenance 
data + metrics. For e.g.: If a dataset is published by a "certified 
organization" and it is reused by many users/applications, then it has 
higher quality.
> Metadata Types for Search
>
> Human Content Description (free text)
..and categories/themes
>
> Machine Content Description (vocabularies)
>
> Provenance
>
> License
>
> Revenue
>
> Credentials
>
> Quality / Metrics
>
> Release Schedule
>
> Data Format
>
> Data Access
+1 for all this first metadata types
>
> Metadata Types for Use
>
> URI Design Principles
>
> Machine Access to Data
>
> API specification
>
I am not sure to understand the above types. Could you give us an 
example why "vocabularies" are not in this list, but "URI design 
principles" is here? One may think that there is no principles in 
designing URIs for vocabs.
> Format Specification
>
What's the difference between "format spec" and "data format"?

As others pointed out, we could define a small set of mandatory field 
when providing the metadata.

Thanks again for taking care of this section.

Cheers,
Ghislain

-- 
Ghislain Atemezing
EURECOM, Multimedia Communications Department
Campus SophiaTech
450, route des Chappes, 06410 Biot, France.
e-mail: auguste.atemezing@eurecom.fr & ghislain.atemezing@gmail.com
Tel: +33 (0)4 - 9300 8178
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~atemezin
Google+:http://google.com/+GhislainATEMEZING
Twitter:@gatemezing

Received on Friday, 16 May 2014 07:27:02 UTC