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

Syntax of referring to DHARMA inscriptions #323

Closed
danbalogh opened this issue Jun 26, 2024 · 6 comments
Closed

Syntax of referring to DHARMA inscriptions #323

danbalogh opened this issue Jun 26, 2024 · 6 comments
Assignees

Comments

@danbalogh
Copy link
Collaborator

I notice that the reference <ref n="tfb-badamicalukya-epigraphy" target="DHARMA_INSBadamiCalukya00007.xml">Lohaner plates of Pulakeśin II</ref> (from the Vengi corpus pointing to the Badami corpus) is now flagged as an error by the schema, even though it follows exactly the instruction of EGD §10.4.6. I've already noted for the EGD revision that the use of @n to point to another repository will no longer be necessary - but did we ever agree that it would actually be forbidden? If we did, or if we agree so now, then existing @n attributes on <ref> elements should be batch removed from the entire corpus (I don't think there are any legitimate uses for which we'd want to preserve them).

While we're at it, we should also agree on the format of referring to such editions: should the target be

  • DHARMA_INSBadamiCalukya00007.xml; or
  • DHARMA_INSBadamiCalukya00007; or
  • BadamiCalukya00007?

Either of these is acceptable to me. The EGD at present says it should be "the filename", which I would believe includes the extension, but the relevant section was written before the FNC was done, and the text also mentions "identifier" and uses inconsistent examples. To sort that out for the new edition, I would prefer to have one and only one of the above. Existing references will again have to be batch-replaced if we choose anything other than the first.

@michaelnmmeyer
Copy link
Member

For the use of @n, let us forbid it. I will update files accordingly.

For @target, people almost always use the form DHARMA_INSBadamiCalukya00007.xml, and Oxygen suggests URIs of this form, so it would be weird not to allow it. That said, @target is made to point to INSBadamiCalukya00007 on the website, so it would also be weird not to allow this last form. I also imagine that people will want to refer to things other than texts on the website (a repository or a person, for instance), for which they would have to use URIs like /people/argr, https://mywebsite.com, etc.

So, I would suggest the guide only prescribes the form DHARMA_INSBadamiCalukya00007.xml, but explains that this reference will be transformed to INSBadamiCalukya00007 = /texts/INSBadamiCalukya00007 = https://dharmalekha.info/texts/INSBadamiCalukya00007.

@danbalogh
Copy link
Collaborator Author

Thanks, this sounds OK to me. But before doing a batch replace, let's wait on an OK from @arlogriffiths .
The new EGD draft already includes provisions for references along the lines of https://mywebsite.com.
I think it would be best not to use relative URLs such as /people/argr in our editions.

@arlogriffiths
Copy link
Collaborator

I agree with forbidding use of @n in this context. I also agree that it should be the full filename (model DHARMA_INSBadamiCalukya00007.xml) that is used as value of @target, for the simple reason that this is how my team has been encoding (at least I myself have).

Since I don't think many people will really ask themselves why an inscription referred to as DHARMA_INSBadamiCalukya00007.xml has a URL https://dharmalekha.info/texts/INSBadamiCalukya00007 on our website, I am not sure further explanation is necessary, though I don't object to it either.

I don't sufficiently understand the issue of URIs /people/argr vs https://mywebsite.com so I am happy to let both of you sort this out.

@danbalogh
Copy link
Collaborator Author

Thanks, Arlo.
@michaelnmmeyer , this means you can go ahead with batch deleting existing instances of @n (not urgent, but since it's now flagged as an error, better sooner than later). You can close this thread when done, unless you would like to urge me to add provision to the EGD for references like /people/argr. As far as I'm aware, there has been no demand for this so far, so I would rather continue living without it.

@michaelnmmeyer
Copy link
Member

Done.

@danbalogh
Copy link
Collaborator Author

Thanks. I've added a comment in the online EGD to let people know it should no longer be used.

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

No branches or pull requests

3 participants