EDM elements mapped to Schema.org elements

Transcription

1 EDM elements mapped to Schema.org elements EDM data is divided amongst classes representing different resources (the original object, the digital representation etc.) in compliance with the oneto-one principle. For the purpose of schema.org mark-up, the statements attached to the ProvidedCHO, corresponding proxies and aggregations are merged onto one single resource. See for the EDM specification. For more rationale on the decisions, see the report from Richard Wallis com/ /projects/ /attachments/ /europeana%20schema.org%20consultancy%20report%20final.pdf EDM element (according to the latest specs 2016) Value type Obligation Definitive mappings Candidate mappings and notes ProvidedCHO & Proxy ProvidedCHO & Proxy schema:creativework All proxies for a given ProvidedCHO contribute to a same schema.org resource dc:contributor schema:contributor Should relate to a schema:person or Schema:Organization dc:coverage schema:about In theory if the coverage is a place (dcterms:spatial) schema: spatialcoverage would be applicable. If a time period (dcterms:temporal), temporalcoverage would be the one. But in practice schema:about is probably the best we can hope for. dc:creator schema:creator Should relate to a schema:person or Schema:Organization dc:date schema:datecreated was thought of, as it's often used as default for CreativeWorks. But it really doesn't fit the dc: date we have in Europeana, which can be any date, not just creation. dc:description schema:description dc: schema:artform Only when we know that the resource is of type VisualArtwork - see note about using VisualArtwork dc:identifier dc:language schema:inlanguage wherever possible should be mapped to BCP 47

2 dc:publisher schema:publisher Should relate to a schema:person or Schema:Organization. so this means this is a property for which we won't be able to map to anything else than schema:thing, unless it comes with a URI that has a schema.org type already. And we won't probably make a mapping process that would be so complex on pulling out external statements right now. So it is flagged as future work. dc:relation dc:rights Mapping dc:rights to to schema:license won't always work as it is not a controlled field and allows s. Only edm: rights will provide a URI (But edm:rights on the Aggregation or WebResource will often be different from the rights of the Provided CHO, see comment in Aggregation) dc:source dc:subject schema:about dc:title schema:name dc:type schema:about Also helps towards decision as to entity type dcterms:alternative schema:alternatename dcterms:conformsto dcterms:created schema:datecreated Wherever possible should be mapped to ISO 8601 dcterms:extent dcterms:hasformat dcterms:hasformat is not a property to map directly to a Schema property. It is a signal to use when identifying which schema Type(s) to use (next to the default schema: CreativeWork) dcterms:haspart schema:haspart dcterms:hasversion dcterms:isformatof schema:exampleofwork Could be used as a signal to identify related work

3 dcterms:ispartof schema:ispartof could additionally be mapped to the more specialized schema:partofseries if the 'part' ProvidedCHO is involved is in a edm:isnextinsequenceof or edm:issuccessorof with another ProvidedCHO that is dcterms:ispartof the same 'whole'. In this case the 'whole' should be dually-typed as CreativeWorkSeries dcterms:isreferencedby dcterms:isreplacedby dcterms:isrequiredby dcterms:issued schema:datepublished Wherever possible should be mapped to ISO 8601 dcterms:isversionof dcterms:medium schema:artmedium Only when we know that the resource is of type VisualArtwork dcterms:provenance dcterms:s schema:mentions dcterms:replaces dcterms:requires dcterms:spatial schema:spatialcoverage subproperty of schema:contentlocation added in v3.1 dcterms:tableofcontents dcterms:temporal schema:temporalcoverage, schema:about subproperty of schema:about added in v3.1. temporalcoverage ideally should be in ISO8601, unless there is a URL for a more descriptive entity is available. There could be a situation where about and temporalcoverage are supplied, describing the same time period, but containing different representations of that period. eg. schema:temporalcoverage: " / ", schema:about: "World War II"

