Re: Best Practice 4 (Document Metadata) - I agree to suppress it

>
> I'm sorry, but I made a mistake in one of my comments in the previous
> message.
>
> "1. Document metadata BP: data publishers SHOULD maintain a
> >> documentation of the metadata that describe your data. This BP
> >> concerns something that has to be done by the data consumer, but this
> >> action doesn't have a direct impact on data consumers. "
>
> "This BP concerns something that has to be done by the data
> consumer,...", it should be this BP concerns something that has to be
> done by the data PUBLISHER.
>

Yep, makes more sense now :)


Some more comments are inline:
>

Doing the same


>> In this case, it should be more clear what is the real meaning of
> >> "documenting". If documenting means to "provide a document that
> >> describe the metadata", then I think that BP on human vs. machine
> >> readable metadata covers this requirement. On the other hand, if
> >> documenting metadata concerns to maintain a documentation for
> >> metadata, then maybe we should have a different BP. In this case,
> >> there will be three BP:
> >
> >
> > As I said in a different thread, I am also pretty unsure about the
> > appropriateness of the human vs. machine BP. In brief I think this
> should be
> > better separated into BPX provide machine readable metadata (the
> term-value
> > pairs); BPY provide (human-readable) metadata documentation and BPZ
> provide
> > self-documented metadata (machine readable documentation associated with
> the
> > format, eg. RDFs or XMLs)
> >
> > I don't see the difference between "provide a document that describe the
> > metadata" and "maintain a documentation for metadata" either.
>
> Yes, I think we can have two separate BP: BPX provide machine readable
> metadata (the term-value
> pairs); BPY provide (human-readable) metadata documentation. But, it
> is not clear for me the need of BPZ provide
> self-documented metadata. I think that BPZ will be redundant with BPX, no?
>

Don't think so.
e.g. you can fulfill BPX with XSL or CSV but then won't be fulfilling BPZ
then, if you use RDF or XML for example, you will be fulfilling both BPs

That's the difference and the reason why we need both and in separated BPs



> >> 1. Document metadata BP: data publishers SHOULD maintain a
> >> documentation of the metadata that describe your data. This BP
> >> concerns something that has to be done by the data consumer, but this
> >> action doesn't have a direct impact on data consumers. There is
> >> another BP (Provide metadata) to say that this documentation should be
> >> provided to data consumers. This BP should be more general than the
> >> Document Vocabularies BP. The metadata documentation should just tell
> >> the vocabularies that are used, instead of providing a complete
> >> documentation for vocabularies.
> >
> >
> > Don't understand why you say that documenting metadata is a data consumer
> > responsibility.
> > Also the only. I insist. We shouldn't say that metadata are also
> > vocabularies (although there are vocabularies for metadata). That will be
> > quite confusing for most of the people in a global (non-LD aware)
> audience.
> > When I want to reuse some data I'm looking for both, the metadata
> > documentation (useful to search and filter) and the data model
> documentation
> > (useful to be able to make things with that data)
>
> I agree with you that metadata and vocabularies are not the same thing.
>

Good!



> >[...]
> >
> > My proposal is:
> >
>
> > BP1 on metadata availability (just provide whatever metadata)
> ok!
>
> > BP2 on machine readable metadata (term-value pairs)
>
> It is not clear why do we need two separate BP: BP2 and BP 4. What do
> you mean by "term-value pairs") Could you please give a simple
> example?
>

The actual metadata in whatever machine readable format you choose.
i.e.

title: "whatever title"
description: "whatever description"
date: "whatever-date"
...

All encoded in RDF, JSON, XML, CSV... or the machine readable format of
your choose



> > BP3 on documenting what metadata terms you are using (human readable
> terms
> > options, possible values, ranges and the like)
> ok!
>
> > BP4 on self-documented metadata (metadata with associated machine
> readable
> > schema)
>

This one force you basically to choose a format with an associated "schema"
for encoding your metadata
i.e. can't use CSV to fulfill BP4, but still can use RDF or XML

Hope this helps.
Best,
 CI.



