KWARC / FoMID

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Library structuring

Jazzpirate opened this issue · comments

Desirable features:

  • Multilinguality
  • Multiple differing definitions for the same concepts (e.g. using realms, see #12)
  • Remarks, Examples
  • Glossary-like entry points? On MathHub, should be followed by definitions, remarks and examples
  • Provenance/Confidence? ("Definition published here", "proof published here", "proof implemented in system X here", "added by user Y")

=> SMGloM structure as smglom/area/conceptname.language.tex likely won't do anymore. Archive structure is questionable anyway, but also the addition of several "types" of entries and multiple entries for "the same" concepts put this into question. Also, once the library grows, the individual archives will grow by largely irrelevant (for a given user) content. E.g. everyone needs basic algebra, no one needs highly specialized concepts in higher commutative algebra.

=> GIT integration in MMT could maybe solve that by LMH specifically cherry picking (dependency trees of) individual modules? In that case, the "backend" organizational structures becomes largely irrelevant

I agree that "backend organizational structure" is irrelevant. Indeed I have always only seen the archive structure of SMGloM only as a way to organize (write/push) access and who feels responsible for an archive, not structure math into areas.

...although we need a similar "organizational structure" with respect to URIs, so we should still come up with a meaningful way of sorting entries into an organizational structure, that is ideally not wholly arbitrary

...although we need a similar "organizational structure" with respect to URIs,

wasn't that what MMT namespaces are for?

wasn't that what MMT namespaces are for?

Yes, so we should come up for a meaningful scheme to sort individual entries into meaningful namespaces ;)
e.g. http://mathhub.info/smglom/algebra/linear-algebra/vectorspaces?remark17335 might become ugly quickly

Ugly is not a problem!
Instead, we should make sure that we can serve the respective material under these URLs (at least) from MathHub

Ugly is not a problem!

I'm not entirely convinced this is true. If you want to include or reference a module or symbol, you ultimately have to somehow reference its URI. IDEs can help, but I don't think we should rely on IDE assistance alone. Of course, we can also help on the TeX side, but this too can only go so far. I think we make things easier for users if URIs are at least somewhat intuitive or memorable.

Even if "ugly is not a problem", beautiful is better :-)