Re: AW: Requirements for profiles

Lars, sorry for having overlooked this email in the long discussion. Thanks for the feedback, we'll try to fix this :-)

Antoine

On 11/12/17 11:31, Svensson, Lars wrote:
> Hi Antoine,
> 
> On Mittwoch, 22. November 2017 11:43, Antoine Isaac [mailto:aisaac@few.vu.nl] wrote:
> 
>>>> 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
> 
> Yes, I think you could consider the iiif2edm profile as such a component, even if it's not completely independent of EDM (perhaps it could be).
> 
> One minor nitpick on the profile document: §1.5 says "A provider CAN provide access to a IIIF Manifest"; I guess that should be "A provider MAY provide access to a IIIF Manifest" since RFC 2119 lists no keyword "CAN". As an alternative you can of course consider "A provider COULD provide access to a IIIF Manifest" using terminology from RFC 6919 [1].
> 
> [1] https://tools.ietf.org/html/rfc6919
> 
> Best,
> 
> Lars
>

Received on Thursday, 11 January 2018 08:02:06 UTC