> > BP5 on reusing generic standard metadata terms when possible (i.e. dc,
> foaf
> > and the like)
> ok!
>
> kind regards,
> Bernadette
>
> >
> > Best,
> >  CI.
> >
> >
> >>
> >> Cheers,
> >> Bernadette
> >>
> >>
> >> 2015-01-20 21:51 GMT-03:00 Laufer <laufer@globo.com>:
> >> > Hi, Carlos,
> >> >
> >> >> BP4 is about documenting what metadata terms are you finally using
> >> >
> >> > Terms are parts of a vocabulary.
> >> >
> >> > And we will have a whole section about vocabularies.
> >> >
> >> > Metadata is documenting data. Then, metadata should be documented.
> These
> >> > documents about metadata are metadata of metadata. We should take care
> >> > about
> >> > an infinite chain.
> >> >
> >> > If we talk about documents for machines, we are talking about
> >> > vocabularies.
> >> > And section 7.
> >> > 4 will take care of this.
> >> >
> >> > If we are talking about humans, metadata is the documentation. Have a
> >> > documentation about metadata is mandatory. If metadata does not have a
> >> > documentation, it does not have a meaning. For example, If one says
> that
> >> > the
> >> > dataset has a GNU license, how this can be understood by a human if
> GNU
> >> > is
> >> > not documented? The meaning is the documentation and must exist if
> >> > someone
> >> > decides to refer to it.
> >> >
> >> > In respect to code lists, (maybe this is not the formal definition) I
> >> > think
> >> > they are a kind of type, or even a kind of vocabulary. Again, I think
> >> > section 7.4 is a better candidate to talk about this.
> >> >
> >> > Best regards,
> >> > Laufer
> >> >
> >> >
> >> >
> >> > Em terça-feira, 20 de janeiro de 2015, Carlos Iglesias
> >> > <contact@carlosiglesias.es> escreveu:
> >> >
> >> >> Hello everyone,
> >> >>
> >> >> Here goes my view on this:
> >> >>
> >> >> - I tend to disagree on (former) BP4 being derived from BP1+2+3
> >> >>
> >> >> BP1 is on metadata availability (provide metadata)
> >> >> BP2 is on human vs. machine readable metadata (how to present
> metadata)
> >> >> BP3 is reusing generic standard metadata terms when possible (i.e.
> dc,
> >> >> foaf and the like)
> >> >> BP4 is about documenting what metadata terms (being reused or ad-hoc)
> >> >> are
> >> >> you finally using
> >> >>
> >> >> I don't see overlap between any of the above.
> >> >>
> >> >> - WRT BP11 Document vocabularies
> >> >>
> >> >> I don't see any overlap with (fomer) BP4 either as:
> >> >>
> >> >> BP4 is about documenting what metadata terms are you finally using
> >> >> BP11 is about documenting your data (not metadata) models (or
> >> >> "vocabularies") in the case you are developing new ones.
> >> >>
> >> >> - Finally WRT Annette's comments I think there is a missing point
> here:
> >> >> BPXX Document your data
> >> >>
> >> >> This is about the "data codebooks" that should be accompanying our
> data
> >> >> as
> >> >> additional documentation but unfortunately are rarely available
> making
> >> >> working with 3rd party data a pain. This "codebooks" usually document
> >> >> all
> >> >> the information that Annette is refereeing to in her message and
> more.
> >> >>
> >> >> Best,
> >> >>  CI.
> >> >>
> >> >> On 20 January 2015 at 21:00, Annette Greiner <amgreiner@lbl.gov>
> wrote:
> >> >>>
> >> >>> Here are a few things that come to mind as needing to be documented
> in
> >> >>> metadata.
> >> >>> Units, for any measure that is not unitless.
> >> >>> For responses to a survey question, the question itself and how it
> was
> >> >>> coded. (This is where code lists come in.)
> >> >>> Meaning of nulls, zeroes, NA, etc.
> >> >>> language, locale (we have this one covered elsewhere, but probably
> it
> >> >>> should be included under the more general BP.)
> >> >>>
> >> >>> I think the metadata information right now is a little bit
> redundant.
> >> >>> Documenting metadata is really the same as providing metadata. When
> we
> >> >>> have
> >> >>> generalized the BP about documenting, it will be even more like the
> >> >>> one
> >> >>> about providing metadata. In both cases, we are talking about using
> >> >>> good
> >> >>> metadata to describe the data and making it available to data
> >> >>> consumers.
> >> >>> -Annette
> >> >>> --
> >> >>> Annette Greiner
> >> >>> NERSC Data and Analytics Services
> >> >>> Lawrence Berkeley National Laboratory
> >> >>> 510-495-2935
> >> >>>
> >> >>> On Jan 20, 2015, at 5:16 AM, Bernadette Farias Lóscio
> >> >>> <bfl@cin.ufpe.br>
> >> >>> wrote:
> >> >>>
> >> >>> >
> >> >>> > The Document metadata BP should be rewritten to become more
> general,
> >> >>> > i.e., not just vocabularies should be documented. In this case,
> what
> >> >>> > else should be documented when talking about metadata?
> >> >>> >
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> ---
> >> >>
> >> >> Carlos Iglesias.
> >> >> Internet & Web Consultant.
> >> >> +34 687 917 759
> >> >> contact@carlosiglesias.es
> >> >> @carlosiglesias
> >> >> http://es.linkedin.com/in/carlosiglesiasmoro/en
> >> >
> >> >
> >> >
> >> > --
> >> > .  .  .  .. .  .
> >> > .        .   . ..
> >> > .     ..       .
> >>
> >>
> >>
> >> --
> >> Bernadette Farias Lóscio
> >> Centro de Informática
> >> Universidade Federal de Pernambuco - UFPE, Brazil
> >>
> >>
> ----------------------------------------------------------------------------
> >
> >
> >
> >
> > --
> > ---
> >
> > Carlos Iglesias.
> > Internet & Web Consultant.
> > +34 687 917 759
> > contact@carlosiglesias.es
> > @carlosiglesias
> > http://es.linkedin.com/in/carlosiglesiasmoro/en
>
>
>
> --
> Bernadette Farias Lóscio
> Centro de Informática
> Universidade Federal de Pernambuco - UFPE, Brazil
>
> ----------------------------------------------------------------------------
>



-- 
---

Carlos Iglesias.
Internet & Web Consultant.
+34 687 917 759
contact@carlosiglesias.es
@carlosiglesias
http://es.linkedin.com/in/carlosiglesiasmoro/en