schema: remodel role-specific elements in work and expression #1370
Conversation
…ements Remove membership in respLikePart for - arranger; - funder; - librettist; - lyricist; and - sponsor
This PR addresses in part PR #799
|
Why can't we continue with #799? |
|
@rettinghaus, by all means continue with PR #799. I hope you'll note my comments there -- comments which led to creation of a this PR which has the same motivation as #799 but accomplishes the goal with different means. Of course reviewers review, but a PR should not be granted an automatic approval either. |
|
Yeah, I think this duplicates the work done in #799 ... This PR removes these elements without also replacing them with something, meaning that merging this will leave MEI in a state where we remove the ability to describe a composer or an author, without also having a replacement method. I know this is only in development, but it would be good to have removals and replacement solutions together, IMO. |
|
Sorry for the confusion. The separation of this PR from #1371 is due to 2 things:
|
Ok, I understand. So, the duplication is due to workflow issues. If I analyze the situation correctly, you, @pe-ro, are using the GitHub web interface for making your modifications to the files in the The best option in case of an existing PR that wants to achieve a similar thing would be to make use of the comment and, most importantly, code-line comments (which, btw. also allow direct alternative code suggestions that could be merged into the PR after the discussion is resolved). In general, if you want to modify multiple files, the most common way would be to clone the repository to your machine, create a new branch there, and then make granular commits to that branch for every change you make, e.g., commit 1 : remove author and composer; commit 2: relax model of work, and so forth. If you want or have to use GitHub’s web interface, you could also create a branch first, then switch to that branch (instead of develop) make your changes to a single file and commit it directly to that newly created branch (each with sound granularity and change description). After you have completed all your changes for the goal you want to achieve, you can open a new pull request from your branch against develop. Consequently, there would be just one pull request, with all the changes needed to make it a sound and round code-suggestions^. Given the situation we have right now I would propose the following workflow.
This sound good? |
|
@bwbohl, sorry for not responding to this sooner. Thanks for helping me out. I think it will be easier for everyone, including me, to remove/mark-as-a-draft/whatever the pull requests I submitted earlier and for me to follow your instructions on using the GitHub interface to submit a single, comprehensive pull request. There will be a large number of revisions, but the logic will be easier to follow overall. |
|
Hey @pe-ro, thanks for coming back to this. Never mind any delays, we all are doing this with the time we can spare ;-) |
|
Sorry, now I'm more confused. Should I create a new pull request from a new branch or leave things as they are? |
|
We can just merge these PRs to other branches than develop, namely the |
|
If that's easier for you, it's fine by me. Is anything else required of me? |
|
I could just merge them |
Modify role specific elements Yes, this is an alternative to the creation of <agent>. In my opinion, the proposal to create <agent> as a replacement for the various role-specific elements places too much of a burden on the encoder to specify the nature of the agent's relationship to the bibliographic item; and doesn't help clarify that some agents are privileged in some styles of bibliographic description. Allowing some roles to be "singled out" makes it easier to transcode from existing markup like MARC and MODS. <creator> and <editor> can mark those privileged roles and other roles can go into <respStmt>. As I've said elsewhere, if treating some roles as special offends the encoder's sensibilities, then all roles can go into <respStmt> since <respStmt> retains its former children, i.e., <resp> and name-lIke elements. <creator>, <editor> and <resp> are all places where authority attributes (@auth and @auth.uri) can be used to provide pointers to standard values for the agent-to-item relationship. While the name-like elements (<name>, <persName>, and <corpName>) can use these same attributes for pointers to standardized / variant names for these entities.
|
OK, but there will be conflicts between my suggestions and those of #799. |
Modify content model of work
Modify content model of expression
|
Yeah, that's why I merged your other develo-agentX branches here. Now we have your proposal in one place and can proceed e.g. by comparing this branch to the one of #799 |
|
Got it. Thanks again. |
This PR is one of a number of replacements for PR #799