Utente:Aubrey/Metadati

Ti spiego una cosina, per spiegarla a me e scriverla da qualche parte. Sto imparando (ma dato che è un prcesso in corso potrei aver frainteso) che la questione metadati, per come sono gestiti, funziona più o meno così.

(copio-incollo da una mail che avevo mandato a jean Fred ed SJ)

• the whole librarian system is built around metadata, which are very

often structered in many different format and standards:

• • Dublin Core, MARC are descriptive metadata standard (e.g. title, author...)
  • MAG, METS are structered metadata standards (e.g. first page,

cover, last page) (obviously, for books)

• OAI-MPH is a protocol for metadata communication: digital library

systems like DSpace, EPrints, etc. let the user

• • upload a file,
  • add his metadata (using some standards),
  • index, import, export the metadata,
  • using OAI-MPH, the system provide the metadata to third-party

harvester, who can come and harvest them.

This is a strange architecture:

• there are data providers (libraries, repositories)
• there are service provider (aggregators)

and there is this data flows, with harvester that like bees fly around and take metadata and stuff and take it to aggregators.

• Obviously*, everything works when we have machine-readable files and

data. Everything should be done automatically (at list, when we follow the standards, things go quite well).

Ora, io vedo che spesso, nonostante l'architettura sia questa, vari servizi hanno esigenze diverse. Usare i campi Dublin Core, per esempio, è una convenzione, non cambia nulla, di fatto, a come stiamo facendo adesso. Cambierebbe che

• chiamiamo ufficialmente dc.author il campo autore
• dovremmo trovare il modo, in un qualche modo, di esportare quel metadato autore a piacimento, e farlo viaggiare secondo i protocolli.

Io spess vedo che i nostri repository, qui in università, hanno dei campi predefiniti, utilizzano DC e tutto. ma se diversi aggregatori vogliono dati diversi (uno sono 10 campi, l'altro 12, ecc) noi gli esportiamo e impacchettiamo come vogliono loro. E' questa flessibilità di flusso di metadati, io ritengo, quello che veramente manca a wiki. Cioè un software che sappia importare ed esportare i metadati in maniera modulare, flessibile, e automatica. Che li riconosca come dati e non testo.

Ci tenevo a dirti questa cosa, per darti, nei limiti del possibile, una vaga idea di come funziona a livello "professionale". non siamo poi così lontani. Spiace solo dover reinvetare strani modi (con section e toolserver) per fare cose che altrove fanno in maniera più standard.

ti lascio in appendice la fine della lettera precedente, magari c'è qualcosa in più che ti serve.

Aubrey

Now, this is what we miss: in Commons, that is our best repositories, everything is done in wikitext, nothing is machine readable (whatever this means)

My perspective is that if we want to do something now, without waiting for a software revolution, we shoud set up

• a sort of dbcommons/wikidata/toolserver intermediary, where to put out data
• a sort of harvester, who goes in Commons and takes the data from the

templates, and put it there

• a sort of "standardizer", which post-process the data and put them

in a machine-readable format (maybe many formats) for other harvester to come and take them.

This would be a massive hack/patch, because doing stuff in toolserver is not the best thing, but it is something. Think about personeData, it is a proof orf concept, and it does not involve other extensions or similar.

Eventually, this is what I would have told in our little discussion in Berlin. Probably that are many errors, but this is the draft of the idea. Unfortunately, it requires much work.

I bet you understand more of these things bettere than me (you know about sstandards and XML), so you can teach me something :-)