dpla:SourceResource / edm:ProvidedCHO

[azaroth42]

dpla:SourceResource is:

the described resources (in EDM called "cultural heritage objects") about which DPLA collects descriptions

edm:ProvidedCHO (the superClass of dpla:SourceResource) is:

the Cultural Heritage objects that Europeana collects descriptions about

As every dpla:SourceResource is also a edm:ProvidedCHO, that implies that every dpla:SourceResource is a resource about which Europeana collects descriptions. If we use SourceResource in HyBox, it implies that both Europeana and DPLA collect descriptions about HyBox objects.

Clearly, none of this is even remotely true :( So ... can the definitions of the classes be changed, do we simply not care, or do we find a new class for the non repository object descriptions?

[azaroth42]

Thoughts @anarchivist @no-reply @aisaac ? Others?

[aisaac]

Sorry I really have no time for this before the end of the week, I'm in meetings...

[anarchivist]

@azaroth42 Just for the record, @no-reply's out for another week and a half, so here's a not so gentle nudge since I know we're short on your time...

As every dpla:SourceResource is also a edm:ProvidedCHO, that implies that every dpla:SourceResource is a resource about which Europeana collects descriptions. If we use SourceResource in HyBox, it implies that both Europeana and DPLA collect descriptions about HyBox objects.

I think it's a rather loose implication (since this just happens as a skos:definition), but I see your point.

So ... can the definitions of the classes be changed [...]

👌 From DPLA's perspective on dpla:SourceResource, sure. For Europeana's perspective on edm:ProvidedCHO, I'd defer to @aisaac and @vcharles89.

... do we simply not care ...

👍 That's probably where I'm at at the moment. Formally speaking, the definition isn't overly strict.

... or do we find a new class for the non repository object descriptions?

👎

[no-reply]

I'm generally in the "don't care" camp.

If the feeling on the EDM side is that ProvidedCHO is really "the class of things which Europeans has descriptions of, we would need to change the Source Resource definition anyway.

I'll think a bit about DPLA's position on what a "Source Resource" is, exactly, but I think it's safe to say it will be loose enough that a hybox/pcdm object may be one without any action on DPLA's (or Europeana's) part.

[aisaac]

[I know we're short on your time...] -> OK, now that I'm not sleeping and I don't have to fire an answer first. edm:ProvidedCHO was probably really the class of things Europeana gathers data about. That said, we can maybe change the description to 'This class includes the Cultural Heritage objects that Europeana collects descriptions about'. Then you can fit other things in it without worrying. And honestly for a non-native speaker like me 'comprise' was already ambiguous. Actually the knowledge that an object is 'collected' by Europeana could be also infered from the fact that ProvidedCHO are aggregated in a (Europeana) Aggregation, making what the definition says not so important. That said I think we're never used this to infer anything. Basically it's the fact that a ProvidedCHO is described in our database that makes it 'collected' in Europeana. @vcharles89 @hugomanguinhas do you feel there would be a problem?

[azaroth42]

Can we just change the definition to "A Cultural Heritage Object" and call it a day? :) The inclusion in a Europeana aggregation seems like the best way to know that Europeana cares about it.

[anarchivist]

@aisaac said:

edm:ProvidedCHO was probably really the class of things Europeana gathers data about. That said, we can maybe change the description to 'This class includes the Cultural Heritage objects that Europeana collects descriptions about'. Then you can fit other things in it without worrying. And honestly for a non-native speaker like me 'comprise' was already a

and then @azaroth42 replied:

Can we just change the definition to "A Cultural Heritage Object" and call it a day? :) The inclusion in a Europeana aggregation seems like the best way to know that Europeana cares about it.

👍 on both from me.

@aisaac said:

That said I think we're never used this to infer anything. Basically it's the fact that a ProvidedCHO is described in our database that makes it 'collected' in Europeana.

This is the same for DPLA, and I can tell you we've never inferred anything from whether something was typed as a dpla:SourceResource.

[aisaac]

I think I would prefer a change that is as discrete as possible. A diff of one word that was not super clear would seem less dangerous to me. Especially as @vcharles89 is updating the EDM definition this week and we can't include more significant stuff in.

[anarchivist]

@aisaac OK - understood, I think I'd be fine with such a change, which would be along the lines of what you propose:

This class includes the Cultural Heritage objects that Europeana collects descriptions about.

[vcharles89]

I also prefer to have a minimal change of the edm:ProvidedCHO, especially because a more important change might trigger discussions in our network that we couldn't handle at the moment as we are updating our documentation. We will publish a new version of the EDM Definitions next week that will include this light change.

[anarchivist]

@vcharles89 Thanks, Valentine!

@azaroth42 Are we squared away on this?

[azaroth42]

Sure :)

[hugomanguinhas]

Hi all,

Sorry for jumping in so late in the thread... and just wanted to say that looking at the machine-interpretable definitions (XSD and OWL) that we are also good, meaning that there is no issue on using EDM outside the Europeana context. Only the EDM Internal XSD have Europeana specific classes (edm:EuropeanaAggregation) and properties (edm:europeanaProxy) with the corresponding restrictions but I assume these are alright as it is meant for Europeana internal use.

It might be relevant though to loosen the restriction on our OWL file between the ore:Aggregation and the edm:ProvidedCHO since at the moment it is necessary that the CHO is connected to an Aggregation by the edm:aggregatedCHO so that it can be used in non-aggregation contexts... but this may only be a problem in a close world environment.

Best regards, Hugo

[anarchivist]

Thanks @hugomanguinhas!

[aisaac]

@hugomanguinhas thanks for the check! +1 for loosening the restriction from our OWL files.