You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
migrated from Trac, where originally posted by lars_h on 19-May-2014 12:47pm
The current CD format requires that every CMP or FMP is attached to a specific symbol, but it is not uncommon that a property one wishes to state is hard to classify as having more to do with one symbol than with another.
One example would be the identity
(a \circ b) \otimes (c \circ d) = (a \otimes c) \circ (b \otimes d)
(which appears on page 15 of http://arxiv.org/abs/1204.2421, if you want some context): is this an identity for \otimes or an identity for \circ? Neither choice has any precedence over the other.
A solution to this would be to allow CMPs and FMPs also as a direct child of the CD element, since this lets you state the basic claim that this is a property of the symbols in this dictionary, without attributing it to one specific symbol. Come to think of it, that applies equally well to Examples too.
By contrast, I expect it to be less common to have properties not specific to one content dictionary. A property may certainly mix symbols from several dictionaries, but it is usually introduced as part of the creation of one specific dictionary, so that will be where it is natural to state it. If one is simultaneously creating two content dictionaries and have to state a property that mixes symbols from both, then the question must arise why the two dictionaries should be separate. (There could be reasons, but I would not expect that to be usual.)
As per Michael's remark on #149, I'm adding the om3 list as Cc here.
The text was updated successfully, but these errors were encountered:
migrated from Trac, where originally posted by clange on 2-Jun-2014 11:34am
I support the idea of having CD-level CMPs and FMPs. Here, again, pairs of related CMPs/FMPs should be grouped into a common container as suggested in #140.
Regarding properties specific to more than one CD I would take it easy, as we wouldn't want to reinvent OMDoc and its theory graphs. IMHO it's fine to state properties that relate symbols from multiple CDs in either of the affected CDs, or even in a different CD.
migrated from Trac, where originally posted by lars_h on 19-May-2014 12:47pm
The current CD format requires that every CMP or FMP is attached to a specific symbol, but it is not uncommon that a property one wishes to state is hard to classify as having more to do with one symbol than with another.
One example would be the identity
(which appears on page 15 of http://arxiv.org/abs/1204.2421, if you want some context): is this an identity for \otimes or an identity for \circ? Neither choice has any precedence over the other.
A solution to this would be to allow CMPs and FMPs also as a direct child of the CD element, since this lets you state the basic claim that this is a property of the symbols in this dictionary, without attributing it to one specific symbol. Come to think of it, that applies equally well to Examples too.
By contrast, I expect it to be less common to have properties not specific to one content dictionary. A property may certainly mix symbols from several dictionaries, but it is usually introduced as part of the creation of one specific dictionary, so that will be where it is natural to state it. If one is simultaneously creating two content dictionaries and have to state a property that mixes symbols from both, then the question must arise why the two dictionaries should be separate. (There could be reasons, but I would not expect that to be usual.)
As per Michael's remark on #149, I'm adding the om3 list as Cc here.
The text was updated successfully, but these errors were encountered: