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

Hi, Ghislain,

Sorry about misspelling your name.

Cheers,
Laufer


2014-05-19 12:03 GMT-03:00 Laufer <laufer@globo.com>:

> Hi, Ghislam,
>
>
> >> 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.
> Interesting. I think it would be necessary to have vocabularies to
> describe these "computed" metadata.
>
> >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.
> This is a starting list. We have to discuss it a lot. The name "URI Design
> Principles" could not explain what I have thought. I was thinking about a
> rule that a dataset could have, in a way that a Consumer could build an
> appropriate URI for accessing a specific resource (the definition of
> resource used in rdf).
>
>
> >> What's the difference between "format spec" and "data format"?
> I think that the terminology has to be well-defined and some terms are
> difficult to be understood only by their names.
> Some information that is related to the "Use" task could be of the
> Consumer interest when choosing the dataset, during the "Search" task . The
> two types are related: "Format Specification" and "Data Format". "Date
> Format" could be for example, "CSV" and "Format Specification" could be the
> semantics of the CSV file (defined by the CSV on the Web WG). But, again,
> the names of these metada types have to be defined and described.
>
>
> >>As others pointed out, we could define a small set of mandatory field
> when providing the metadata.
> +1. DCAT AP also did this kind of thing.
>
> Cheers,
> Laufer
>
> 2014-05-16 4:26 GMT-03:00 Ghislain Atemezing <auguste.atemezing@eurecom.fr
> >:
>
> 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
>>
>
>
>
> --
> .  .  .  .. .  .
> .        .   . ..
> .     ..       .
>



-- 
.  .  .  .. .  .
.        .   . ..
.     ..       .