Print

Print


Hi Rodolphe,

I understand your being puzzled here. But truly, this is the same property as for the current ESE. The difficulty is thus the same.
Your proposal to give types to web resources instead would make sense in principle. But this property is until now mostly motivated by the need of categorizing the objects ingested in Europeana, and to distribute them in the different result tabs on the portal. In that context, allowing several ens:types to be connected to one object (via different WebResources) would be confusing, as long as we don't have the interface to render that properly.

In fact I expect that dc:format could be used for capturing the type of the individual resources. Of course it's not controlled, and thus some improvement could be made. But well, for the moment we wouldn't be able to do much out of a controlled value for that field in Europeana, so we can't really push it hard now.

Cheers,

Antoine


> Hi all,
>
> I'm having a hard time with:
> ____________________________________________________________
>
> ens:type | literal (TEXT-VIDEO-SOUND-IMAGE) | min 1, max 1
> ____________________________________________________________
>
> which is now a property of ens:ProvidedCHO
>
> How to proceed with physical objects coming with more than one "digital
> representation", and more than one type of resource ( images, audio and
> video ) ?
>
> I know this element just moved from ens:Aggregation, following comments by
> Go, but I would expect to see it as a property of ens:WebResource ?
>
> Best,
>
> Rodolphe
>
>
>
> -----Message d'origine-----
> De : Discussion list for Europeana WP3 participants
> [mailto:[log in to unmask]] De la part de
> Antoine Isaac
> Envoyé : mercredi 6 avril 2011 11:26
> À : [log in to unmask]
> Objet : Re: Separating between provider's focus and Europeana focus for EDM
> ingestion
>
> PS: note that in attempt for making stuff more practical for providers, and
> also to prepare for XML schema and object models where types have to be
> given to all resources, we've assigned a new "ens:ProvidedObject" type to
> the "central node" in the EDM "triangle".
> As mentioned last week, we can't be sure that ens:PhysicalThing can apply to
> every case (especially for the cases where the physical nature of the object
> would be debatable). So we have to come with something that just captures
> the *function*.
> It does not change much to the graph structure--it's just a matter of adding
> an additional type. But it should be added to the next EDM version, if
> that's alright.
>
> Antoine
>
>
>
>> Dear all,
>>
>> A follow-up on the discussions we had last week, in the work we're doing
> at the Office trying to populate EDM templates.
>> The basic idea is to make the work easier for providers who don't have to
> manage the data provenance requirements that Europeana has to meet. For such
> providers, all descriptive metadata on objects comes from their space, and
> hence they don't need proxies.
>>
>> http://europeanalabs.eu/wiki/EDMXMLSchema thus now gives access to two
> pages:
>> - http://europeanalabs.eu/wiki/EDMObjectTemplatesProviders
>> - http://europeanalabs.eu/wiki/EDMObjectTemplatesEuropeana
>>
>> Feedback welcome!
>> In the same line, in the next week we would work on making the Primer
> reflect that, as Herbert suggested. Mostly, streamlining most of the
> examples and making proxies disappear from the beginning of the document...
>>
>> Best,
>>
>> Antoine
>>
>>
>>> Hi everyone,
>>>
>>> I will mention it at the meeting in Vienna next week, but in case some of
> you are interested in more details, here are links to recent progresses made
> at the Office for the Danube programme (beyond the ESE-EDM stuff for linked
> data that I've circulated last week):
>>>
>> [...]
>>> - identification by the Operations team of properties that apply to the
> different main EDM classes, so as to prepare programming work by our
> technical team (and which can be used for XML schema creation). This is
> based on the EDM specs you know already--notably formal and informal domain
> and ranges assignments.
>>> It also tries to fill some gaps re. the contextual entity classes for
> which little "profiling information" came out of our work in WP3. The aim is
> clearly not to be exhaustive. Rather, we cherry-picked elements from
> available ontologies, so that Europeana can later ingest (and exploit) a
> "core" for each of these types.
>>> See http://europeanalabs.eu/wiki/EDMXMLSchema
>>>
>>> Best,
>>>
>>> Antoine
>>>