{"action":"created","issue":{"url":"https://api.github.com/repos/PghFrankenstein/Pittsburgh_Frankenstein/issues/57","repository_url":"https://api.github.com/repos/PghFrankenstein/Pittsburgh_Frankenstein","labels_url":"https://api.github.com/repos/PghFrankenstein/Pittsburgh_Frankenstein/issues/57/labels{/name}","comments_url":"https://api.github.com/repos/PghFrankenstein/Pittsburgh_Frankenstein/issues/57/comments","events_url":"https://api.github.com/repos/PghFrankenstein/Pittsburgh_Frankenstein/issues/57/events","html_url":"https://github.com/PghFrankenstein/Pittsburgh_Frankenstein/issues/57","id":343406156,"node_id":"MDU6SXNzdWUzNDM0MDYxNTY=","number":57,"title":"S-GA line location @n on resequenced surfaces","user":{"login":"ebeshero","id":4014518,"node_id":"MDQ6VXNlcjQwMTQ1MTg=","avatar_url":"https://avatars3.githubusercontent.com/u/4014518?v=4","gravatar_id":"","url":"https://api.github.com/users/ebeshero","html_url":"https://github.com/ebeshero","followers_url":"https://api.github.com/users/ebeshero/followers","following_url":"https://api.github.com/users/ebeshero/following{/other_user}","gists_url":"https://api.github.com/users/ebeshero/gists{/gist_id}","starred_url":"https://api.github.com/users/ebeshero/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ebeshero/subscriptions","organizations_url":"https://api.github.com/users/ebeshero/orgs","repos_url":"https://api.github.com/users/ebeshero/repos","events_url":"https://api.github.com/users/ebeshero/events{/privacy}","received_events_url":"https://api.github.com/users/ebeshero/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":{"login":"raffazizzi","id":144770,"node_id":"MDQ6VXNlcjE0NDc3MA==","avatar_url":"https://avatars1.githubusercontent.com/u/144770?v=4","gravatar_id":"","url":"https://api.github.com/users/raffazizzi","html_url":"https://github.com/raffazizzi","followers_url":"https://api.github.com/users/raffazizzi/followers","following_url":"https://api.github.com/users/raffazizzi/following{/other_user}","gists_url":"https://api.github.com/users/raffazizzi/gists{/gist_id}","starred_url":"https://api.github.com/users/raffazizzi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/raffazizzi/subscriptions","organizations_url":"https://api.github.com/users/raffazizzi/orgs","repos_url":"https://api.github.com/users/raffazizzi/repos","events_url":"https://api.github.com/users/raffazizzi/events{/privacy}","received_events_url":"https://api.github.com/users/raffazizzi/received_events","type":"User","site_admin":false},"assignees":[{"login":"raffazizzi","id":144770,"node_id":"MDQ6VXNlcjE0NDc3MA==","avatar_url":"https://avatars1.githubusercontent.com/u/144770?v=4","gravatar_id":"","url":"https://api.github.com/users/raffazizzi","html_url":"https://github.com/raffazizzi","followers_url":"https://api.github.com/users/raffazizzi/followers","following_url":"https://api.github.com/users/raffazizzi/following{/other_user}","gists_url":"https://api.github.com/users/raffazizzi/gists{/gist_id}","starred_url":"https://api.github.com/users/raffazizzi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/raffazizzi/subscriptions","organizations_url":"https://api.github.com/users/raffazizzi/orgs","repos_url":"https://api.github.com/users/raffazizzi/repos","events_url":"https://api.github.com/users/raffazizzi/events{/privacy}","received_events_url":"https://api.github.com/users/raffazizzi/received_events","type":"User","site_admin":false},{"login":"ebeshero","id":4014518,"node_id":"MDQ6VXNlcjQwMTQ1MTg=","avatar_url":"https://avatars3.githubusercontent.com/u/4014518?v=4","gravatar_id":"","url":"https://api.github.com/users/ebeshero","html_url":"https://github.com/ebeshero","followers_url":"https://api.github.com/users/ebeshero/followers","following_url":"https://api.github.com/users/ebeshero/following{/other_user}","gists_url":"https://api.github.com/users/ebeshero/gists{/gist_id}","starred_url":"https://api.github.com/users/ebeshero/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ebeshero/subscriptions","organizations_url":"https://api.github.com/users/ebeshero/orgs","repos_url":"https://api.github.com/users/ebeshero/repos","events_url":"https://api.github.com/users/ebeshero/events{/privacy}","received_events_url":"https://api.github.com/users/ebeshero/received_events","type":"User","site_admin":false}],"milestone":null,"comments":0,"created_at":"2018-07-22T13:30:15Z","updated_at":"2018-07-22T13:38:59Z","closed_at":null,"author_association":"COLLABORATOR","body":"@raffazizzi I just noticed something I think we've not been doing right with the line locations (`@n` attributes) for some of the S-GA files. Do you remember how in S-GA c-56, there's a long early deletion and resequencing marked in the ms? See http://shelleygodwinarchive.org/sc/oxford/frankenstein/volume/i/#/p3/mode/xml\r\n\r\nBack in October 2017, we carefully worked out how the text was marked to \"flow\" in reading order in our file here: \r\n[collateXPrep/sga_Notebooks/msCollPrep_c56.xml](https://github.com/PghFrankenstein/Pittsburgh_Frankenstein/blob/Text_Processing/collateXPrep/sga_Notebooks/msCollPrep_c56.xml)\r\n\r\nThis affects three `<surface>` elements which are effectively split into two parts each by our pre-collation resequencing. So we have two sets of `<surface>` elements sharing the same `@xml:id` for `ox-ms_abinger_c56-0013`, `ox-ms_abinger_c56-0009`, and `ox-ms_abinger_c56-0015`\r\n\r\nFor whatever reason, I opted not to change these `@xml:id`s to indicate something like Part-1-of-2, but I don't remember why I never changed them.  We may have chosen to live with duplicate `@xml:ids` on these doubled `<surface>` elements because they do literally point back to the correct file, AND because during the collation process we \"drop out\" the `<surface>` elements. They don't show up at all in the `<app><rdg wit=\"msColl\">....</rdg></app>` output, and in their place, we have the `@n` on each `<lb/>` identifying the surface and line position.\r\n\r\nCurrently we derive our `@n` attributes for each `<lb/>` from each `surface/@xml:id` and a simple count of the line children inside. Does this cause a problem as we're looking at generating pointers and relying for help on the `@n` attributes to help locate the position on the file? It *might not* because we also set `<gap>` elements to indicate when lines or character tokens follow after any kind of displacement. Here's an example from c56-0013:\r\n\r\n```\r\n<gap reason=\"resequencing\" unit=\"lines\" quantity=\"28\"/>\r\n```\r\nWe also have other kinds of `<gap>` elements to mark character displacement, and I am pretty sure you're looking for these to help construct your pointers. My question is, in the case of lines, shouldn't I be calculating a line number from these three surfaces (c56 0013, 0009, 0015) based on the gap information? \r\n\r\nIn case you're already doing that and I'd better not, let me know. But I don't see that it could hurt and since we've only been seriously testing one or two collation units at a time for constructing pointers until now, I think this is one of those big picture questions for stitching together the full collation of the novel!  Let me know what you think. For right now I'm going to \r\na) leave those `<surface>` elements alone rather than add to their `@xml:ids`--that is, live with their invalidity in `msCollPrep_c56.xml`, and \r\nb) try correctly calculating the line numbers when they come from split surfaces (if there's a gap with`@unit=\"line\"` add the value in `@quantity` to the line-count that appears in `@n`). \r\nThis is sort of revisiting the issue of an old ticket here: [#41])(#41 ) "},"comment":{"url":"https://api.github.com/repos/PghFrankenstein/Pittsburgh_Frankenstein/issues/comments/406867415","html_url":"https://github.com/PghFrankenstein/Pittsburgh_Frankenstein/issues/57#issuecomment-406867415","issue_url":"https://api.github.com/repos/PghFrankenstein/Pittsburgh_Frankenstein/issues/57","id":406867415,"node_id":"MDEyOklzc3VlQ29tbWVudDQwNjg2NzQxNQ==","user":{"login":"ebeshero","id":4014518,"node_id":"MDQ6VXNlcjQwMTQ1MTg=","avatar_url":"https://avatars3.githubusercontent.com/u/4014518?v=4","gravatar_id":"","url":"https://api.github.com/users/ebeshero","html_url":"https://github.com/ebeshero","followers_url":"https://api.github.com/users/ebeshero/followers","following_url":"https://api.github.com/users/ebeshero/following{/other_user}","gists_url":"https://api.github.com/users/ebeshero/gists{/gist_id}","starred_url":"https://api.github.com/users/ebeshero/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ebeshero/subscriptions","organizations_url":"https://api.github.com/users/ebeshero/orgs","repos_url":"https://api.github.com/users/ebeshero/repos","events_url":"https://api.github.com/users/ebeshero/events{/privacy}","received_events_url":"https://api.github.com/users/ebeshero/received_events","type":"User","site_admin":false},"created_at":"2018-07-22T13:38:59Z","updated_at":"2018-07-22T13:38:59Z","author_association":"COLLABORATOR","body":"@raffazizzi Rethinking this, since one of my goals is to clean up the repo and write clear documentation of what we're doing--a problem with the doubled `@xml:id`s is simply that they generate confusion later. Likely we'll have some help with adding/correcting `<w>` (word boundary) markup in these `msCollPrep` files in the coming months, and people coming on board to help with our project are likely to get confused! I think it's a small thing to add some kind of indicator that these three surfaces are cut parts of a whole, and in generating the `@n` values for the `<lb/>` elements, just get the substring before the new indicator... "}}
{"actor":{"display_login":"ebeshero"}}