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

CD-level properties (CMP and FMP) #150

Closed
jbs1 opened this issue Jul 6, 2016 · 2 comments
Closed

CD-level properties (CMP and FMP) #150

jbs1 opened this issue Jul 6, 2016 · 2 comments
Assignees

Comments

@jbs1
Copy link

jbs1 commented Jul 6, 2016

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.

@jbs1
Copy link
Author

jbs1 commented Jul 6, 2016

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.

@kohlhase
Copy link
Member

kohlhase commented Oct 2, 2017

moved to OpenMath/OMSTD#15

@kohlhase kohlhase closed this as completed Oct 2, 2017
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

2 participants