D6.3: Design of Triform (DKS) Theories (Specification/RNC Schema/Examples) and Implementation of Triform Theories in the MMT API #137

Closed
minrk opened this Issue Sep 8, 2015 · 18 comments

Comments

Projects
None yet
5 participants
@minrk
Contributor

minrk commented Sep 8, 2015

  • WP6: Data/Knowledge/Software-Bases
  • Lead Institution: Jacobs University Bremen
  • Due: 2016-11-30 (month 15)
  • Delivered: 2016-09-10, together with D6.2 (#136)
  • Nature: Report
  • Task: T6.2 (#124)
  • Proposal: 55
  • Final report: bundled with the report for D6.2 (#136)

The OpenDreamKit proposal had envisioned WP6: Data/Knowledge/Software bases as a foundational enterprise that would develop a knowledge-based architecture over the course of the project and would allow to re-engineer ad-hoc interfaces between systems (e.g. from T3.2 (#51)) on a more semantic basis -- the knowledge aspect (K). Consequently, the proposal envisioned concentrating the data (D) aspect on the mathematical knowledge bases (specifically LMFDB, OEIS, and FindStat) and proposed a host of foundational investigations of mathematical for the software (S) aspect with applications e.g. in the verification of algorithms.

Already the kickoff meeting in Paris in September 2015 revealed that the D/K/S aspects are much more tightly coupled in systems than anticipated. This was confirmed by the DKS survey conducted subsequently (see Section 2 of D6.2 (#136)). In particular, the participants of WP6 identified the interoperability of OpenDreamKit systems to be one of the most critical steps in creating a VRE toolkit. Thus we prioritized tasks T6.1 (#123), T6.2 (#124), T6.3 (#125) and organized a series of workshops and code-maratons to develop a semantic foundation for system interoperability and simultaneously test it in implementations.

As a consequence, we have completed the initial design of D/K/S-bases (for D6.2 (#136)) in parallel with the initial implementation of a DKS base format based on OMDoc/MMT and the implementation of a DKS base system itself based on the MMT system (both for D6.3 (#137)), all activities fuelling each other. D6.3 (#137) was thus completed about three months ahead of schedule. Note that the RNC schema envisioned in the title proved un-necessary since, with the refined Math-in-the-Middle (MitM) design, the normal OMDoc/MMT schema is sufficient.

Due to the resulting tight coupling between D6.2 (#136) and D6.3 (#137), and for the convenience of the reader, we have decided to report on both deliverables together; see the report for deliverable D6.2 (#136). When the design has further matured through work in the OpenDreamKit project, we plan to describe the MitM paradigm of integration of mathematical software systems into a VRE toolkit in a journal paper. We envision submission around month 27.

@minrk minrk added this to the D6.3 milestone Sep 8, 2015

@kohlhase kohlhase self-assigned this Sep 15, 2015

@kohlhase

This comment has been minimized.

Show comment
Hide comment
@kohlhase

kohlhase Jun 30, 2016

Member

we are working on this in based on the WP6 workshops and use cases. We have an initial design and implementation in MMT. This will be written up.

Member

kohlhase commented Jun 30, 2016

we are working on this in based on the WP6 workshops and use cases. We have an initial design and implementation in MMT. This will be written up.

@kohlhase

This comment has been minimized.

Show comment
Hide comment
@kohlhase

kohlhase Aug 29, 2016

Member

Essentially, this is the initial implementation of the design in D6.2 (#136). This needs to say more about the querying interface.
In particular, the OMDoc/MMT schema should be enough.

Member

kohlhase commented Aug 29, 2016

Essentially, this is the initial implementation of the design in D6.2 (#136). This needs to say more about the querying interface.
In particular, the OMDoc/MMT schema should be enough.

@kohlhase

This comment has been minimized.

Show comment
Hide comment
@kohlhase

kohlhase Sep 5, 2016

Member

@nthiery @bpilorget, We would like your advice.

In the process of writing up D6.2 (see #136) the initial design has been sufficiently stabilized that we have implemented large parts of the "initial design" in the MMT System. This makes sense, since we could otherwise not be sure that the design is sensible. But this is a problem for writing up the two deliverables D6.2/3. In D6.2 we want to argue for the sensibility of the design, and in D6.3 we are supposed to talk about the implementation (BTW, Schemata, ... do not even make sense now, since we did not have to extend OMDoc/MMT by new features, so the schemata already pre-exist). The problem is that D6.2 and D6.3 share a lot of contents. I can see three possible ways to deal with the situation:

  1. We throw out the implementation parts from D6.2 and save them for 6.3, this makes D6.2 a lot weaker and less self-contained.
  2. we combine D6.2 and D6.3 into a single report (just put the two titles on the title page and explain why we do this in the abstract and intro), which we already submit now.
  3. we make D6.3 as an update of D6.2, and mark the new text passages, so that they stand out.
    I think the second would option would be the best, since it gives the most readable report. This would probably (since we give both deliverables) not even need a change in the grant agreement. And the earlier discharge of the deliverable D6.3 would mesh well with the fact that we postponed D4.3 saying that we spent more time on WP6 initially.
    Please comment.
Member

kohlhase commented Sep 5, 2016

@nthiery @bpilorget, We would like your advice.

In the process of writing up D6.2 (see #136) the initial design has been sufficiently stabilized that we have implemented large parts of the "initial design" in the MMT System. This makes sense, since we could otherwise not be sure that the design is sensible. But this is a problem for writing up the two deliverables D6.2/3. In D6.2 we want to argue for the sensibility of the design, and in D6.3 we are supposed to talk about the implementation (BTW, Schemata, ... do not even make sense now, since we did not have to extend OMDoc/MMT by new features, so the schemata already pre-exist). The problem is that D6.2 and D6.3 share a lot of contents. I can see three possible ways to deal with the situation:

  1. We throw out the implementation parts from D6.2 and save them for 6.3, this makes D6.2 a lot weaker and less self-contained.
  2. we combine D6.2 and D6.3 into a single report (just put the two titles on the title page and explain why we do this in the abstract and intro), which we already submit now.
  3. we make D6.3 as an update of D6.2, and mark the new text passages, so that they stand out.
    I think the second would option would be the best, since it gives the most readable report. This would probably (since we give both deliverables) not even need a change in the grant agreement. And the earlier discharge of the deliverable D6.3 would mesh well with the fact that we postponed D4.3 saying that we spent more time on WP6 initially.
    Please comment.
@kohlhase

This comment has been minimized.

Show comment
Hide comment
@kohlhase

kohlhase Sep 5, 2016

Member

We could also mention that we want to write a journal paper about the content of D6.2/3 which can serve as an update. The draft of this could become an ODK report that is not a deliverable.

Member

kohlhase commented Sep 5, 2016

We could also mention that we want to write a journal paper about the content of D6.2/3 which can serve as an update. The draft of this could become an ODK report that is not a deliverable.

@bpilorget

This comment has been minimized.

Show comment
Hide comment
@bpilorget

bpilorget Sep 6, 2016

Contributor

If everything planned for D6.3 can be written right now in a combined D6.2/D6.3 deliverable, I don't see any objection. Maybe make clear in titles of the document what parts are more 6.2 and what parts are more 6.3.
The update through a journal paper is also a good idea and it can be said in the introduction of the front page.

Contributor

bpilorget commented Sep 6, 2016

If everything planned for D6.3 can be written right now in a combined D6.2/D6.3 deliverable, I don't see any objection. Maybe make clear in titles of the document what parts are more 6.2 and what parts are more 6.3.
The update through a journal paper is also a good idea and it can be said in the introduction of the front page.

@kohlhase

This comment has been minimized.

Show comment
Hide comment
@kohlhase

kohlhase Sep 6, 2016

Member

, I don't see any objection.

excellent, then that is what I will (attempt to) do.

Maybe make clear in titles of the document what parts are more 6.2 and what parts are more 6.3.

good idea. I will do that.

Member

kohlhase commented Sep 6, 2016

, I don't see any objection.

excellent, then that is what I will (attempt to) do.

Maybe make clear in titles of the document what parts are more 6.2 and what parts are more 6.3.

good idea. I will do that.

@nthiery

This comment has been minimized.

Show comment
Hide comment
@nthiery

nthiery Sep 7, 2016

Contributor

Hi Michael!
Given the situation I agree that it's more meaningful, and in fact more practical for the reviewers, to have a single true report with all the material (of course with proper indications of what's design and what's implementation).

Technically speaking, I will need to upload two pdf's; however one of them could be reduced to a short document explaning that D6.2 ending up being subsumed by D6.3 (or the converse) and why, and refering to the other report. This of course assumes that we would be delivering D6.2 and D6.3 simultaneously. What's your foreseen timeline?
This of course will need to be approved by our PO, but I expect no trouble: after all, we would be delivering D6.3 a couple months early!

Contributor

nthiery commented Sep 7, 2016

Hi Michael!
Given the situation I agree that it's more meaningful, and in fact more practical for the reviewers, to have a single true report with all the material (of course with proper indications of what's design and what's implementation).

Technically speaking, I will need to upload two pdf's; however one of them could be reduced to a short document explaning that D6.2 ending up being subsumed by D6.3 (or the converse) and why, and refering to the other report. This of course assumes that we would be delivering D6.2 and D6.3 simultaneously. What's your foreseen timeline?
This of course will need to be approved by our PO, but I expect no trouble: after all, we would be delivering D6.3 a couple months early!

@kohlhase

This comment has been minimized.

Show comment
Hide comment
@kohlhase

kohlhase Sep 7, 2016

Member

I will need to upload two pdf's; however one of them could be reduced to

OK, I can do that, sounds reasonable.

What's your foreseen timeline?

The report is done in essence (still waiting for a contribution from @pdehaye ) and with the merging overhead, I expect that I will be done with everything by friday night.

Member

kohlhase commented Sep 7, 2016

I will need to upload two pdf's; however one of them could be reduced to

OK, I can do that, sounds reasonable.

What's your foreseen timeline?

The report is done in essence (still waiting for a contribution from @pdehaye ) and with the merging overhead, I expect that I will be done with everything by friday night.

@nthiery

This comment has been minimized.

Show comment
Hide comment
@nthiery

nthiery Sep 7, 2016

Contributor

On Wed, Sep 07, 2016 at 05:42:29AM -0700, Michael Kohlhase wrote:

The report is done in essence (still waiting for a contribution from
[1]@pdehaye ) and with the merging overhead, I expect that I will be
done with everything by friday night.

Great!

Contributor

nthiery commented Sep 7, 2016

On Wed, Sep 07, 2016 at 05:42:29AM -0700, Michael Kohlhase wrote:

The report is done in essence (still waiting for a contribution from
[1]@pdehaye ) and with the merging overhead, I expect that I will be
done with everything by friday night.

Great!

@kohlhase

This comment has been minimized.

Show comment
Hide comment
@kohlhase

kohlhase Sep 10, 2016

Member

@nthiery I made a first stub. Could you have a look whether this is sufficient?

Member

kohlhase commented Sep 10, 2016

@nthiery I made a first stub. Could you have a look whether this is sufficient?

@nthiery

This comment has been minimized.

Show comment
Hide comment
@nthiery

nthiery Sep 11, 2016

Contributor

I edited a bit the stub, and left two TODO's there. Once implemented, I believe this will do the job!

Contributor

nthiery commented Sep 11, 2016

I edited a bit the stub, and left two TODO's there. Once implemented, I believe this will do the job!

@kohlhase

This comment has been minimized.

Show comment
Hide comment
@kohlhase

kohlhase Sep 12, 2016

Member

I have extended the explanation. could you have another read?

Member

kohlhase commented Sep 12, 2016

I have extended the explanation. could you have another read?

@nthiery

This comment has been minimized.

Show comment
Hide comment
@nthiery

nthiery Sep 16, 2016

Contributor

On Sun, Sep 11, 2016 at 09:37:00PM -0700, Michael Kohlhase wrote:

I have extended the explanation. could you have another read?

Sounds very good. I have asked our PO whether this was ok. Thanks!

Contributor

nthiery commented Sep 16, 2016

On Sun, Sep 11, 2016 at 09:37:00PM -0700, Michael Kohlhase wrote:

I have extended the explanation. could you have another read?

Sounds very good. I have asked our PO whether this was ok. Thanks!

@nthiery

This comment has been minimized.

Show comment
Hide comment
@nthiery

nthiery Sep 16, 2016

Contributor

A more technical question: we want the github issue description for our deliverables to be helpful for our followers. One way to achieve this without duplication is to move the abstract of the report into the github issue description, which itself is included in the report. Is this something we want to do here? Systematically?
One little drawback is that we can't use our macros for cross linking other deliverables and tasks in the abstract.
What do you think?

Contributor

nthiery commented Sep 16, 2016

A more technical question: we want the github issue description for our deliverables to be helpful for our followers. One way to achieve this without duplication is to move the abstract of the report into the github issue description, which itself is included in the report. Is this something we want to do here? Systematically?
One little drawback is that we can't use our macros for cross linking other deliverables and tasks in the abstract.
What do you think?

@kohlhase

This comment has been minimized.

Show comment
Hide comment
@kohlhase

kohlhase Sep 17, 2016

Member

I like the idea of having the abstract of the reports in the issue description systematically.
But just to get this clear, this would be after the report was published, correct?
Or are you envisioning systematically going around and making up "abstracts" for upcoming deliverables? While this might be a useful exercise, I think it might be unrealistic.
But afterwards I see this as useful (BTW, do we have any evidence of followers other than the reviewers?).
More important than the abstracts, I find a link to the published report on the issue description. But the abstract would be very useful for searching.

Member

kohlhase commented Sep 17, 2016

I like the idea of having the abstract of the reports in the issue description systematically.
But just to get this clear, this would be after the report was published, correct?
Or are you envisioning systematically going around and making up "abstracts" for upcoming deliverables? While this might be a useful exercise, I think it might be unrealistic.
But afterwards I see this as useful (BTW, do we have any evidence of followers other than the reviewers?).
More important than the abstracts, I find a link to the published report on the issue description. But the abstract would be very useful for searching.

@nthiery

This comment has been minimized.

Show comment
Hide comment
@nthiery

nthiery Sep 19, 2016

Contributor

I moved the text of the report to the github description, finalized the later, and did minor proofreading edits.
This is ready to be submitted.

Contributor

nthiery commented Sep 19, 2016

I moved the text of the report to the github description, finalized the later, and did minor proofreading edits.
This is ready to be submitted.

@kohlhase

This comment has been minimized.

Show comment
Hide comment
@kohlhase

kohlhase Sep 20, 2016

Member

I have updated the authors to the ones of D6.2.

Member

kohlhase commented Sep 20, 2016

I have updated the authors to the ones of D6.2.

@nthiery

This comment has been minimized.

Show comment
Hide comment
@nthiery

nthiery Jan 4, 2017

Contributor

Submitted to the EU portal. Thanks!

Contributor

nthiery commented Jan 4, 2017

Submitted to the EU portal. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment