Dear Patrick, Thank you for responding. It's extremely helpful to hear from you, and I will try to address your comments seriously and as well as I can.
>>> ... it seems to me simply impossible to map ONIX to LIDO, as they were not >>> designed to describe the same things (as is correctly demonstrated in >>> reference [4]). ONIX can be mapped to library formats such as MARC formats >>> or MODS, but LIDO was designed to account for physical objects, not >>> abstract notions such as publications; the only element of "non-uniqueness" >>> I can find in LIDO is the mention of the state/edition to which a specific >>> art print or photograph print belongs (but a LIDO record is designed to >>> account for the specific print as a physical object, not to describe the >>> abstract notion of "state"). Yes, point taken. ONIX and MaRC21 mappings in both directions do already exist: http://www.loc.gov/marc/onix2marc.html and http://www.editeur.org/96/ONIX-and-MARC21/. However, the distinction between publication abstraction ("Product Type") and the item ("Singleton") seems to hinge on one additional "should have" relation (in FRBRoo) or, in Indecs, a more concrete "all items in this class have" relation, for all properties. This is the main justification for allowing a mapping using all properties of individual items that apply to classes of identical items. If I look at MaRC or ONIX, I find that this approach is already the common usage. Most of the properties of "the product" or "the library resource" are properties of *any and each item* rather than abstract properties of a class; i.e. they are inherited - no-one is checking every single item to make sure (except maybe the end customer or retailer, or librarian, when things go wrong!). It's true that a product still does not have a "repository" or "state" (actually I'm still not sure what "state" means in the museum context), but it may well have an "edition" (again inherited from a more abstract level). Properties that can't apply simply don't get mapped, as per LIDO documentation here: http://network.icom.museum/cidoc/working-groups/data-harvesting-and-interchange/faq/general-questions/ The LIDO schema itself does not prohibit creating LIDO records for conceptual objects. >>> The temptative mapping from UNIMARC to CRM, to which Michael Hopwood refers >>> in his message, is a demonstration that it is impossible to map from a >>> model or format designed to account for abstractions to a model or format >>> designed to account for unique physical things. Yes - this is another tentative mapping experiment, with similar aims - to document where LIDO can and cannot match important properties from the source schemas. >>> As Martin puts it, FRBRoo would be a better match for a mapping target from >>> ONIX (and <indecs>). Yes - one of the expected outcomes of this mapping experiment is a set of proposed extensions and/or adaptations of LIDO to make it fully FRBRoo- and indecs-compatible. This is one of the areas where I require assistance from the experts in these frameworks. >>> The suggestion that a manifestation could be described in LIDO as though it >>> were a unique item does not seem to me particularly helpful. What is the >>> point of doing so? There are several justifications for this, primarily for me those stipulated by the Linked Heritage project itself: 1. The project's Description of Work mandates an ONIX mapping, via LIDO, for integration into Europeana; 2. The specific Work Package I am responsible for necessitates creating mappings for book, music and AV data; 3. Heritage data in general can be enriched by creation of LIDO data for commercially published, in-copyright cultural works, especially looking forward to linked data representations. But also some other use cases one might imagine for the commercial... 4. Facilitation of commercial product data, with links to retail opportunities, alongside relevant heritage objects (in fact this is the business model proposed by the EC, Federation of European Publishers, and adopted by Linked Heritage as a hypothesis); 5. Possible enrichment of commercial product data from heritage links; 6. First steps towards a trusted linked data network in a specific, well-documented domain. ...and heritage sectors: 7. There is intrinsic cultural interest in the products of the commercial media sectors, particularly where these are e.g. editions of classic works, or modern works with heritage topics as their subjects; 8. Many heritage institutions are themselves publishers and could integrate various types of publication (paid and free access) seamlessly into the collections data they share through LIDO datasets. 9. Linked data representations of commercial data (especially from indecs-related schemas like those for books, music and film) will contain robust semantic relations and normally rely on unique, standard identifiers, adding to the potential trust and authority of heritage linked data (there is already considerable overlap e.g. with MaRC/ONIX mappings, or the use of ISBN, ISTC, ISNI(=VIAF) etc.). I hope this goes some way towards explaining what admittedly does seem at face value a strange experiment. Best wishes, Michael Hopwood Linked Heritage Project Lead EDItEUR United House, North Road London N7 9DP UK Tel: +44 20 7503 6418 Mob: +44 7811 591036 Skype: michael.hopwood.editeur http://www.linkedheritage.org/ http://editeur.org/ The information contained in this e-mail is confidential and may be privileged. It is intended for the addressee only. If you are not the intended recipient, please inform the sender and delete this e-mail immediately. The contents of this e-mail must not be disclosed or copied without the sender's consent. We cannot accept any responsibility for viruses, so please scan all attachments. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the company. EDItEUR Limited is a company limited by guarantee, registered in England no 2994705. Registered Office: United House, North Road, London N7 9DP, United Kingdom
