Closed jonathanrobie closed 3 years ago
This seems like it would create a lot of overhead for consumers of SB (i.e. they would be required to adopt whatever identification scheme the "owner" chose). I also don't understand why DBL needs to know the latest revision for a translation project. The user who uploads the SB to DBL should know that information.
I don't think DBL needs to know how to find the latest revision, I do think it needs to know who to ask for the latest revision, which means it needs to know which project repository owns the project and has the latest version. Once it knows that, the rest can be negotiated.
I could be wrong, of course. What am I missing?
On Thu, Jul 30, 2020 at 11:21 AM Tim Steenwyk notifications@github.com wrote:
This seems like it would create a lot of overhead for consumers of SB (i.e. they would be required to adopt whatever identification scheme the "owner" chose). I also don't understand why DBL needs to know the latest revision for a translation project. The user who uploads the SB to DBL should know that information.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/209#issuecomment-666450157, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPTPP752EGIYO2IM2HYE3R6GFY3ANCNFSM4PN5LMVA .
Why would it need to know who to ask if it doesn't need to ask? What am I missing?
A publisher who uses DBL wants to know if there is a newer version of the text for a DBL resource or wants to know why a change was made, etc.
The publisher contacts a DBL administrator. This administrator also has access to the project in Paratext or some other environment. The DBL resource should have sufficient information to let the administrator move to the Paratext environment or talk to someone who uses that environment and understand where to find the equivalent state of the project.
This basically amounts to being able to display identifying information in DBL so that the administrator knows where to find things.
Related to #222 #75 #210
I think this works now that the creating system provides the identifier and revision. As long as we define identification and integrity constraints correctly.
On Thu, Nov 5, 2020 at 12:02 PM Jesse Griffin notifications@github.com wrote:
Related to #222 https://github.com/bible-technology/scripture-burrito/issues/222 #75 https://github.com/bible-technology/scripture-burrito/issues/75 #210 https://github.com/bible-technology/scripture-burrito/issues/210
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/209#issuecomment-722507514, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPTPLTH2AYFEYL4CJDQITSOLLCTANCNFSM4PN5LMVA .
OK, safe to close then @jonathanrobie ?
Before we close this, I think we need to define identification and integrity constraints in the specification.
On Fri, Nov 13, 2020 at 10:24 AM Jesse Griffin notifications@github.com wrote:
OK, safe to close then @jonathanrobie https://github.com/jonathanrobie ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bible-technology/scripture-burrito/issues/209#issuecomment-726825796, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANPTPKDI6MPX475VNATHYLSPVFT3ANCNFSM4PN5LMVA .
Discussion around #208 and #227 have revealed that this use case is accounted for.
A resource server like DBL needs a way to identify the owner and latest revision for a translation project. If several different translation editors are being used, on several machines, and the result is stored in more than one place, it still needs to know where to find the current authoritative source for any given project.
Possible solution:
This would require extending the SB metadata.