Il giorno sab, 11/06/2011 alle 14.03 +0200, Piotr Praczyk ha scritto: > In some other areas, it is missing concepts we need.
If I am not mistaken, it's only the support for file revisions or what else? > What level of support for METS did you have in mind ? Exporting data. > importing in full format, importing in some subset of the format ? > Do You think, we could easily implement something that would deal with > concepts present there ? > - metadata of objects encoded in different formats (it looks like a more > general concept of MoreInfo) > - relations between different parts of different files (in the examples, > they showed how to divide monolith files into chapters and link them between > iach other (audio format with transcript format)) > Implementing all this sounds like a rather big project for me ... especially > that we would have to extend the standard (which would make us again not > completely compatible). > What do you think about this ? Maybe METS should not be native to Invenio but > we should start with supporting the possibility to export data in this format > ? Ouch I replied to this in the email to Cristian but keeping it short, I think it the long term it would be nice to support METS in importing and exporting, (by storing a side when importing anything that is not understood, so that it can be re-exported), and in the short term (i.e. for your case) it would be nice if you can keep at least METS in mind to be sure that it will be possible to support it somehow in the future. > not necessarily. the use cases I know (probably there are more about which > Salvatore and Suenje have knowledge) are : > 1) (the most obvious for me) - the case of standalone plots showing an > important phenomenon. The access to them shall be provided by the figures > search. Isn't this addressed by associating a record to the standalone plot? (especially to search for it, I guess you will do it through its metadata). > The idea was to provide new mechanism not modifying the existing > capabilities of Bibupload... just stopping to use FFT for objects as > Figures. Great! > Indeed, I was thinking about having one tool only because of the temporary > identifeirs described later. > Having one tool makes their semantic easier. We do not have to implement > complicated scenarios of detecting if a given temporary id is still necessary. > Do you see any elegant solution to this problem with separate tasks ? I see, indeed it make perfect sense. > if MoreInfo grows, usage of blobs will become increasingly unefficient. > In fact, I was talking some time ago with roman about usag of some > Key-Value store (he also needed something) ..... and the namespaces in > MoreInfo were somehow inspired by column families present in HBase. or JSon in MongoDB :-) > > Example of linking to a document being uploaded in parallel: > > > > <record> > > <specialfield tag="001">234</specialfield> > > <datafield tag="BDR"> > > <subfield code="a">tmp:NewDocument</subfield> <!--the identifier of > > BibDoc --> > > <subfield code="r">number of a document to reference</subfield> > > <subfield code="t">Main</subfield> <!--the identifier of BibDoc --> > > <!-- other subfields characteristic to the relation --> > > </datafield> > > </record> > > > > ??? Should we always attach a document or only its particular version ? > > (or marking that all versions? ) > > >As I mentioned before I really think that a link can only be made across > >specific versions of bibdoc. > > yes! This is exactly the use case that was inspiration for relations between > versions... > BDR link between record and document. > BibDocRelation is a different thing - does not involve records, BDR does. > BibDocRelation has to be obviously versioned, BDR - this was my question ;) Mmh, if we keep on with the philosophy of bibdocfile, a document (including the two dimensions of multiple formats and multiple revisions), is as a whole attached to a record, so IMHO BDR should not specify a version. > > >As a side track, as this is needed also in the context of BibEdit, we > >were thinking of decoupling the semantic of an FFT tag from the > >--insert/correct/append/delete/replace mode being used in BibUpload. In > >the end these modes have a meaning WRT metadata but are a bit confusing > >WRT what to do with fulltext. For this reason it might be nice to > >officialize a subfield in the FFT to put the actual "command" to perform > >(i.e. append/revise/delete) a bit like today is done with the $t. > makes sense but requires a little of conceptual work -> this would involve > many special cases and situations with non-obviously clear semantics. I will ticketize it :-) > >> +++ A larger example - Uploading of two new BibDoc and their attachment > > >Your copyright example makes me even more thing about METS! (see the > >Administrative Metadata section). > ><http://www.loc.gov/standards/mets/METSOverview.v2.html#admMD> > > Indeed... I just wanted to ilustrate that other modules (someone was roking > on exactly this for Invenio ? ) fit into this scheme... > moreover, I wanted to have a piece of moreinfo that wold have to be attached > to a particular file. Yes, it's stored in MoreInfo but as a very structure information (that is also synchronized in MARC to be searched later... indeed fulltext management is becoming complex :-) ). > >> (...) > >In the end, on a side track, it would be really nice to refactor these > >class structure not to only represent bibdocs on the filesystem, but > >e.g. to be able to offer the same interface for URLs referenced in the > >MARC (in 8564 tags), so that it could become transparent to manage > >resources attached to records, regardless of them being on filesystem or > >remote. Similar side track would be to be able to have a class for > >transient bibdocs (e.g. wrapping temporary files on disk), that are not > >archived in the final structure of the filesystem. Indeed this can be > >done in general by assuming a bibdoc is not necessarily attached to a > >record. > What is the usecase that would benefit from this ? I can not see it. Easyness in formatting (through BibFormat) the attached files (whetever via BibDoc or simply MARC) and uniformity in the CLI interface. > btw... what do you think about JSON in XML ? Do you think, we should go > for some encoding of everything in XML or rather do like here ? I really like more and more JSON, so as although I feel its a bit striking to see JSON inside XML, it might be easy if in the future we will add some fully JSON-based API. Cheers! Sam -- Samuele Kaplun Invenio Developer ** <http://invenio-software.org/>