4 edm:currentlocation [0,1] Not to be mapped yet Physical location would be mapped via schema:offer + schema:availableatorfrom - see holdings example: https: // org/community/schemabibex/wiki/holdings_via_offer. But it is preferable to postpone further specification and implementation for the moment, this is property is less urgent, and may benefit from our having richer (organization) data. edm:hasmet edm:hastype schema:about Catered for with multi-typing edm:hastype should be used to help decide the schema Type(s) to assign to a CHO edm:incorporates schema:haspart edm:isderivativeof schema:isbasedon edm:isnextinsequence [0,1] schema:previousitem In combination with schema:listitem for the parent object edm:isrelatedto edm:isrepresentationof [0,1] schema:about edm:issimilarto edm:issuccessorof schema:previousitem In combination with schema:listitem edm:realizes schema:exampleofwork edm:type 1 N/A Europeana purpose only, not really fit for general scenarios Can be used to help decide the schema Type(s) to assign to a CHO or a WebResource edm:waspresentat edm:europeanaproxy N/A Internal purpose edm:year schema:datecreated No property generic enough in schema.org - usually years defaults to using datecreated, but edm:year is too generic (and noisy, due to the process of automatically extracting it. ore:proxyfor N/A Proxies are merged with ProvidedCHOs for schema.org. ore:proxyin N/A

5 owl:sameas schema:sameas rdf:type Aggregation and EuropeanaAggregation Aggregation and EuropeanaAggregation ore:aggregates N/A See above edm:aggregatedcho 1 N/A edm:country 1 schema:addresscountry edm:dataprovider 1 schema:provider Currently Aggregation data is merged with ProvidedCHO and Proxy data. This may be revisited if schema.org adopts a one-to-one approach. edm:hasview schema:url If we can recognize the object of this property to be an instance of (a subclass of) schema:mediaobject then the mapping of hasview should be audio/image/video (as per the section 'audio/image/video' in the report) or contenturl (but if we fail to recognize a specific type of media object then we will probably fail to recognize that we have a media object in general). edm:isshownat [0,1] schema:url edm:isshownby [0,1] schema:contenturl schema:contenturl is only valid for MediaObject & subtypes, which should be alright for edm:isshownby values edm:landingpage schema:url The value is the Europeana portal page URL. edm:language No mapping. Mapping to schema:inlanguage would conflict with the inlanguage built from ProvidedCHO/proxy's dc: language. edm:object [0,1] schema:image Previously this mapping was activated only when there was no preview opt-out from the providers. But this opt-out has been deprecated since. edm:preview schema:thumbnailurl The value is the URL of the thumbnail used for the portal. Previously this mapping was activated only when there was no preview opt-out from the providers. But this opt-out has been deprecated since.

6 edm:provider [0,1] schema:provider dc:rights Rights statements at the level of the Aggregation (and the edm:rights 1 WebResource) are often not the ones for the ProvidedCHO edm:ugc [0,1] There is nothing special in Schema.org that could capture this other than fully detailing the provider with whatever info is available edm:intermediateprovider [0,1] schema:provider edm:webresource WebResource schema:webpage or schema:mediaobject Webpage if the WebResource is refered from the Aggregation using edm:isshownat, MediaObject otherwise rdf:about schema:url The value is the identifier (rdf:about) of the web resource dc:creator schema:creator dc:description schema:description dc: dc:rights Use edm:rights to populate schema:license. but see question in the Aggregation dc:source schema:encodescreativework dcterms:conformsto dcterms:created schema:datecreated Wherever possible should be mapped to ISO 8601 date dcterms:extent dcterms:haspart schema:haspart dcterms:isformatof dcterms:isreferencedby

