-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Function] Move parts from IAML MoP vocabulary #44
Comments
We chose to keep only the terms that could be used in our data --> IAML is a different vocabulary.
ok. We'll do that
ok. We'll do that
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 ?
The term in our vocabulary is more generic and contains the two terms of IAML
OK |
I will refer here to "MoPs that are actually functions" as "bad MoPs".
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: Stupid example. Suppose that you decide about not transferring the
Consider that BnF normally refers with codes to that vocabulary. Normally for casting, but what about BIB records?
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 SO, if we consider them bad MoPs, we should remove them from MoPs (on my opinion).
I was not speaking about an interconnection between DOREMUS-IAML-MOP and DOREMUS-FUNCTION, but between IFLA-MOP and DOREMUS-FUNCTION.
Good. I suppose that the labels in other languages of |
The BnF doesn't use these codes in the bibliographic records.
We agree. We should remove :
No |
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
skos:exactMatch
and move themWe 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:
eclairagiste@fr
chef eclairagiste@fr
andeclairagiste@fr
The text was updated successfully, but these errors were encountered: