Ticket #181 (new potential innovation)

Opened 4 years ago

Last modified 3 years ago

Dependencies between Renderings

Reported by: cmueller Owned by: vzholudev
Priority: minor Milestone: zzz Future zzz
Component: Presentation Version:
Keywords: Cc: nmueller, clange, kohlhase
Blocked By: Blocking:
Due to close: Include in GanttChart: no
Dependencies: Due to assign:

Description

In my discussion with mathematician, I was pointed to the following use case that I have already discussed with Normen and Michael via eMail. I am attaching a description and their responses below. I am adding this use case as I believe that we might want to model dependencies between rendering e.g. to also support a scenario described by Christoph in ticket:178.

Request by a mathematician: A system should warn you if you want to reuse an already used notation or letter. This is a very critical aspect as we make use of a lot of symbols but only have a limited amount of notations/ letters. However, choosing could notation is essential for mathematical writings.

me: I assume that this services requires a notion of equality on the side of MathML expressions or rather renderings elements (of different prototypes) that produce the same MathML output and should thus not be used in combination.

Normen: This rather relates to consistency checking than to MoC, but, yes, that would be worthwhile. Sounds interesting, although I am not sure on which ntn constituent the equality should be defined.

me: I assume that a notation of equality on the side of prototypes allows us to find similarities of the represented objects, of the semantics of objects.

me: On the rendering side it helps to detect if there are very similar or even equal presentations for different symbols. Authors want to avoid that as it confuses the reader.

Michael: Since we have largely eliminated the choice of notations from the documents themselves to higher levels, I do not think that MoC has much to offer here. The consistency is guaranteed by the presentation process and the CoPs?, I would say.

me: I am by no means an expert of MoC, but I see it on different levels. Maybe Normen's work would not directly cover this kind of "consistency" checking. But we can build on his conceptual findings and technical support to provide MoC on other layers, i.e. during the rendering. So based on Normen's work it is easier for us to define equality between renderings (or the respective MathML expressions).

Change History

Changed 4 years ago by clange

This is definitely an interesting use case. I think it's not generally related to #178, just that #178 is a very special case of this. If there is already a rendering for the context "Chinese,physics,waning moon" and some author wants to add another rendering for exactly the same context, then the author should be warned.

@Michael, I don't understand your comment. Sure, the process of choosing a notation is now situated on the !CoP level, but on a very technical level this results in precise markup, like @ec attributes, or notation tags. So once we know two rendering elements that the author wants to use and whose prototypes match different symbols, can't we just MDiff them?

Changed 4 years ago by cmueller

  • cc kohlhase added

Changed 4 years ago by cmueller

  • owner changed from cmueller to nmueller

Changed 3 years ago by nmueller

  • owner changed from nmueller to vzholudev
Note: See TracTickets for help on using tickets.