>>

1. Alignment on goals - recognition of the difference between "HBS" and "MIT" models of innovation. We (Megan, Chris, Jim) will remember the focus of producing a specific app for specific purpose, with a user story.	=
2. Alignment on method - Discord etc.	=
3. We are building an "IDE" for law - see https://law.mit.edu/pub/whatwouldanintegrateddevelopmentenvironmentforlawlooklike/release/2 An IDE needs to sit at the intersection of many approaches - including big data for clauses (https://lawgood.io/) The fit with algorithms and data sets for actual performance (Sandy Pentland, head of connection.mit.edu) https://law.mit.edu/pub/aperspectiveonlegalalgorithms/release/3. See also the piece with Thomas Hardjono (CTO there) which is a nuts-and-bolts presentation of Prose Objects as part of a secure decentralised data model http://hardjono.mit.edu/sites/default/files/documents/CommonAccord_Provenance_11182015.pdf.	=
4. It also can be understood to be a semantic web and should fit somehow into that ecosystem. Jim will be presenting Prose Objects at https://op.europa.eu/en/web/endorse/programme - a four-day conference on EU semantic web for legislation and court decisions. Sally Guyer (WorldCC) and Luigi Telesca (OTF and Trakti) will keynote one of the days. Jim's presentation briefly mentions this student project. https://docs.google.com/document/d/1W-k2_UoC2JoOP0-42t5yoxFkKS8NGwSCWUv_tGbZ_mY	=
5. Shawn's code:	=
/99/WiP/Schedule/String.py	=
This is fabulous. Jim tested it and found it worked perfectly, including in a number of edge cases. (Even variables with leading and trailing spaces such as { 6 }.)	=
The code is clear, readable, succinct. These are critical properties for an open solution.	=
Rendering fails if a key is not found. This seems right because it seems that the code for finding more dictionaries should handle the issue of failing to find a key as part of expanding the temporary dictionary. But I am only guessing about this relationship and leave it to you coders to make this choice. With help, I did a temporary way to handle a missing key (pasted below), but think that this is not part of the path forward.	=
It seems to me (Jim) that there are two ways of conceiving the issue of expanding the dictionary:	=
i) in the course of string expansion, a call is made to expand the dictionary or return the fact that the key can't be found. OR	=
ii) the goal is actually to create a temporary dictionary comprising all the dictionaries consulted during the process of attempting to fully expand a specified key	=	value. One possible output of this process is the expanded string. Another possible output is the temporary dictionary itself.
Is this good thinking?	=
Either way, it is exciting to have this code!	=
______________________________________________	=
	=
def find_value(key):	=
if not key in thisDict:	=
return key # maybe wrap this in html as error	=
	=
value	=	thisDict[key]
search	=	[x.group() for x in re.finditer(r'{(.*?)}', value)]
# End case	=
if len(search)	=	= 0:
return value	=
else:	=
for i in range(len(search)):	=
if search[i][1:-1] in thisDict:	=
new_val	=	find_value(search[i][1:-1])
else:	=
new_val	=	search[i]
value	=	value.replace(search[i], new_val, 1)
return value	=
print find_value("r00t")	=
	=
___________________________________________________________	=