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

Fix cyclic 'contains' relations #37

Open
digitalheir opened this issue Apr 4, 2023 · 4 comments
Open

Fix cyclic 'contains' relations #37

digitalheir opened this issue Apr 4, 2023 · 4 comments
Labels
DONE ! Has been done in a branch. The issue will be closed when the software is released

Comments

@digitalheir
Copy link

In signs_description.xml:

  • Aa18 is a denoted to contain Aa17, but also vice versa. I think it is clear that Aa17 does not include Aa18.
  • V98 is a denoted to contain V36, but also vice versa. I think it is clear that V98 does not include V36.
  • Y1 is a denoted to contain Y2, but also vice versa. I think it is clear that Y2 does not include Y1.
  • D32 is a denoted to contain D197, but also vice versa. I think it is clear that D197 does not include D32.

Additionally:

  • I64 is a variant of I12, but I would not consider them as 'containing' each other
  • Y4 is the mirror image of Y3, but I would not consider them as 'containing' each other
digitalheir added a commit to digitalheir/jsesh that referenced this issue Apr 4, 2023
Fixes first half of rosmord#37:

- Aa18 is a denoted to contain Aa17, but also vice versa. I think it is clear that Aa17 does _not_ include Aa18.
- V98 is a denoted to contain V36, but also vice versa. I think it is clear that V98 does _not_ include V36.
- Y1 is a denoted to contain Y2, but also vice versa. I think it is clear that Y2 does _not_ include Y1.
- D32 is a denoted to contain D197, but also vice versa. I think it is clear that D197 does _not_ include D32.
@rosmord
Copy link
Owner

rosmord commented Apr 4, 2023

Thanks for the comments. I have probably made too much use of the "part of" relationship at some point. I agree with you. It's fixed.

In some cases (esp. I64/I12) the idea was to use I64 as base for successive "contains" search, and retrieve all signs with an uraeus, for instance.

Now, I have also a tag for this.

(basically, the part of relationship would be improved if certain objects, which are not standalone glyphs, would be usable, notably "uraeus as part of a headress").

@rosmord rosmord added the DONE ! Has been done in a branch. The issue will be closed when the software is released label Apr 4, 2023
@rosmord rosmord closed this as completed Apr 4, 2023
@digitalheir
Copy link
Author

digitalheir commented Apr 4, 2023

Note, I haven't changed the I64 / I12, and Y4 / Y3 in the pull request, do you think these should have a different tag, like "variant of" and "mirrors"?

@digitalheir
Copy link
Author

I think it is a good idea to have a notion of 'subglyphs'. I wonder if the Hieroglyph fonts like Noto already define these, since ttf allows font authors to reuse shapes. Perhaps a good starting point?

@rosmord rosmord reopened this Apr 6, 2023
@rosmord
Copy link
Owner

rosmord commented Apr 6, 2023

I'm afraid won't be precise enough. Basically, you need Egyptologists to do this kind of work (and as far as I know, quite a few projects for sign description have included the information in signs_description.xml.

One of the current problems is that the sign info editor should probably be linked to a web site, allowing collaborative work. But

  • it would require quite a bit of work to create the site (not the main problem) ;
  • ... and it would require maintaining the site, validating stuff, avoiding spams...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DONE ! Has been done in a branch. The issue will be closed when the software is released
Projects
None yet
Development

No branches or pull requests

2 participants