Implementation of notation tags

[cmueller]

Please revise the idea of notation tags as well as the respective extension of the rendering algorithm from the technical perspective.

This discussion is essential for the MKM journal paper (Normen was referring to in his eMail) and thus the deadline is rather critical (deadline for the paper is 5.01. but I am only available until 10.12.). Find the latest draft at:  https://svn.omdoc.org/repos/jomdoc/doc/blue/mkm-journal/paper.pdf

An earlier paper on the idea of notation tags can be found here:  http://kwarc.info/cmueller/papers/CDMTCS-341.pdf

[cmueller]

My prior email to the JOMDoc mailing-list

Motivation for Extending the Algorithm

The problem with the old rendering algorithm is, that no user (neither author nor reader) has an opportunity to explicitly select a rendering for a mathematical object in his paper. We have a work around: e.g. we can capture only one rendering in a notation definition and place it next to the object. When choosing the option "collect ntn from document", this notation definition has the highest priority. Having only one rendering child, this one will be selected. However, for granularity, users have to draw on the context-parameters (e.g. with Cascading Context Files or IC attributes) leaving it to the algorithm to select an appropriate rendering element, e.g. the "German" and the "Russian" one. But there is no way to simply say: Take this rendering for this object!

Notation tags

I propose notation tags that allow to extensionally select rendering. Instead of specifying properties, users can explicitly select a concrete rendering. Besides given users better control, this feature will be necessary to capture the user's explicit choice (i.e. when changing a notation with JOBAD). Please see further details in the following paper:  http://kwarc.info/cmueller/papers/CDMTCS-341.pdf

Reading

The following sections are interesting for this discussion:

• page 9 - informal introduction of notation tags
• 4.3. Revision of the conversion algorithm (also summarized the previous options)
• figure 9: Two example notation tags in XML with explanation below
• 5.2. Another use of notation tags and extension of JOMDoc: I ask to discuss to extend JOMDoc to track all applied rendering elements in the conversion process and preserving this information in the convert output document. Figure 11 proposes two examples in OMDoc and XHTML+RDFa.

[cmueller]

Replying to cmueller: Below you find Christoph's response to the mailing list:

= Motivation for Extending the Algorithm = The problem with the old rendering algorithm is, that no user (neither author nor reader) has an opportunity to explicitly select a rendering for a mathematical object in his paper.

Not? Well, maybe not in JOMDoc, but haven't you already had an idea for solving this in the 2007 MathUI paper?

We have a work around: e.g. we can capture only one rendering in a notation definition and place it next to the object. When choosing the option "collect ntn from document", this notation definition has the highest priority. Having only one rendering child, this one will be selected.

I agree that this is not an elegant, scalable solution.

... I propose notation tags that allow to extensionally select rendering. Instead of specifying properties, users can explicitly select a concrete rendering. Besides given users better control, this feature will be necessary to capture the user's explicit choice (i.e. when changing a notation with JOBAD).

I'm not yet sure whether/how this will affect JOBAD. Suppose that in an active document the reader selects a notation N for a symbol S, which is part of a formula F. Suppose that p_old(F) was the presentation of F before the selection, and let p_new(F) be the new presentation. Suppose that we'd also like to remember p_old(F) in the active document for easily reverting to this presentation. (And consider that we've already had the idea to do that by adding the new rendering of F as an additional child to an maction.) Then, it would be perfectly sufficient to encode this as

<semantics>
  <maction selection="1">
    <mrow>p_new(F)</mrow>
    <mrow>p_old(F)</mrow>
  </maction>
  <annotation-xml>
    F <!-- i.e. the content markup of F -->
  </annotation-xml>
</semantics>

From this point of view we would only need the notation tags for the JOMDoc renderer, but not for JOBAD.

Nevertheless, I think it makes sense to use them in the active document as well. That would give us the advantage to make the client side know that p_new(F) and p_old(F) are not just two alternative representations of F, between which the user wanted to switch, but also _why_ (or: in what regard) they are alternatives. Consider the following improvement (pseudo-code, imagine the actual notation tag syntax here):

<maction selection="1">
  <semantics>
    <mrow>p_new(F)</mrow>
    <annotation-xml>
      <notation-tag use-notation="alternative-notation">
        F
      </notation-tag>
    </annotation-xml>
  </semantics>
  <semantics>
    <mrow>p_old(F)</mrow>
    <annotation-xml>
      <!-- no notation tag, as this is the original F -->
      F
    </annotation-xml>
  </semantics>
</maction>

What do you think about that?

[cmueller]

Replying to cmueller:

Replying to cmueller: Below you find Christoph's response to the mailing list:

= Motivation for Extending the Algorithm = The problem with the old rendering algorithm is, that no user (neither author nor reader) has an opportunity to explicitly select a rendering for a mathematical object in his paper.

Not? Well, maybe not in JOMDoc, but haven't you already had an idea for solving this in the 2007 MathUI paper?

The paper can be found at  http://kwarc.info/publications/papers/mathUI07.pdf

At the time of that paper the notation definition have not be used. We were drawing on the old presentation elements. We made use of the OMDoc pcontext element to import a collection of these presentation elements into a document.

<pcontext xml:id=”paper5−pc” base=”#report−pc”><ref xref=”#pres4−id”/></pcontext>

The above reference a presentation element with xml:id="pres4-id" in the document report-pc.

For granular selection, we overwrite the pcontext by referencing an presentation element with a pc attribute:

<omtext xml:id=”text1”>
 <CMP>We will discuss the binomial coefficient which can be represented in three alternative ways: i . e .
 <OMOBJ xml:id=”foo”>
   <OMA><OMS cd=”bk” name=”bk”/><OMV name=”n”/></OMV name=”k”/></OMA>
 </OMOBJ> (Germany),
 <ref xref=”#foo” pc=”#bk−F”/> (France), and <ref xref=”#foo” pc=”#bk−R”/> (Russia) </CMP>
</omtext>

For example <ref xref=”#foo” pc=”#bk−F”/> reference a presentation element with xml:id="bk-F" in the document foo. So in the flattened document the ref elements are substituted with the presentation elements.

However, now we have notation definition, with prototype and rendering elements. The rendering elements are analogously to the former presentation elements. If we would draw on a similar approach, where foo is the URI of a document and bk-F is the URI of a rendering element, the flatting will produce invalid OMDoc: We can not simply replace the ref with the rendering element, as it must be embedded in a notation definition. We can replace a ref with the notation definition (that include bk-F), but and unless bk-F is the first child, it will not be consider for the conversion.

So I believe that we cannot draw on this approach any longer, but propose to introduce a new element, a tag element, which is an optional input into the conversion algorithm changing it as follows:

• collect all notation definitions
• arrange prototypes and renderings in a map (where key=prototype and value=set of rendering), renderings are arranged based on the order they were collected
• optionally: rearranged renderings based on context parameters
• optionally: select the rendering that is tagged for a specific object, analogous to all other collection: tags closer to the object have a higher priority.

<tag xref="bk-D"/>
<omtext>
<OMOBJ xml:id="math">...</OMOBJ>
<tag xref="bk-F"/>
</omtext>

For example, to present math the rendering bk-F is chosen as it is closer to the object than bk-D (of course only if the rendering is a value for the respective prototype that matches math)

Tags can be collected from different sources: Within the input document or an external file. These sources can be prioritized.

But this is my suggestion, I am open for discussion.

[clange]

Replying to cmueller:

<omtext xml:id=”text1”>
 <CMP>We will discuss the binomial coefficient which can be represented in three alternative ways: i . e .
 <OMOBJ xml:id=”foo”>
   <OMA><OMS cd=”bk” name=”bk”/><OMV name=”n”/></OMV name=”k”/></OMA>
 </OMOBJ> (Germany),
 <ref xref=”#foo” pc=”#bk−F”/> (France), and <ref xref=”#foo” pc=”#bk−R”/> (Russia) </CMP>
</omtext>

For example <ref xref=”#foo” pc=”#bk−F”/> reference a presentation element with xml:id="bk-F" in the document foo. So in the flattened document the ref elements are substituted with the presentation elements.

That's wrong. A ref is replaced with the target of its @xref attribute. In this case, this is the OMOBJ, and the @pc attribute selects the presentation context to apply while resolving the ref. That would work with @pc pointing to rendering elements as well.

<tag xref="bk-D"/>
<omtext>
<OMOBJ xml:id="math">...</OMOBJ>
<tag xref="bk-F"/>
</omtext>

For example, to present math the rendering bk-F is chosen as it is closer to the object than bk-D (of course only if the rendering is a value for the respective prototype that matches math)

In fact I think this makes processing (and practical implementation) harder. While it's easy to dereference a URI reference, it is more work to find the closest tag element.

But this is my suggestion, I am open for discussion.

Note that hereby I don't intend to say that the old approach is good and the new one is bad. These are just two comments about separate parts of your post, which are not in contradiction to each other. I do not yet know which syntax I actually prefer. I think a good thing about the new "tag" approach is that it is more flexible, as these tags can also be placed in completely different places as the formulas can be, e.g. in user profiles.

However, the tag element does not yet look to me like an OMDoc syntax that will actually be implementable. Many things can be tagged, be it with keywords, or with more complex things. That means, for a language with such diverse applications as OMDoc has, the very general element name tag for such a special relationship as a notational preference seems too restrictive to me. But that concern can easily be accommodated by including an attribute for the "dimension" of tagging, e.g. <tag dimension="omdoc:notation" xref="#rend"/>, if "dimension" is the right term.

[cmueller]

Replying to clange:

Replying to cmueller: That's wrong. A ref is replaced with the target of its @xref attribute. In this case, this is the OMOBJ, and the @pc attribute selects the presentation context to apply while resolving the ref. That would work with @pc pointing to rendering elements as well.

Sorry for that. You are absolutely right, I should have read more carefully. And I agree, this could still be used for the new approach and actually already is used in a limited from, i.e. the ec attribute.

The ec attribute allows to point to containers and notation definition. If we allow it to also point to rendering, it would include the pc-purpose.

The value of the ec attribute would than depend on the granularity of the pointer allowing it to point either to containers (doc_id), notations definition (doc-ID/ntn-ID), or rendering elements (doc-ID/ntn-ID/rend-ID). Please note that the references should be consistent to Florian's addressing schema.

However, with the latter most granular pointer the collector has more work as it can not longer collect notation definitions. Instead, it has to filter the collected notation definition as only a one/subset of its renderings is referenced. I am not sure, whether we want to complicate the collection step. What do you think?

{{{ <tag xref="bk-D"/> <omtext> <OMOBJ xml:id="math">...</OMOBJ> <tag xref="bk-F"/> </omtext> }}}

For example, to present math the rendering bk-F is chosen as it is closer to the object than bk-D (of course only if the rendering is a value for the respective prototype that matches math)

In fact I think this makes processing (and practical implementation) harder. While it's easy to dereference a URI reference, it is more work to find the closest tag element.

Yes, but we restrict the use of extensional references to the input document. The tag provides another layer of markup in addition to reference in the input document. well, but you are saying this below ...

I think a good thing about the new "tag" approach is that it is more flexible, as these tags can also be placed in completely different places as the formulas can be, e.g. in user profiles.

I agree, so maybe we want to have both (if we decide that the extension of the ec attribute is worthwhile).

However, the tag element does not yet look to me like an OMDoc syntax that will actually be implementable. Many things can be tagged, be it with keywords, or with more complex things. That means, for a language with such diverse applications as OMDoc has, the very general element name tag for such a special relationship as a notational preference seems too restrictive to me. But that concern can easily be accommodated by including an attribute for the "dimension" of tagging, e.g. <tag dimension="omdoc:notation" xref="#rend"/>, if "dimension" is the right term.

Yes, you are right. Maybe we can also use type instead of dimension.

[clange]

Replying to cmueller:

The value of the ec attribute would than depend on the granularity of the pointer allowing it to point either to containers (doc_id), notations definition (doc-ID/ntn-ID), or rendering elements (doc-ID/ntn-ID/rend-ID). Please note that the references should be consistent to Florian's addressing schema.

I thought so, too, but then I don't understand why he suggests the primitive documentURI#fragmentID syntax in comment:ticket:27:9. Maybe it's not yet clear to him how notation definitions would fit into the more formal MMT framework.

However, with the latter most granular pointer the collector has more work as it can not longer collect notation definitions. Instead, it has to filter the collected notation definition as only a one/subset of its renderings is referenced. I am not sure, whether we want to complicate the collection step. What do you think?

No idea right now :-( But, still, can't we leave the collector as it is and use the fine-granular references as a way of prioritizing the collected notation definitions in cases where more than one of them matches?

However, the tag element does not yet look to me like an OMDoc syntax that will actually be implementable. Many things can be tagged, be it with keywords, or with more complex things. That means, for a language with such diverse applications as OMDoc has, the very general element name tag for such a special relationship as a notational preference seems too restrictive to me. But that concern can easily be accommodated by including an attribute for the "dimension" of tagging, e.g. <tag dimension="omdoc:notation" xref="#rend"/>, if "dimension" is the right term.

Yes, you are right. Maybe we can also use type instead of dimension.

Good idea. type would be consistent with other elements of the OMDoc syntax.

[cmueller]

Replying to clange:

I thought so, too, but then I don't understand why he suggests the primitive documentURI#fragmentID syntax in comment:ticket:27:9. Maybe it's not yet clear to him how notation definitions would fit into the more formal MMT framework.

We should find out. Florian, can you please help?

No idea right now :-( But, still, can't we leave the collector as it is and use the fine-granular references as a way of prioritizing the collected notation definitions in cases where more than one of them matches?

The collector collects notation definitions (this collection is ordered based on the prioritization of collection option and the actual order the notation definitions are collected). Then, the collector rearranges the collected notation definitions into a map, which keys are prototypes and values are lists of all renderings that are connected to these prototypes.

Given

ntn1: p1 => r1,r2,r3
ntn2: p2 => r4,r5,r6

and ec="ntn1/r3,ntn2/r5"

The collector would collect ntn1 and ntn2 and add them to his collection-list. Internally he would then build the following map, also only two renderings (r3 and r5) should have been considered:

p1 => r1,r2,r3
p2 => r4,r5,r6

instead of

p1 => r3
p2 => r5

Using the ec to prioritize notation definitions, is what we currently do. However, without filtering the notation definitions, these ec attributes cannot be used as explicit selections of rendering.

[dmisev]

This with the tags is a pretty good idea! Much more flexible/reusable (on the user side) than the EC solution. Also applicable to other areas and not only notations as Christoph pointed out. Extending EC shouldn't be big deal, and I think we should make it higher priority in the rendering selection (as the most granular approach) before the tags.

I'll start coding considering this syntax:

<tag type="notation" xref="notation xml:id"/>

[dmisev]

ops, the xref was wrong should be:

<tag type="notation" xref="rendering xml:id"/>

[clange]

Replying to dmisev:

{{{ <tag type="notation" xref="rendering xml:id"/> }}}

Just the xml:id is not nice for resolving the references. I'd rather put the URI of the rendering element there, which is #xmlid if we are in the same document, or some/uri/of/a/document#xmlid otherwise.

[dmisev]

Hm yes, xml:ids won't necessarily be unique among different documents, but it's very probable that if there are two same ids then the renderings are the same thing. I was thinking of the tags as simple rendering selection from the already collected notations, while leaving EC as the more rigorous, stricter alternative. But I don't know, what do you think of this?

[clange]

Replying to dmisev:

Hm yes, xml:ids won't necessarily be unique among different documents, but it's very probable that if there are two same ids then the renderings are the same thing.

You can't rely on that.

I was thinking of the tags as simple rendering selection from the already collected notations, while leaving EC as the more rigorous, stricter alternative. But I don't know, what do you think of this?

Having both a simple and an advanced solution is generally good. However, the simple solution still should not be wrong, and that's why I plea for proper URIrefs as attribute values -- which is BTW the case in all other xref attributes in OMDoc as well. On the other hand, didn't you say that the tags are more flexible and reusable? Isn't that an argument for preferring tags over EC?

[dmisev]

Replying to clange:

On the other hand, didn't you say that the tags are more flexible and reusable? Isn't that an argument for preferring tags over EC?

Yes sure, but a tag will work globally on the whole document, and if you want to do it specifically for some object then EC would be the right choice.

Some more on the xref discussion - consider you've made a "profile" collection of tag elements, where every xref will be "absolute URI#rendering id" (I'm not sure if relative URIs would be possible in this case?). If you move some notation container then you'll have to update this tags collection, or if you move your "profile" to another system then you'll most probably have to update every reference. It'll be quite tedious for the users to maintain their preferences, and I see no big difference from EC here.

[clange]

Replying to dmisev:

Yes sure, but a tag will work globally on the whole document, and if you want to do it specifically for some object then EC would be the right choice.

Oh, yes, I see.

Some more on the xref discussion - consider you've made a "profile" collection of tag elements, where every xref will be "absolute URI#rendering id" (I'm not sure if relative URIs would be possible in this case?).

Sure. If I say "URIref" I'm talking about this datatype:  http://www.w3.org/TR/xmlschema-2/#anyURI

If you move some notation container then you'll have to update this tags collection, or if you move your "profile" to another system then you'll most probably have to update every reference. It'll be quite tedious for the users to maintain their preferences, and I see no big difference from EC here.

OK, then we have to think about a way for tagging that is both simple to write and maintainable. Relying on xml:ids to be unique throughout a document collection is not an option. URIs pointing to notation containers may change, as you pointed out. So what we might actually need is a per-repository "notation resolution" service with its own URI syntax, which abstracts from the actual locations of the notation definitions.

[clange]

Notice my latest mail to the JOMDoc list, with some ideas about more detailed notation tags pointing from single symbols to renderings and why we need them for certain use cases. Once I got some feedback from you, I will create tickets or comments from parts of that mail.

[clange]

The notation tags, as we are discussing them right now, are not sufficient for all use cases -- if my following assumptions are right. But I need your feedback.

This is a copy of the aspects of today's long e-mail that are related to this thing. I will file a separate ticket for the other statement about roles of prototypes.

First of all, why do we need notation tags? There are two use cases that I think I understand well, and I'll focus on them: notation editing in SWiM and notation selection in JOBAD. There are others, but, @Christine, I think you understand them better, and you know the requirements for them.

The use case for NOTATION EDITING (in the context of SWiM and the OpenMath? CDs) is as follows:

1. a user looks at a formula and thinks that the rendering of a certain symbol is wrong.
2. He wants to click on the symbol (or use a context menu) to quickly reach the notation definition in order to fix it.
3. "The notation definition" here is the one that was used when rendering the respective symbol.

It's not yet clear to me whether (2) should lead the author to the rendering element only, or rather to the whole notation definition, as the prototype could also be wrong.

A possible enhancement of this workflow is when the user is fine with the existing notation but wants to author a new, alternative one.

The use case for NOTATION SELECTION (in the context of JOBAD) is as follows:

1. a user looks at a formula and doesn't like the way a certain symbol is rendered.
2. He opens a context menu for the symbol and sees that there are alternative renderings.
3. He selects one of them.
4. The "alternative renderings" here are all renderings that are part of notation definitions for the respective symbol, except the one that was just used to render the symbol.

@Christine: That requires what you just explained to me: that we need notation tags in the output document rendered by JOMDoc (as in fig. 12 in the paper draft), in order to make it explicit on the client side what notation definition was used to render a particular symbol. But I claim that the current way of representing this information is not yet sufficient. Not talking about contexts now, we so far represent one information: that a certain rendering was used while rendering a particular formula. But what if the same symbol occurs more than once in a formula but is rendered differently? Consider a formula

(n \choose k) = C^n_k

This formula expresses the equality of two renderings for the binomial coefficient, and in content markup (Lisp-like pseudo-code) it would maybe look like this. (@Christine, correct me if I'm wrong!):

(equals ([ec=rendering1] (binom n k)) ([ec=rendering2] (binom n k)))

Now we can't just say in the output that "rendering1" and "rendering2" were used. (That's how I understand the current draft of notation tags.)

So I think that instead of, or in addition to

<div about="#mobj">
  <span rel="o:tag" href="url/of/rendering1"/>
  <span rel="o:tag" href="url/of/rendering2"/>
  <m:semantics>
    <!-- PMML -->
    <m:annotation-xml>
      <om:OMOBJ xml:id="#mobj">
        <!-- ... -->
      </om:OMOBJ>
    </m:annotation-xml>
  </m:semantics>
</div>

we necessarily have to introduce links from the symbols in the OMOBJ to the renderings that were used for rendering them. If an extensional context was given for the respective symbol or subterm and took precedence over other rules during the rendering, we may just be able to preserve the respective @ec attributes. Imagine, however, that "rendering1" was selected because it matched the current intensional context (e.g. the language), and "rendering2" was forcibly selected by an @ec attribute. Then, we'd also need to include the information in the output that the first occurrence of the symbol was rendered using "rendering1". A way of doing that could be putting the notatin tag into an OpenMath? attribution:

<om:OMATTR>
  <om:OMATP>
    <om:OMS cd="jomdoc" name="used-rendering"/>
    <om:OMFOREIGN>
      <tag xref="url/of/rendering1"/>
    </om:OMFOREIGN>
  </om:OMATP>
  <om:OMA>
    <om:OMS cd="combinat1" name="binom"/>
    <om:OMV>n</om:OMV>
    <om:OMV>k</om:OMV>
  </om:OMA>
</om:OMATTR>

Thanks to parallel markup, the client-side application (e.g. JOBAD) could then easily get hold of the rendering that was used exactly for the symbol that the user clicked.

[dmisev]

But is this related to this ticket? I see the notation tags as an alternative way for selecting renderings, and this as a possible way to annotate how an object was rendered. Applications would definitely benefit from having this kind of information after JOMDoc has done the rendering (as in your use cases). I just think we should put it in a separate ticket and discuss it there.

I'll implement the notation tags as they are described in the paper. For @xref I'll make these three formats valid:

• docURI#renderingId
• #renderingId
• renderingId - in this case the rendering is selected from the already collected notations

Mentioning the notationId in xref seems redundant to me, as xml:ids are anyways unique in the document.

Christine/Christoph?, any comments?

[clange]

Replying to dmisev:

But is this related to this ticket?

Of course it is. Just note that I'm talking about a special case, i.e. my concerns were not about notation tags in the content markup but only about notation tags in the rendered document.

I see the notation tags as an alternative way for selecting renderings, and this as a possible way to annotate how an object was rendered.

My post was not against notation tags, but about a better way of doing them. I claimed that the existing idea of doing notation tags is insufficient for editing and selecting notations (see examples above) -- a show-stopper for such interactive services, if I haven't made a mistake in my reasoning. If we agree that such a better way is needed, it's up to us do decide whether it should replace the <tag/> approach, or whether it should be offered as an alternative. This has to be negotiated with Christine, as she is aware of the other use cases for notation tags, which are neither editing nor selection.

Applications would definitely benefit from having this kind of information after JOMDoc has done the rendering (as in your use cases). I just think we should put it in a separate ticket and discuss it there.

Feel free to do so, but I insist that my objections are about the topic of this ticket (at least as far as notation tags in the rendered output are concerned) and should be discussed before starting the implementation.

@Christine: Nevertheless, it may be a pragmatic solution to implement <tag/> first, to please the reviewers of the paper that introduced them. I cannot judge on that.

I'll implement the notation tags as they are described in the paper. For @xref I'll make these three formats valid: * docURI#renderingId * #renderingId * renderingId - in this case the rendering is selected from the already collected notations

The latter is evil. If we say that the type of @xref is URIref (xs:anyURI), then renderingId would be a relative URI. Think of a REST-based system that makes available small pieces of OMDoc knowledge by URIs (like the upcoming TNTBase), then renderingId could well be the relative URI to a document in the same, well, maybe not directory, but theory, or notation definition.

[clange]

Just got some feedback from Michael on that. See #177 for a new syntax for notation tags in the rendered output.

Michael confirmed that my use case descriptions are valid and that in these cases one does need notation tags that are closer to the rendered symbols. Then, he convinced me that actually one doesn't want the tags in the content markup part of the parallel markup output (so forget about my OMATTR idea), but in the presentation markup. And there, it's a good practice (as the elision proves) to simply invent a new attribute for it.

@Christine, Dimitar: Do you agree?

Note: #177 only covers notation tags in the output generated by the renderer. I don't have any particular objections against using the proposed <tag/> element in OMDoc source documents nor user profiles.

[cmueller]

Replying to clange:

@Christine, Dimitar: Do you agree?

I agree.

Note: #177 only covers notation tags in the output generated by the renderer. I don't have any particular objections against using the proposed <tag/> element in OMDoc source documents nor user profiles.

So what is our final representation for the tag element now? I got confused by the many ideas we had so far. Thank you!

[dmisev]

Replying to clange:

@Christine, Dimitar: Do you agree?

I agree.

The latter is evil. If we say that the type of @xref is URIref (xs:anyURI), then renderingId would be a relative URI. Think of a REST-based system that makes available small pieces of OMDoc knowledge by URIs (like the upcoming TNTBase), then renderingId could well be the relative URI to a document in the same, well, maybe not directory, but theory, or notation definition.

Ok then, the first two only.

So what is our final representation for the tag element now? I got confused by the many ideas we had so far. Thank you!

I think it's same as in the paper + #177 ?

[cmueller]

Replying to dmisev:

So what is our final representation for the tag element now? I got confused by the many ideas we had so far. Thank you!

I think it's same as in the paper + #177 ?

Yes, plus the type="notation" attribute.

[clange]

Christine, Dimitar, thanks for your feedback! Replying to dmisev:

So what is our final representation for the tag element now? I got confused by the many ideas we had so far. Thank you!

I think it's same as in the paper + #177 ?

Yes, why not? But let's consider the three cases separately. @Christine, what do you think?

• The original OMDoc document: Here, I think your reason for introducing <tag/> was giving the user an easier alternative to putting @ec attributes into the OpenMath? markup -- right? If that's the case, I fully agree with doing both implementations, but anyway, that's rather your business (and research field) than mine :-)
• The user profile: If I understood the paper correctly where you introduced notation tags, <tag/> makes perfectly sense there. (On the other hand, this occurrence of notation tags is not yet handled by JOMDoc, is it?)
• The rendered document: From my JOBAD and SWiM point of view, #177 would solve all problems. For other use cases, it's also easy to collect the @ec attribute in the whole PMML formula using a single XPath expression (descendant::m:*/@ec). So I think we don't need <tag/> there -- but maybe you have a use case where they do make sense -- what do you finally think?

