search

DOREMUS-ANR / knowledge-base

Repository containing controlled vocabularies and data published by DOREMUS
http://data.doremus.org/
Apache License 2.0
16 stars 7 forks source link

[Function] Move parts from IAML MoP vocabulary #44

Open pasqLisena opened 6 years ago

pasqLisena commented 6 years ago

Parts of IAML MoP vocabulary describe indeed functions:

Most of them are already in the function vocabulary (table), so I suppose that the modelling group already spotted this. Anyway we should put an effort for mantaining all the languages and notes.

Roadmap

We can avoid to keep that skos:editorialNote "English term is preferred globally." that is repeated for each concept. While is useful for instrument (see traditional ones), it is weird for functions.

Related comment:

ccecconi commented 6 years ago

Make sure that all the concepts in MoP are in Function

We chose to keep only the terms that could be used in our data --> IAML is a different vocabulary. Why should we keep the same functions ?

Add a column in the table for the other languages and move them

ok. We'll do that

Add a column in the table for the skos:exactMatch

ok. We'll do that

Remove the concept from MOP"

what do you want to say here ? We'll never use these terms as MOPs in our data but they are part of the IAML vocabulary. Do we really have to remove them ? In that case, what's the point of linking them with our functions ?

"Chef éclairagiste" / "éclairagiste"

The term in our vocabulary is more generic and contains the two terms of IAML

We can avoid to keep that skos:editorialNote "English term is preferred globally."

OK

pasqLisena commented 6 years ago

I will refer here to "MoPs that are actually functions" as "bad MoPs".

We chose to keep only the terms that could be used in our data --> IAML is a different vocabulary. Why should we keep the same functions ?

Not clear the question to me, but I interpret it as "The function vocabulary is autonomous, it follows different rules. So it is normal that some bad MoPs do not appears as function".

This is fair enough BUT there is a practical issue: what will happen to concepts used so far as bad MoPs that have not a correspondance in functions?

Stupid example. Suppose that you decide about not transferring the conductor to function. Should we continuing declaring it in real data as MoP?

Remove the concept from MOP

what do you want to say here ? We'll never use these terms as MOPs in our data ...

Consider that BnF normally refers with codes to that vocabulary. Normally for casting, but what about BIB records?

... but they are part of the IAML vocabulary.

Our IAML vocabulary is not an "hard copy" of the IFLA official one. It is an export that we autonomously generated from our sources (tables, online resources) and we have the full control on it (infact we use OUR namespace http://data.doremus.org/something). The 2 vocabularies (IFLA one and our one) are not the same (our one is more rich ✌️ ). ("Hard copy" is how we imported MIMO, Rameau, we use them "as is", without any improvement from our side)

SO, if we consider them bad MoPs, we should remove them from MoPs (on my opinion).

In that case, what's the point of linking them with our functions ?

I was not speaking about an interconnection between DOREMUS-IAML-MOP and DOREMUS-FUNCTION, but between IFLA-MOP and DOREMUS-FUNCTION. We link them with IFLA one anyway (interconnection is always good).

"Chef éclairagiste" / "éclairagiste"

The term in our vocabulary is more generic and contains the two terms of IAML

Good. I suppose that the labels in other languages of éclairagiste will be transferred to the function vocabulary. What about the labels of Chef éclairagiste? Should them be transferred as altLabel?

ccecconi commented 6 years ago

Consider that BnF normally refers with codes to that vocabulary. Normally for casting, but what about BIB records?

The BnF doesn't use these codes in the bibliographic records.

SO, if we consider them bad MoPs, we should remove them from MoPs (on my opinion).

We agree. We should remove :

What about the labels of Chef éclairagiste? Should they be transferred as altLabel?

No