search

KWARC / FoMID

0 stars 0 forks source link

Library structuring #17

Open Jazzpirate opened 3 years ago

Jazzpirate commented 3 years ago

Desirable features:

=> 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

kohlhase commented 3 years ago

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.

Jazzpirate commented 3 years ago

...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

kohlhase commented 3 years ago

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

wasn't that what MMT namespaces are for?

Jazzpirate commented 3 years ago

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

kohlhase commented 3 years ago

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

Jazzpirate commented 3 years ago

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.

kohlhase commented 3 years ago

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