[cmueller]

Replying to clange:

Christine, Dimitar, thanks for your feedback! Replying to dmisev:

So what is our final representation for the tag element now? I got confused by the many ideas we had so far. Thank you!

I think it's same as in the paper + #177 ?

Yes, why not? But let's consider the three cases separately. @Christine, what do you think? * The original OMDoc document: Here, I think your reason for introducing <tag/> was giving the user an easier alternative to putting @ec attributes into the OpenMath? markup -- right? If that's the case, I fully agree with doing both implementations, but anyway, that's rather your business (and research field) than mine :-)

Well, I wasn't actually thinking about making it easier for users. I just needed to know what renderings have been used for all mathematical object in a page (to implicitly enrich the user model: a rating of a page means that the user likes all referenced renderings). So it can either be tags or ec.

* The user profile: If I understood the paper correctly where you introduced notation tags, <tag/> makes perfectly sense there. (On the other hand, this occurrence of notation tags is not yet handled by JOMDoc, is it?)

A user profile can be seen as a notation document with tags only. Thus, JOMDoc needs to be able to collect all tags from a file and use them. The former is thus only a sub-case of this one, we can also allow users to use either "tag" or "ec" as we need to collect (parse) both anyway.

* The rendered document: From my JOBAD and SWiM point of view, #177 would solve all problems. For other use cases, it's also easy to collect the @ec attribute in the whole PMML formula using a single XPath expression (descendant::m:*/@ec). So I think we don't need <tag/> there -- but maybe you have a use case where they do make sense -- what do you finally think?

I agree, "ec" is enough.

[clange]

Replying to cmueller:

Well, I wasn't actually thinking about making it easier for users. I just needed to know what renderings have been used for all mathematical object in a page (to implicitly enrich the user model: a rating of a page means that the user likes all referenced renderings). So it can either be tags or ec. A user profile can be seen as a notation document with tags only. Thus, JOMDoc needs to be able to collect all tags from a file and use them. The former is thus only a sub-case of this one, we can also allow users to use either "tag" or "ec" as we need to collect (parse) both anyway.

Ah, so your reason for coming up with tag in addition to @ec, which has existed before (in the MKM paper) was the user profile scenario, where there is no content-markup formula, but just these tags. Makes sense. Yes, or course, in an OMDoc document we could then look for both tag and @ec.

From a very technical point of view, both is easy. In XPath it's tag/@xref (where tag means "all child elements (of the div that contains the rendered formula) that are named 'tag'") vs. descendant::m:*/@ec.

[dmisev]

I've added support for notation tags in JOMDoc. To enable collection and application of notation tags use the --tags option, and then -f, --doc, --ec in the same way as for notation collection.