7 dcterms:ispartof schema:ispartof dcterms:issued schema:datepublished Wherever possible should be mapped to ISO 8601 date edm:isnextinsequence [0,1] schema:previousitem In combination with schema:listitem for the parent object edm:preview [0,1] edm:rights [0,1] schema:license New - but see question in the Aggregation owl:sameas schema:sameas edm:agent skos:preflabel [0,1] per lang tag skos:altlabel Agent schema:person or schema: Organization schema:name schema:alternatename skos:note schema:description dc:date dc:identifier Now EDM does not distinguish persons and organisations at the class level. Many mappings can be used for both, assuming such "noise" is ok for schema.org. Alternatively, we could have rules based on the presence of person- or organization-specific elements like rdagr2:gender. We need: - a list of agent attributes for Agents that indicate a person or an organization - a list of properties for CHOs, whose values are expected to be a person or organization schema:additionalname for person, schema:name for organization. additionalname is person specific and designed for middle names etc. schema:alternatename can be used for all types. edm:begin [0,1] schema:birthdate schema:birthdate for person or schema:foundingdate for organization. Wherever possible should be mapped to ISO 8601 date

8 edm:end [0,1] schema:deathdate schema:deathdate for person or schema:dissolutiondate for organization. Wherever possible should be mapped to ISO 8601 date edm:hasmet schema:knows for person, only if the target is a Person. edm:isrelatedto edm:isrelatedto is broader than the family relations specified for schema:relatedto edm:waspresentat schema:event for organization. For persons, schema: performerin is too specific. foaf:name schema:name rdagr2: biographicalinion schema:description rdagr2:dateofbirth [0,1] schema:birthdate Wherever possible should be mapped to ISO 8601 date rdagr2:dateofdeath [0,1] schema:deathdate Wherever possible should be mapped to ISO 8601 date rdagr2:dateofestablishment [0,1] schema:foundingdate Wherever possible should be mapped to ISO 8601 date rdagr2:dateoftermination [0,1] schema:dissolutiondate Wherever possible should be mapped to ISO 8601 date rdagr2:gender [0,1] schema:gender rdagr2: professionoroccupation schema:jobtitle rdagr2:placeofbirth [0,1] schema:birthplace rdagr2:placeofdeath [0,1] schema:deathplace owl:sameas ref to Agent schema:sameas Places edm:place schema:place Properties of a schema:geocoordinates can be gathered onto a schema:place via a schema:geo wgs84_pos:lat [0,1] schema:latitude

9 wgs84_pos:long [0,1] schema:longitude wgs84_pos:alt [0,1] schema:elevation wgs84_pos:lat_long [0,1] skos:preflabel [0,1] per lang tag schema:name skos:altlabel schema:alternatename schema:name. Several names allowed - or schema:alternatename skos:hiddenlabel If it is sharable with the outside world, it could be mapped to schema:alternatename. skos:note schema:description dcterms:haspart ref to Place schema:containsplace dcterms:ispartof ref to Place schema:containedin edm:isnextinsequence schema:previousitem In combination with schema:listitem for the parent parent owl:sameas ref to Place schema:sameas edm:timespan skos:preflabel [0,1] per lang tag TimeSpan skos:altlabel schema:alternatename skos:note dcterms:haspart dcterms:ispartof ref to TimeSpan ref to TimeSpan edm:begin [0,1] edm:end [0,1] edm:isnextinsequence crm:p79f. beginning_is_qualified_by schema:date is only a datatype for ISO8601 values

10 crm:p80f. end_is_qualified_by owl:sameas ref to TimeSpan schema:sameas Concepts skos:concept Schema:Thing See proposals in the Schema Bib Ext community group. Define as Type schema:thing Also Schema.org extension proposal for External Enumerations: com/schemaorg/schemaorg/issues/894 skos:preflabel [0,1] per lang tag schema:name skos:altlabel schema:alternatename skos:broader, skos: narrower, skos:related skos:broadmatch, skos: narrowmatch, skos: relatedmatch skos:exactmatch, skos: closematch skos:note skos:notation skos:inscheme dcat:dataset cc:license foaf:organization edm:fulltextresources ref to Concept ref to Concept ref to Concept string (+ rdf: datatype) ref to Concept Scheme Other (non-core) Classes: Future Work schema:dataset N/A schema:organization

11 svcs:service skos:conceptscheme edm:event edm:physicalthing oa:annotation schema:service N/A for now schema:event schema:thing schema:product schema:comment schema:review... See paragraph in report. There was some discussion on using children of schema:(assess)action as types here. But the data is possibly the result of performing an action, not the action itself.