DublinCoreCatalogService should not complain about "unexpected" dublincore flavors

Steps to reproduce

Steps to reproduce:
1. Define a new extra metadata catalog by copying the attached file in the /etc folder
2. Create a new series and, in the tab "Metadata II", give the field some value
3. Upload a new recordings assigned to that series

Actual Results:
The logs are filled with warnings like:
(DublinCoreCatalogService:162) - Unexpected dublin core catalog flavor found, ignoring 'dublincore/extra'

Expected Results:
The system should simply ignore a flavor it does not know. The "dublincore/*" flavor is not documented to be reserved.

Workaround (if any):
Use a flavor in which the "type" (the first half) is not "dublincore"

Activity

Show:
Former user
August 11, 2017, 12:15 PM

Merged in uni-koeln/opencast-uni-k-ln/t/MH-12351-lower-dublincorecatalogservice-log-level (pull request #1648) at 5d0b3d3 to r/3.x

Rubén Pérez
August 9, 2017, 7:04 PM

Sorry for the delay to answer. I think you did understand the whole idea, but I will still comment here as a reference for future readers (if any! )

Let me be as concise as I can: this is not about dublincore namespaces. This is not about namespaces at all. It is also not about dublincore. This is about a class expecting certain flavors ("dublincore/episode" and "dublincore/series"), which instead looks for any element with flavor type "dublincore" and complains if the subtype is not one of those it expects. The class was patched once already, because the "dublincore/oaipmh" was causing all these annoying print statements on the logs.

So I believe this log statement should not be a warning, because having an "extra" dublincore catalog is a perfectly normal thing, and adding it to the mediapackage as "dublincore/whatever" seems just the way to go.

As an aside: it's not weird for our catalogs to have non-dublincore namespaces. In fact, the root element is "dublincore" in most of them, which is NOT dublincore term (or, at least, we do not qualify it with the dublincore namespace, but with the "matterhorn" namespace).

Former user
August 7, 2017, 12:39 PM

I think my confusion is that we add non-dublincore namespaces into a catalog containing a dublincore namespace that is primarily dublincore, therefore, mostly dublincore flavored.

Rubén Pérez
August 7, 2017, 12:38 PM

> "It might be easier to feed all available mediapackage catalogs to the email WOH. Even those, that contain non-Dublincore standard fields, such as SMIL, Person, vCard, FOF, etc. "
Indeed. But that's not the point.

> "I don't understand what other Opencast metadata requires Dublincore standard fields besides the series and episode."

This has nothing to do with the catalog content, but with the flavor assigned to the MP element containing. Apparently the "dublincore/" flavors have a special meaning to the DublinCoreCatalogService. That is (to the extent of my knowledge) not documented. Even if it was, I find it absurd. It is fine that there are certain flavors with "special handling" (namely "dublincore/episode" and "dublincore/series"). It is not so fine that these values are hard-coded and not documented anywhere. And it is (on my opinion) unnecessary annoying that the class complains when it finds elements with the "dublincore/" flavor that do not match any of there special flavors: if they do not match, simply ignore them.

Take a look at the proposed pull request. You'll see it has nothing to do with the metadata content, but with mediapackage element flavors.

Former user
August 7, 2017, 12:16 PM

I don't understand what other Opencast metadata requires Dublincore standard fields besides the series and episode.

It might be easier to feed all available mediapackage catalogs to the email WOH. Even those, that contain non-Dublincore standard fields, such as SMIL, Person, vCard, FOF, etc.

Fixed and reviewed
Your pinned fields
Click on the next to a field label to start pinning.

Assignee

Rubén Pérez

Reporter

Rubén Pérez

Severity

Usability Issue