Skip to content
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

Works that are not Musical #14

Open
pasqLisena opened this issue Jun 28, 2018 · 11 comments
Open

Works that are not Musical #14

pasqLisena opened this issue Jun 28, 2018 · 11 comments

Comments

@pasqLisena
Copy link
Contributor

Création de nouvelles oeuvres (F14-F28-F22) selon certaines professions d’auteur

(colonne R : F28 Nouvelle expression)

  • F22 P165i is incorporated in F25 (component lié à M42)
  • F22 R66i had a performed version through) F31
  • F22 R9 realizes F14 Individual Work
    - U94 has work type M61 Work Type (ou raccourci F22 Uxx realizes work of type M61 Work Type)
  • F28 P9 consists of E7 Activity
    • P14 carried out by E21 Person
    • U31 had function of type M31 Actor’s Function

WAITING FOR en attente référentiel des Work Type

-- issue by Martine

@pasqLisena
Copy link
Contributor Author

This means that in all projects (query, converters, visualisers) the query:

SELECT * WHERE { 
?s a efrbroo:F22_Self-Contained_Expression
} LIMIT 100

will no more return musical works but all kind of work!

This means that it should be changed to:

SELECT * WHERE { 
?s a efrbroo:F22_Self-Contained_Expression;
    mus:U94_has_work_type "musical work"
} LIMIT 100

STRONGLY DISCOURAGED

@rtroncy
Copy link

rtroncy commented Jun 28, 2018

When has this mus:U94_has_work_type property been introduced? For what purpose? I would definitively discuss this during the next meeting in Paris

@pasqLisena
Copy link
Contributor Author

For what purpose?

For distinguishing between "musical work", "scenography", "costumes", ...

@pasqLisena pasqLisena mentioned this issue Jun 29, 2018
@pierrechoffe
Copy link

How does data.bnf.fr deal with this problem?

@pasqLisena
Copy link
Contributor Author

pasqLisena commented Jun 29, 2018

With bnf-onto:subject

<http://data.bnf.fr/ark:/12148/cb13916483d#about> a frbr:Work ;
    rdfs:label "L'Orfeo. SV 318" ;
    bnf-onto:firstYear 1607 ;
    bnf-onto:subject "Musique" ;
    dcterms:contributor <http://data.bnf.fr/ark:/12148/cb11925667d#about> ;
    dcterms:creator <http://data.bnf.fr/ark:/12148/cb13897646g#about> ;
    dcterms:date "1607" ;
    dcterms:description "\"Favola in musica\" en un prologue et 5 actes. - 1re représentation : Mantoue, Palazzo ducale, 24 février 1607"@fr ;
    dcterms:language <http://id.loc.gov/vocabulary/iso639-2/ita> ;
    dcterms:subject <http://dewey.info/class/780/> ;
    dcterms:title "L'Orfeo. SV 318"@it ;
    mo:genre <http://data.bnf.fr/vocabulary/musical-genre/op> ;
    rdagroup1elements:dateOfWork <http://data.bnf.fr/date/1607/> ;
    ore:isAggregatedBy <http://data.bnf.fr/ark:/12148/cb14556567q#about> ;
    = <http://data.bnf.fr/ark:/12148/cb13916483d#frbr:Work> ;
    foaf:depiction <http://gallica.bnf.fr/ark:/12148/bpt6k127515c.thumbnail>,
        <http://gallica.bnf.fr/ark:/12148/bpt6k1275305.thumbnail>,
        <http://gallica.bnf.fr/ark:/12148/bpt6k8803881p.thumbnail>,
        <http://gallica.bnf.fr/ark:/12148/bpt6k8836681r.thumbnail>,
        <https://upload.wikimedia.org/wikipedia/commons/f/f2/Frontispiece_of_L'Orfeo.jpg> .

<http://data.bnf.fr/ark:/12148/cb123129155#about> a frbr:Work ;
    rdfs:label "Le avventure di Pinocchio" ;
    bnf-onto:firstYear 1883 ;
    bnf-onto:subject "Littératures" ;
    dcterms:creator <http://data.bnf.fr/ark:/12148/cb118973660#about> ;
    dcterms:date "1883" ;
    dcterms:description "Conte pour enfants, publ. d'abord en feuilleton en 1878, puis en vol. en 1883"@fr ;
    dcterms:language <http://id.loc.gov/vocabulary/iso639-2/ita> ;
    dcterms:subject <http://dewey.info/class/800/> ;
    dcterms:title "Le avventure di Pinocchio"@it ;
    rdagroup1elements:dateOfWork <http://data.bnf.fr/date/1883/> ;
    = <http://data.bnf.fr/ark:/12148/cb123129155#frbr:Work> ;
    foaf:depiction <https://upload.wikimedia.org/wikipedia/commons/6/65/Pinocchio.jpg> .

Anyway, my issue, more than about the choice, is about the change. All past queries (for us and for everyone that is using our data) would return messy things.

@rtroncy
Copy link

rtroncy commented Jun 29, 2018

Indeed. I would vote against such a change. One work-around is to use sub-types of F22 so that we can still get all possible work (backward compatibility) but we could make more specialized queries to retrieve certain type of work. This amounts to convert the Work Type vocabulary into new DOREMUS classes. However, this will break some generic aspects of the modeling pattern of DOREMUS

@pierrechoffe
Copy link

You mean something like Fxx S-C Musical Expression, Fyy S-C Choreographic Expression, Fzz S-C Literary Expression, all sub-types of F22 Self-Contained Expression ?

@rtroncy
Copy link

rtroncy commented Jun 29, 2018

Yes, this would be the idea, but we have to weight whether this is really worth it or not. We will discuss this during the next July general assembly in Radio France

@rtroncy
Copy link

rtroncy commented Jul 9, 2018

Alternative proposal: we would use the pattern with mus:U94_has_work_type for all Works that are not of type "musical work"

Hence, the query:

SELECT * WHERE { 
?s a efrbroo:F22_Self-Contained_Expression;
    mus:U94_has_work_type "scenography"
} LIMIT 100

would return this type of works. However, the Musical Works will not have the property mus:U94_has_work_type

@pierrechoffe
Copy link

But then querying F22 would also return scenography, unless you specify « and not scenography ». Plus, it is more error prone: it is easier to forget a type than to mistakenly use one class for another, isn’t it ? I would vote for your first proposal 😉

@rtroncy
Copy link

rtroncy commented Jul 9, 2018

Correct, this is a trade off. F22 would be the type of any work, the musical ones but also of other types. However, those other type of works will typically not have values for the properties associated with musical works, so they will not be retrieved in a typical SPARQL query where one of those properties is not marked as optional. It will be possible to filter the non-musical work using the mus:94_has_work_type property. The rationale for this second solution is that this is a much cleaner solution with respect to the model which does not invalidate the current data on which depends a large number of applications, pedagogical material, examples, tutorials, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants