Hello in this lecture we will go forward in the analysis of the tools in order to implement the Europeana Data Model requirements. Remind from the previous lecture that we have basically seven requirements. We have already seen how to deal with requirement number one and the tool is the use of ORE aggregation that connects together. The real object identified by the Edm:ProvidedCHO, namely the provided cultural heritage object, and a number of views of Web resources related to the object. Then we have seen, that it's a good practice to have a unique identifier that it is distinct from the metadata describing the object, in order to avoid the ambiguity between the description of the object and the object itself. And then we have seen a number of standards, used in order to support the implementation of these mechanisms. Such as RDF, the Dublin Core Metadata Initiative, the ORE object reuse and exchange and the SKOS. So, today we will focus on requirement number 3 and number 4. So first of all requirement number 3. So, since data on the real object can be possibly provided by a number of providers, we have seen in previous lectures that the Mona Lisa are provided by the Louvre website or from the Jaconde website. So possibly, those metadata can be, can contain potentially contradictory statements. Remind the title of Mona Lisa, in one case is Mona Lisa in the other case is Giaconda, okay? ... or in general they can be different. So we need a mechanism to describe the object from the perspective of the provider that is offering the data. So from the perspective of the aggregation, remind the aggregation is the tool that we use in order to connect the real object with its digital representation. Okay, so, the general schema is the following, suppose you have two providers, we have two proxies that allow us to associate to the same object, the information from the two providers. To clarify the concept of proxy, let's see this example. So you see that in this case you have two proxies, the proxy 1 and proxy 2, that are actually connected with the aggregation of the two data providers for Mona Lisa that we have seen in the previous lecture. So the Louvre in one case, on the bottom side on the slide, and the Direction des musèes the France on the top. As you can see, here there is an example of contradictory statement, as we observed before, because the title is in one case portrait de Mona Lisa. dite La Gioconde. In the other case is portrait Lisa Gherardini. Again, dite Mona Lisa. So you see that, through proxies we allow the coexistence of these two contradictory statements regarding the same real object, okay? But Europeana itself, creates new data for the objects it ingests. In particular for two main purposes. One is for harmonization purpose and the other one is for semantic enrichment. So, also Europeana exploits the proxy mechanism, in order to make possible, theycoexistence ... ... for having information from Provider 1 in this case, Provider 2, and Europeana. In this case, we call it a Europeana proxy. Okay, again, in this example this is basically the example we saw before in which we have removed for the sake of readability the provider number 2 you see there is now the Europeana proxy, in which there is the connection with the agent inside the Euopeana that describes Leonardo Da Vinci, the creator. At the same time, the European Aggregation is connected to a new Web resource that is the landing page for Mona Lisa. So, again proxy mechanisms are used to integrate information coming from a number of providers, Europeana included. Okay, the last requirement that we have to analyse is the support for object that are composed of other objects. In other way, we want to support some kind of hierarchical representation, of objects. In this case, the Europeana Data Model provides two relationships, one is hasPart and isPartOf, okay? These relations allows us to describe the inclusion links between objects. The other one isNextInSequence, that allows to establish in order among the parts that compose the object, let's see this with an example. In this example, we are simply analyzing an atlas, that is clearly made ... ... of individual pages, and this atlas is available at the National Archives of the Netherlands. Let's click here to have a look, okay. This is the atlas and as you can see, you can move through the pages. So, this is page two, page three, page four and so on and so forth. So clearly, this atlas is made of a number of pages, okay. So in this case, we have the proxy for the atlas that, ... is connected to a number of parts. Through the DC terms hasPart that are proxies for the aggregation in which individual pages are described. The connection between the proxies of the pages, sorry the, the, the current sequence in order to explore the proxies related to the pages, is defined through the relationship isNextInSequence. And so you see, you can move from page one, to page two, to page three, and so on and so forth. Okay, just to recap, we have now had a look to all the requirements of Europeana. A good starting point to a deeper understanding of Europeana is the Europeana Data Model definition that is available as a PDF, you have a link here. And those are two pictures that I think can help in order to organize the concepts that we have seen in the last two lectures. So first of all, the core classes, they provided cultural heritage objects, so the unique identifier for the physical object we are considering, Mona Lisa. The web resource, a number of digital representations of Mona Lisa. The ORE aggregation, the digital representation and the real object are connected to an aggregation that is the point of view of a single provider. The contextual entities... We have events, we have agents, we have places, and so on and so forth. And then the proxy that allows the coexistence of information, possibly contradictory, provided by different providers and then we have the property hierarchy. Remind that as an example we have seen several time the hasMet property. So hasMet is a part of a more general relationship that is isRelatedTo, that is part again of a more general relationship that is the DC:relation, okay? Again, please have a look to the Europeana Data Model definition. In this case, we are now at the version 5.2.5 and ... you see here all the concepts that we have seen in our slides very quickly, our lecture very quickly, are explored in greater details. Okay, so, well, now let's play the role of a provider, okay? I have some digital content, I want to contribute to Europeana. What are the mapping guidelines? What are the ... the guidelines that I have to follow in order to be consistent with Europeana Data Model? Okay, there are a number of guidelines that are listed in this Europeana Data Model mapping guideline document. Again, you have a link here, you can click on it and see the PDF. Here, I just summarize the most relevant from my point of view. So, first of all, providers should give as much properties as possible, as many properties as possible from their existing data. But definitely, they do not have to use all the available EDM properties. There are some mandatory properties and some recommended properties and you see ... in the table. on right... what are the mandatory as an example from the provided cultural heritage object point of view, clearly you need a title, you need a language for the description, you need the subject. And then a Europeana Data Model type, and then you have a number of recommended properties, okay? B, you have to provide only references or literal values to avoid duplication of data. If you remind when we discussed the linked data principle, this is a good practice in order, again, to avoid duplication of data. Sure, you have to be as much precise as you can so if you can use subproperties in order to be more specific and remind again from previous lecture that you can use more general properties and then provide also more specific properties. The example we saw is the hasMet relationship and then the creator relationship, okay? Then about proxy, and I am quoting from the, from the document. "In the first stage, Europeana will focus on ingesting simple Europeana Data Model data without proxies. The only proxies that are required are the ones created by Europeana itself, in relation with its semantic enrichment efforts." So, I know that the proxy concept could be a bit difficult at the beginning to be implemented. But as you see, Europeana suggests for the first stages, just to provide data without proxies. Only Europeana will use this mechanism in order to enrich the data. Let's see a very simple example that again you can find in the mapping guideline document. I provided you the link, you the link in this slide before. So let's suppose that you're the provider again and the, you're object is described by Lido. Lido is again another standard that stands for Lightweight Information Description Object, okay? In this case, you see that Lido, being a standard and consistent with XML, what you have to do is to map this information into Europeana Data Model, ... and in this case you need a unique identifier for the provider caltural heritage object. In this case, it's the UEDIN:214, so this is the unique identifier we use. Then we need a title, in this case it's Buccin Trombone Nominal Pitch B, and then you have as an example information on the date of this object, this is an instruments ... it is about 1840. Okay, ... this is an excerpt from a very complex example. We do not have the time here to go into the details of the example but I strongly encourage you to go to the mapping guidelines document and to see the appendix in order to figure out what is going on. Very well, concluding, we have first seen the importance of using proper tools, mechanism, and standards in order to describe digital resources. Then we have seen how those concepts can be applied in the context of the description of cultural heritage objects. Remind that the final purpose is to better support, the preservation, and dissemination of our rich cultural heritage. Bye bye.
