Re: Requirements for profiles

Hi Lars,

> 
>> Then Karen asked for an example for requirement 5.3. I see the Europeana Data
>> Model (or even better, the DPLA metadata application profile [1], which is a built on top
>> of EDM) as a such combination, as it re-used several vocabularies at the same time,
>> by means of 'combination of combination/constraints' for their elements.
>>
>> Well I must say that I'm not 100% sure at which level the notion of profiles sits in this
>> combination, i.e. whether it's the end result (the DPLA MAP itself) or the various
>> components (i.e. the way EDM 'profiles' DC, plus the way EDM 'profile' SKOS, plus the
>> way EDM 'profiles' OAI-ORE, etc).
> 
> I'd say that EDM is the (application) profile, since it defines constraints on which elements from which vocabularies are to be used and with what cardinalities. Of course EDM can be seen as a modular profile built on components defined elsewhere, e. g. you could have a profile that defines how to express rights metadata (must have one edm:rights element that must contain a URI pointing to a closed list of pre-defined rights statements and if the rights statement is one that mandates attribution (e. g. CC BY) the rights information also must contain a ex:attributionExample element that shows whom to attribute it to). Then harvesters could search for content that adheres to that profile an know exactly how to extract the relevant information. In a way a bit like how Java interfaces work.
>

Could such a component be like
https://pro.europeana.eu/page/edm-profiles#iiif-to-edm-profile
?
Note that I'm not sure this one is full independent from EDM on the theoretical side. But once again, the proof of the pudding is in the eating: some have used it in a non-full-EDM context:
https://pro.europeana.eu/page/edm-in-nomisma-org

Cheers,

Antoine

Received on Wednesday, 22 November 2017 10:43:41 UTC