ccronje
commented
3 years ago Perhaps we could investigate restructuring and representing publication metadata as schema.org JSON-LD?
- using types Collection, Book, Chapter to define relationships between texts (hasPart, isPartOf, translationOfWork)
- identify translators in Book and Chapter properties (translator, inLanguage)
- describe translators using Person type
Once indexed in SC, would this enable an end user to search for e.g. a Book, translated inLanguage, by translator >> (potentially down the track) export in X format with dynamic metapublication JSON-LD stub?
gnlaera
firepick1
sujato
what we have
When setting up Bilara, I was cognizant of the fact that people often work together. Indeed, my earliest translations on the site are a collaboration with Jessica Walter. So from the beginning I wanted to provide a way for teams to work together, and define this in publication.json. However I am wondering whether this was a mistake.
the problem
The basic problem is that teams are fluid and hard to define. People come and go. Those who say they'll do a job don't do it, while those who say that are not doing much end up doing all the work. It's especially aggravated online, where team members frequently don't know each other outside of the team. I can see this being an ongoing administrative headache.
another way?
Instead of having teams, every publication is defined as an individual, and every person works separately on Bilara. That is the default process anyway. It aligns neatly with the simple fact that Github permissions are per-person.
What happens when more than one person is working? Well, we have (or will have!) two distinct roles: translator and proofreader. Let's say that Gabriel and Marco are working on Portuguese translations together. One translates a sutta, the other proofs it. They coordinate among themselves as to who is translating what, to avoid duplication. They frequently share passages and phrasing, and this is noted in the relevant publication description field.
Now, when it comes time to publish, this is not an issue as far as Suttacentral is concerned. Gabriel publishes his suttas, Marco publishes his, and they each appear on the site under their own name. The metadata field informs the user of the collaborative process. No worries!
But what if they want to make it a book? Let's publish
mnwith some translations from Gabriel and some from Marco! Well, then we introduce a meta-publication. It's defined as a "publication that includes other publications". We add both their publication projects to the meta-publication, which would include any necessary additional information (for example an ISBN number).Essentially it's the same thing as a collaboration, except that:
This way we don't have to anticipate the course that a translation will take. We don't have to force a particular working method or priority on teams. Let each translator take care of their work, help each other, and when appropriate, decide on a collaborative publication later.
It would also allow us to define certain other kinds of publications that are not so far catered for. For example, what about bilingual publications? What if someone wants to make an EPUB with Pali and Italian? Or with English and Thai (for example, for education purposes)? Technically, this is trivial with Bilara i/o, but we have no way of describing it in publication.json.
Such cases would be handled in a separate file, call it
metapublication.json.publication.jsonwill include the basic publications, which are tied to a github sccount and a single user. It is consumed by Bilara, thus it looks both ways: back to the app and forward to the publication.metapublication.jsondefines any combination of publications inpublication.json.It is simpler in concept, as it has nothing to do with the Bilara app. It only looks forward to the output from Bilara-data. We could link it, for example, with bilara i/o. One could instruct bilara i/o "export scmetapub23 as sheet" or whatever.
limitations