Cathleen McGrath
Unafffiliated
Student Success Counselor at Colorado State University Global
I have a bachelor's degree in Political Science with a minor in Anthropology and I am 500 hour certified yoga teacher
80128
I have not donated any money to a campaign or political organization. Even though I understand that campaigns require substantial funds just to stay afloat, much less be success, I reject the notion of money in politics and refuse to participate in that fashion. I have however volunteered with various campaigns over the years opting to donate my time instead of my money.
During my attendance at MSU Denver (2016-2018) I was recipient of the Urban Leadership Scholarship and a member of the Urban Leadership Program and also sat on the committee for the university chapter of the American Democracy Project. Both organizations were fundamentally about meeting people where they are at, having engaged discourse with people of differing opinions, actively listening, being an advocate when necessary, and generally studying leadership in the areas of community, business and politics at a local, state and national level.
I have less practical experience in these areas and more knowledge from time studying representation and advocacy during my time studying political science in school and post-graduation. As a Student Success Counselor at CSU Global I have had many discussions with leadership, and continue to press on these issues, about how we can better serve our minority populations as an academic institution.
I want to serve on this commission because I believe the independent commission to be an pivotal step in the right direction to move away from partisan gerrymandering and towards honoring the principles of a fair electorate, which is why I voted in favor of this commission in the first place. Additionally, I am unaffiliated because I do not believe that we as a nation benefit from the strong two party system that has sprung up and fortified gross division in recent decades and for this reason I believe someone like myself, who is not aligned or beholden to a specific political party or agenda, to be the best fit for a commission such as this. I believe this is my chance to serve my community. I am always looking for ways to both use my passion and education in political science and to serve my community and I genuinely believe this commission to be that for me.
I find that the best way to build consensus or to create agreement among others is to very actively listen to and break apart each side of a debate as to understand where solutions can be made to draw the opposing sides together toward a middle ground. It is most important in situations such as with this commission to remove emotion and agenda from the equation and to allow reason and logic to be the guiding principles of decision making. When emotion and agenda is removed we are better suited to problem solve in a cogent that meets the reality of the problem at hand.
As a Student Success Counselor (aka Academic Advisor) I am often having to apply logic and analytical skills to solve student problems where there is often a lot of emotion involved for students, I am able to help break through that reactionary space and explain in a way that makes sense to the student different options so that they feel empowered to choose the best solution for themselves. Additionally, as student of Political Science my entire education was built around having to discuss topics that evoked a lot of passion and opinions in a way that maintained and honored the academic space we were in, this included working successfully in groups with students who were diametrically in opposition to my own political beliefs where we had to reach some kind of consensus for the purpose of completion.
Female


Sign Up
BIRTHDAY
GENDER
Already registered? Sign In
Already a member?
Sign in to your account
Remembe Me
Don’t have an account? SIGN UP
Connect With


{% extends 'layout.html' %} {% block body %}
That's it! You should now see a folder Dropbox/Apps/Easter Eggs
.
How to play:
Find the egg images in the Yard
folder - they could be hiding anywhere!
When you find one, add the image file to your Easter basket
folder. When you've found all five, come back here and click "Finished!"
Hmmm, doesn't look like you've found them all yet. Keep hunting!
{% endif %} {% endblock %}


|
SX126x-Arduino
2.0.1
|
#include <LoRaMac.h>
Data Fields | |
| DeviceClass_t | Class |
| eJoinStatus_t | IsNetworkJoined |
| bool | AdrEnable |
| uint32_t | NetID |
| uint32_t | DevAddr |
| uint8_t * | NwkSKey |
| uint8_t * | AppSKey |
| bool | EnablePublicNetwork |
| bool | EnableRepeaterSupport |
| ChannelParams_t * | ChannelList |
| Rx2ChannelParams_t | Rx2Channel |
| Rx2ChannelParams_t | Rx2DefaultChannel |
| uint16_t * | ChannelsMask |
| uint16_t * | ChannelsDefaultMask |
| uint8_t | ChannelNbRep |
| uint32_t | MaxRxWindow |
| uint32_t | ReceiveDelay1 |
| uint32_t | ReceiveDelay2 |
| uint32_t | JoinAcceptDelay1 |
| uint32_t | JoinAcceptDelay2 |
| int8_t | ChannelsDefaultDatarate |
| int8_t | ChannelsDatarate |
| int8_t | ChannelsDefaultTxPower |
| int8_t | ChannelsTxPower |
| uint32_t | UpLinkCounter |
| uint32_t | DownLinkCounter |
| MulticastParams_t * | MulticastList |
| uint32_t | SystemMaxRxError |
| uint8_t | MinRxSymbols |
| float | AntennaGain |
LoRaMAC MIB parameters
| DeviceClass_t uMibParam::Class |
LoRaWAN device class
Related MIB type: MIB_DEVICE_CLASS
| eJoinStatus_t uMibParam::IsNetworkJoined |
LoRaWAN network joined attribute
Related MIB type: MIB_NETWORK_JOINED
| bool uMibParam::AdrEnable |
Activation state of ADR
Related MIB type: MIB_ADR
| uint32_t uMibParam::NetID |
Network identifier
Related MIB type: MIB_NET_ID
| uint32_t uMibParam::DevAddr |
End-device address
Related MIB type: MIB_DEV_ADDR
| uint8_t* uMibParam::NwkSKey |
Network session key
Related MIB type: MIB_NWK_SKEY
| uint8_t* uMibParam::AppSKey |
Application session key
Related MIB type: MIB_APP_SKEY
| bool uMibParam::EnablePublicNetwork |
Enable or disable a public network
Related MIB type: MIB_PUBLIC_NETWORK
| bool uMibParam::EnableRepeaterSupport |
Enable or disable repeater support
Related MIB type: MIB_REPEATER_SUPPORT
| ChannelParams_t* uMibParam::ChannelList |
LoRaWAN Channel
Related MIB type: MIB_CHANNELS
| Rx2ChannelParams_t uMibParam::Rx2Channel |
Channel for the receive window 2
Related MIB type: MIB_RX2_CHANNEL
| Rx2ChannelParams_t uMibParam::Rx2DefaultChannel |
Channel for the receive window 2
Related MIB type: MIB_RX2_DEFAULT_CHANNEL
| uint16_t* uMibParam::ChannelsMask |
Channel mask
Related MIB type: MIB_CHANNELS_MASK
| uint16_t* uMibParam::ChannelsDefaultMask |
Default channel mask
Related MIB type: MIB_CHANNELS_DEFAULT_MASK
| uint8_t uMibParam::ChannelNbRep |
Number of frame repetitions
Related MIB type: MIB_CHANNELS_NB_REP
| uint32_t uMibParam::MaxRxWindow |
Maximum receive window duration
Related MIB type: MIB_MAX_RX_WINDOW_DURATION
| uint32_t uMibParam::ReceiveDelay1 |
Receive delay 1
Related MIB type: MIB_RECEIVE_DELAY_1
| uint32_t uMibParam::ReceiveDelay2 |
Receive delay 2
Related MIB type: MIB_RECEIVE_DELAY_2
| uint32_t uMibParam::JoinAcceptDelay1 |
Join accept delay 1
Related MIB type: MIB_JOIN_ACCEPT_DELAY_1
| uint32_t uMibParam::JoinAcceptDelay2 |
Join accept delay 2
Related MIB type: MIB_JOIN_ACCEPT_DELAY_2
| int8_t uMibParam::ChannelsDefaultDatarate |
Channels data rate
Related MIB type: MIB_CHANNELS_DEFAULT_DATARATE
| int8_t uMibParam::ChannelsDatarate |
Channels data rate
Related MIB type: MIB_CHANNELS_DATARATE
| int8_t uMibParam::ChannelsDefaultTxPower |
Channels TX power
Related MIB type: MIB_CHANNELS_DEFAULT_TX_POWER
| int8_t uMibParam::ChannelsTxPower |
Channels TX power
Related MIB type: MIB_CHANNELS_TX_POWER
| uint32_t uMibParam::UpLinkCounter |
LoRaWAN Up-link counter
Related MIB type: MIB_UPLINK_COUNTER
| uint32_t uMibParam::DownLinkCounter |
LoRaWAN Down-link counter
Related MIB type: MIB_DOWNLINK_COUNTER
| MulticastParams_t* uMibParam::MulticastList |
Multicast channel
Related MIB type: MIB_MULTICAST_CHANNEL
| uint32_t uMibParam::SystemMaxRxError |
System overall timing error in milliseconds.
Related MIB type: MIB_SYSTEM_MAX_RX_ERROR
| uint8_t uMibParam::MinRxSymbols |
Minimum required number of symbols to detect an Rx frame
Related MIB type: MIB_MIN_RX_SYMBOLS
| float uMibParam::AntennaGain |
Antenna gain
Related MIB type: MIB_ANTENNA_GAIN


MVC 1.0 Generator
Welcome to Jeddict! This tutorial provides a very simple and quick introduction to the MVC 1.0 application generator
by walking you through the creation of a simple MVC CRUD application.
MVC Generator makes it easy to develop Java EE 8 Enterprise applications.
The best thing, in minutes you get an application ready to deploy.
This tutorial takes less than 5 minutes to complete.
Table of Content :
Introduction to MVC 1.0 :
Model-View-Controller(MVC) is a common pattern in Web frameworks where it is used commonly to build HTML applications.
The model refers to the application's data, the view to the application's data presentation and
the controller to the part of the system responsible for managing input, dispatching each request to appropriate handlers,
updating models, resolving views and finally returning the response.
MVC 1.0 framework is built on top of JAX-RS and integrates with CDI and Bean Validation.
A controller is responsible for processing incoming requests. It invokes business logic,
updates the model and returns the view that should be rendered.
Prerequisite :
The requirements for this tutorial are:
- Java 1.8
- NetBeans 8.1
- Jeddict 1.5.5
- GlassFish 4.1 / Payara 4.1
- Ozark 1.0.0-m02
Although Java EE 8 is not yet released, it is possible to use MVC framework already in some Java EE 7 servers,
as the reference implementation of the MVC specification named
Ozark is complete.
Ozark is currently not part of GlassFish / Payara,
so the scope must be set to runtime in pom.xml with maven dependencies to ensure it is bundled with your application
(as shown in next section).
Note :
A small issue: caused by higher version number in NetBeans, The issue is already addressed and can be easily fixed by renaming a JAR in the distribution:
mv glassfish/lib/install/applications/__admingui/WEB-INF/lib/console-core-4.1.151.jar
glassfish/lib/install/applications/__admingui/WEB-INF/lib/console-core-4.1.jar
Setting Up the Project :
To create an IDE project:
- Start NetBeans IDE.
- In the IDE, choose File > New Project(Ctrl-Shift-N) from the main menu, as shown in the figure below :
- In the New Project wizard, expand the Maven category and select Web Application as shown in the figure below. Then click Next.
- Enter ShoppingSystem in the Project name text box and specify the Project Location to any directory on your computer and click next (as shown in the figure below):
- Select the version of Java EE you want to use with your application and
the server to which you want to deploy your application.
- Click Finish.
Create the JPA Diagram :
- Goto File menu > New File > Persistence category.
- From the Persistence , select JPA Diagram and click Next.
- Type CartModel for the diagram name and Browse the location in project.
- Click Finish.
- When you click Finish, the IDE creates the JPA Diagram and opens the diagram in the designer window.
Create the Entities :
- Drag & Drop the Entity from the Palette window to designer.
- Double click on the Entity and rename to Customer.
Add properties and validation :
- To create
@Basic
attribute, click on the Customer Entity ,
then click on the expand button > basic property.
-
Validation annotations like @Size, @NotNull and so on can be added to the respective entity fields by using
Jeddict Diagram > property panel > bean validation.
As shown below :
- Same as above create some other entities and properties (for more information click here).
Generate the entity classes :
- Right click on the diagram > Generate Source Code or (ctrl + G)
Business Service :
Click on the Business Service > select Session Facade.
In the following screen, you can configure the SessionBean package and class name pattern for the EJB facade
that will be created for your application:
-
MVC Controller :
Click on the Controller > select MVC 1.0
Implement the Controller:
In the following screen, you can configure the Controller package and class name pattern for the MVC 1.0
that will be created for your application:
A simple Java EE MVC Controller looks like this:
The @Controller
annotation can be used on methods and classes :
-
When used on classes, all methods of the class are considered as controllers.
-
Classes with Controller methods are CDI managed beans called Hybrid class
(contains a mix of JAX-RS resource methods and MVC controllers).
You can make it Hybrid class by enabling following option :
Return types
There are lots of different return types when working with @Controller methods or classes.
A controller’s method return type determines how its result is processed.
In the following screen, you can define the Controllers return type:
void:
A controller method that returns void
is REQUIRED to be annotated with the @View
annotation.
The following snippet shows this one.
it's more clear because it well separates the corresponding view from the controller logic within the controller method.
String:
A String
returned is interpreted as a view path.
The return value of this method is the path to the corresponding view.
Viewable:
A Viewable
is a MVC class that encapsulates a view path as well as additional information related to its processing
like references to Models
or CDI-based models or ViewEngine
objects
Response:
A JAX-RS Response whose entity’s type is one of the above.
A JAX-RS return type gives you all access to HTTP responses and their headers.
In these return types, String and void are the simplest they should be the preferred ones.
Nevertheless there are other use cases where the Response and the Viewable return type are necessary and useful(as defined above).
Security :
Guarding against malicious attacks is a great concern for web application developers. Two of the most common
forms of attacks cross-site request forgery (CSRF) and cross-site scripting (XSS) can prevented by following option :
Built-in Events :
Using following options MVC application can be informed of important events that
occur while processing a request. This mechanism is based on CDI events that
can be fired by implementations and observed by applications.
Observing events can be useful for applications to learn about the lifecycle of a request, perform logging,
monitor performance etc.
Bean Validation :
Handling form validations in MVC 1.0 is pretty simple. Using the following option NetBeans will add the javax.mvc.binding.BindingResult
class
(which has to be used to handle validation errors) as a property in the controller class
and add error handling to the controller method by using the injected BindingResult reference.
Configure the application:
To create our MVC application we also need a JAX-RS Application class:
The subclass of javax.ws.rs.core.Application
can be used to define additional JAX-RS components.
In the following screen, you can configuration @ApplicationPath
(that define the base path for our application) and class name.
-
Viewer :
One of the best things about MVC is that it actually doesn't matter what view technologies it supports out of the box.
Why? Because it is so easy to integrate any view technologies with MVC.
Click on the Viewer > select JSP >
In this tutorial, NetBeans will generate a set of JSP pages (create.jsp, update.jsp, list.jsp and view.jsp) that are used to handle every possible scenario.
In the following screen, you can configure the JSP template location inside the web project and you can also define whether the
script and style-sheet files (Twitter Bootstrap, jQuery etc.) should be offline or online(cdnjs) :
-
Now, click on the Generate button.
Inspecting The Generated Code :
NetBeans has generated multiple files under source packages and under Web Pages.
Here is a break-down of what was created:
Java source structure of this project seems like below.
Deploy :
Output :
- Home page opened by NetBeans IDE after deployment.
-
Click on Product ui component (currently no data exist) :
- Click on Add+ button to create new Product :
-
Product created and returned to data table :
-
Same as above create another Product and Customer entry and move to Home Page by Dashboard :
Download Sample Project :
Click here
Have fun with your MVC 1.0 application :)


Haumea
Facts
- Haumea's shape is ellipsoid. This shape is believed to be the result of its rapid rotation.
- Orbital Period: 284.1 Earth Years
- Radius: ~620km
- Discovered by Brown et al.; Ortiz et al. (neither official)
- Discovery date 2004 December 28 (Brown et al.); 2005 July 27 (Ortiz et al.)
- Average orbital speed: 4.531 km/h.
- Known Sattelites: 2 (Namaka, Hi'iaka) and ring
- Temperature: <50K
- A day: 4 hours
History
- In 2005, the Gemini and Keck telescopes obtained spectra of Haumea which showed strong crystalline water ice features similar to the surface of Pluto's moon Charon.[16] This is peculiar, because crystalline ice forms at temperatures above 110 K, whereas Haumea's surface temperature is below 50 K, a temperature at which amorphous ice is formed.[16] In addition, the structure of crystalline ice is unstable under the constant rain of cosmic rays and energetic particles from the Sun that strike trans-Neptunian objects.
- However, further studies of the visible and near infrared spectra suggest a homogeneous surface covered by an intimate 1:1 mixture of amorphous and crystalline ice, together with no more than 8% organics.
- The absence of measurable methane in the spectra of Haumea is consistent with a warm collisional history that would have removed such volatiles, in contrast to Makemake.

Highlights
- Ring: This planet has a ring. That's it.
- Years: An orbital period takes 284.8 earth years. It means sooo long.
- Shape: How many ellipsoid planets have you been? Let us answer, 0.
Precaution
- Don't forget to bring your helmet!
- For researchers, please be careful on this planet. The gravity makes a mess.


d2l-activity-list-item (default)
d2l-activity-list-item (course)
d2l-activity-list-item (learning path)
d2l-activity-list-item (mixed)
d2l-activity-list-item-accumulator
Note that the move function must be added to the collection observing the item reorders.


Written statement to Parliament
Written ministerial statement by the Secretary of State for Education Nicky Morgan on the School Teachers' Review Body's 26th report.
The 26th report of the School Teachers’ Review Body ( STRB ) is being published today. Its recommendations cover the remit that I issued in October 2015. The report contains recommendations on how to apply the pay award for teachers that is due to be implemented from September 2016. Copies of the STRB ’s 26th Report are available in the Vote Office, the Printed Paper Office and the Libraries of the House, and online at www.gov.uk.
The STRB has recommended a 1% uplift from September 2016 to the minima and the maxima of all classroom teacher and leadership pay ranges in the national pay framework, and to classroom teacher allowances (teaching and learning responsibility ( TLR ) payments and special educational needs ( SEN ) allowances). It has also recommended the school teachers’ pay and conditions document ( STPCD ) be amended to make clear that schools can use a salary advance scheme for rental deposits as part of the existing recruitment and retention incentives and benefits. In addition, it has recommended that my department should develop good practice guidance to help schools make effective use of their existing flexibility to tailor pay policies to meet local recruitment and retention needs in a competitive labour market.
A full list of the recommendations is attached as an annex.
My officials will write to all of the statutory consultees of the STRB to invite them to contribute to a consultation on my acceptance of these recommendations. The consultation will last for 4 weeks.
I am grateful to the STRB for these recommendations and, subject to the views of consultees, I intend to accept all the key recommendations.
My detailed response contains further information on these matters.
School Teachers’ Review Body’s ( STRB ’s) recommendations and response from the Secretary of State for Education (Nicky Morgan).
[The following sets out the full set of recommendations from the STRB as published in the 26th Report (CM 9302) on 6 July 2016, together with the response from the Secretary of State for Education.]
The Secretary of State for Education (Nicky Morgan): The 26th Report of the STRB is being published today. It covers matters referred to the STRB in October 2015. Copies are available in the Vote Office, the Printed Paper Office and in the Libraries of the House and online at www.gov.uk.
In making its recommendations, the STRB was asked to consider the adjustments that should be made to the salary and allowance ranges for classroom teachers, unqualified teachers and school leaders to reflect the average of up to 1% pay award for public sector workers.
In addition, the STRB was asked to consider:
In making its recommendations, the STRB was asked to consider:
I am grateful for the in-depth consideration which the STRB has given to this important matter. I am inviting comments on the STRB ’s report and my response to its recommendations by 2 August 2016.
The STRB has recommended:
Finally I will want to ensure that we have had due regard to equalities considerations before confirming the government’s response. I would welcome consultees’ views on these matters also.
Published: 6 July 2016


Event Charter Fleet
-
Home
-
Events
-
Event Charter Fleet
About the Azure Seas Motor Yacht
- Length: 73 feet
- Beam: 19 feet, 6 inches
- Displacement: 60,000 pounds
- Cruising Speed: 9 knots
- Maximum Speed: 12 knots
- Capacity: 46 passenger & 4 crew
Yacht Features and Amenities
- Pilot house seating for 4 right behind captain
- Portugese bridge in front of pilot house seats 4-6
- Upper deck has seating for up to 14
- Main salon with full bar, 3 large tables & buffet area
- Large bow for weddings and group photos with seating for 15
- Captain can perform marriages
Available for 4 to 8 hours
About the Captain
With 40+ years of experience in both pleasure and commercial vessels, Captain Fred Hershman has spent his entire life on or near boats. Growing up with his father on a 51-foot ketch sailboat and serving in the Coast Guard from 1968 to 1974. He's a decorated veteran from the Vietnam War and holds a 100-ton captain's license.
(note: please visit our store for motor yacht charter pricing)
About the Channel Cat Motor/Sail Yacht
- Length: 85 feet
- Beam: 41 feet
- Displacement: 107,000 pounds
- Cruising Speed: 12 knots
- Maximum Speed: 14 knots
- Capacity: 149 passenger & 4 crew
Yacht Features and Amenities
- Large 35' x 60' salon with 10' 5" ceiling for entertaining
- 35' birds eye maple bar with brass handles
- Satellite navigational software built-in
- Library/Media room and 5 televisions throughout
- Audio/Video system with Dolby Surround Sound
- All electric commercial galley
Available for 4 to 8 hours
About the Captains
All captains are United States Coast Guard licensed with years of experience cruising the Santa Barbara Coast and Channel Islands as well as, in many cases, all over the world.
(note: please visit our store for motor yacht charter pricing)
About the Grand Times Motor Yacht
- Grand Banks Motor Yacht
- Length: 57 feet
- Beam: 18 feet, 6 inches
- Draft: 6 feet, 0 inches
- Displacement: 100,000 pounds
- Fuel Capacity: 1,500 Gallons
- Water Capacity: 900 Gallons
- Cruising Speed: 9 knots
- Maximum Speed: 11 knots
Yacht Features and Amenities
- 1 master stateroom, 1 bathroom with shower and bathtub
- 2 guest staterooms with separate bathrooms
- Separate crew quarters
- Teak and mahogany interior
- Teak decks
- 1 Generator (15KW) and 1 Generator (8KW)
- State of the art electronics & stereo
- Heating throughout
- 4-burner propane stovetop and electric convection oven
- Full-size refrigerator/freezer
- 1 ice maker
- BBQ
- Transom hot shower
- 15 Ft 60 HP Tender RIB center console
- 6 Kayaks
- 2 Stand Up Paddleboards
Available for 4 hours to 4 days/3 nights
About the Captain
Paul Noury is a United States Coast Guard 100-ton licensed captain. He has been living in the Santa Barbara Harbor and cruising the Channel Islands since 1993. Paul started sailing as a child in his native France and was a sailing instructor in the French. He has extensive captaining and cruising experience on the entire east and west coasts of the United States, as well as Mexico, Central America, the Mediterranean and the Caribbean Sea. Paul’s previous work includes Activities Director for the Four Seasons Resort and well as Operations Director for Adventours Outdoor Excursions giving him an edge on running a first class charter operation. With a degree in Physical Education, Paul loves sharing his extensive knowledge and passion for mother nature and ocean adventures, whether they be by yacht, kayak, paddleboard or tender.
(note: please visit our store for motor yacht charter pricing)
About the Jenny Lane Motor Yacht
- Length: 50 feet
- Beam: 14 feet, 6 inches
- Draft: 5 feet, 9 inches
- Displacement: 36,000 pounds
- Fuel Capacity: 88 Gallons
- Water Capacity: 500 Gallons
- Cruising Speed: 7 knots
- Maximum Speed: 11 knots
Yacht Features and Amenities
- 4 staterooms (with closets), 4 bathrooms with separate crew quarters
- Interiors are finished with hand rubbed varnished teak with light ash trim
- Corian counter tops in the galley and bathrooms
- High gloss epoxy cabin floors
- State of the art electronics & stereo
- Oven and stove
- BBQ
- Refrigerator
- Kayaks (optional)
- Stand Up Paddleboards (optional)
Available for 4 hours to 7 days/6 nights
About the Captains
All captains are United States Coast Guard licensed with years of experience cruising the Santa Barbara Coast and Channel Islands as well as, in many cases, all over the world.
(note: please visit our store for motor yacht charter pricing)
Click on the dropdown menu from the events tab at the top of the page to see details about the event options offered through Shoreline Summit Adventures.


the most recent and referenced textbook in programming languages for software developers
Semantics is the decoration of parse trees/ASTs (which is the process of evaluating attributes, which can be either synthesized or inherited)
Since decoration is the addition of a new layer (a semantic layer) on top of a base layer (a syntactic one), then this leads to some sort of meta-programming. It happens at a higher level, indeed, but it is still restrained to the fact that it is, indeed, programming (therefore syntax based?).
Attribute grammars do not really specify the meaning of a program; rather,they provide a way to associate a program with something else that presumablyhas meaning (p.167)
There are two approaches:
synthesized: attributes are given only on the left side inherited: attributes are calculated on the right side, and depend on the current context


facebook
|
<EMAIL_ADDRESS>CITY SERVE LOGO HERE
Home
About
Projects
Partners
One United Church
City Serve
Recent Projects


---
layout: post
title: "Generative Models for few-shot Prediction Tasks"
subtitle: "Marta Garnelo
Research Scientist, DeepMind"
date: 2018-11-26 19:00:0 +0000
background: '/img/posts/gqn.png'
future_date: False
layer_shift: True
---
Few-shot density estimation lies at the core of current meta-learning (or ‘learning to learn’) research and is crucial for intelligent systems to be able to adapt quickly to unseen tasks. In this talk we will introduce generative query networks (GQN - published in Science this year), a generative model for few-shot scene understanding that learns to capture the main features of synthetic 3D scenes. In the second half of the talk we will cover neural processes (NPs), a generalisation of the GQN training regime to a wider range of tasks like regression and classification. NPs are inspired by the flexibility of stochastic processes such as Gaussian processes, but are structured as neural networks and trained via gradient descent. We show how NPs make accurate predictions after observing only a handful of training data points, yet scale to complex functions and large data sets.


|
This document explains how to set up a new web editor application from scratch, and how to create web editor applications using the Web Editor Framework. Its goal is to teach you the main concepts in the framework so that you can develop your own applications using only the reference documents for support.
Since the Web Editor Framework is an extension of the Navigator Framework it is assumed that you are already familiar with the Navigator Framework. If you are not, you are recommended to start with the Navigator Framework Developer's Guide before continuing with this document.
The Web Editor Framework is a JSP-based framework for developing web applications where the users can modify the contents of a topic map using a forms-based interface. This is done by writing JSP pages which produce HTML pages containing ordinary HTML forms. These forms and the fields in them are connected to actions on the server side which are triggered when the form is submitted.
The actions triggered by a submitted form can create new constructs in the topic map, delete old ones, modify existing ones, and generally do anything you want. The Web Editor Framework comes with an extensive library of actions, documented in The Web Editor Framework: Action Library Reference. In addition, you can easily develop your own and use them in your applications.
In order to get an overview of how the web editor framework actually works, let's walk through one editing operation to see what happens at each stage of the process. The first step is that the user selects a page in the web application, which is then generated in the same way that it would be with the navigator framework. The diagram below shows how this happens.
Figure 1. Editor page generated
The diagram above shows a page being generated by a JSP page on the server and loaded into the browser, where it consists of three form fields and a button. Each of the three form fields is connected with a topic map object on the server-side, in this case a topic name, a topic, and an occurrence. The objects are passed as parameters to the actions, and the framework keeps track of the correspondence between input field names and actions+parameters on the server side.
The next step after this is for the user to edit the information in the form, and then press the "Submit" button. When this happens, the form is submitted back to the ProcessServlet in the web editor framework, which handles the processing of the form. This is done as shown in the diagram below.
Figure 2. Receiving a submitted form
The ProcessServlet when receiving the form will invoke the action group that is connected with the form and pass the form data as well as the parameters provided by the page to the action group. The actions will then be invoked, modifying the topic map, and that completes the editing operation.
There is, however, one more step, and that is to decide what page the user is going to see now. The forwarding logic of the web editor framework is used to decide this, based on configuration provided by the developer. (More on this later.)
Now that the key concepts involved in developing applications with the web editor framework have been introduced we will move on to show how you can build such applications by developing an example.
In order to keep the application simple we will be developing an editor for a topic map that is essentially a project plan, consisting of tasks to be performed, and information about these. For each task, we have a name, tasks it depends on, a person responsible for the task, a deadline date, and a priority. The editing application will allow you to add new tasks, change existing tasks, and so on.
Before we can start building the application, however, we have to set up the environment in which it is to run. We will walk through this step by step, and the diagram below shows a graphical view of the structure we will create.
Figure 3. The directory structure
The first step is to create the directory shown as 'webapp' in the diagram, a directory called $TOMCAT_HOME/webapps/tasked, and inside it, another called WEB-INF. The next step is to copy and paste the example below into a file called web.xml and to put this in the WEB-INF directory.
A minimal web.xml file
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <display-name>TaskEditor</display-name> <description>Simple example topic map web editor application.</description>  <context-param> <param-name>log4j_config</param-name> <param-value>../omnigator/WEB-INF/config/log4j.properties</param-value> <description> Tells the web editor where to find the log4j configuration file. </description> </context-param> <context-param> <param-name>app_config</param-name> <param-value>WEB-INF/config/application.xml</param-value> <description> Tells the web editor where to find the application configuration file. </description> </context-param> <context-param> <param-name>action_config</param-name> <param-value>WEB-INF/config/actions.xml</param-value> <description> Tells the web editor where to find the action configuration file. </description> </context-param> <context-param> <param-name>source_config</param-name> <param-value>../omnigator/WEB-INF/config/tm-sources.xml</param-value> <description> Tells the web editor where to find the topic map sources configuration file. </description> </context-param>  <servlet> <servlet-name>WebEditorProcessServlet</servlet-name> <description>Controller Servlet getting in all requests</description> <servlet-class> net.ontopia.topicmaps.webed.servlets.ProcessServlet </servlet-class> </servlet> <servlet-mapping> <servlet-name>WebEditorProcessServlet</servlet-name> <url-pattern>/process</url-pattern> </servlet-mapping>  <session-config> <session-timeout>30</session-timeout> </session-config> <welcome-file-list> <welcome-file>index.jsp</welcome-file> <welcome-file>index.html</welcome-file> </welcome-file-list> </web-app>
The next step is to create the start page for the application. A first version of this page is given below.
The index.jsp page

The task editor

Here is the task editor!

At this point you can start the Tomcat server and connect to http://localhost:8080/tasked/ to see the start page.
The next step is to make sure that we have the necessary configuration and are able to load the topic map. To do this, create a directory called WEB-INF/config, then put the contents of the example below into a file called application.xml.
A minimal application.xml file
<configuration type="application"> <properties> <property name="defaultCharacterEncoding" value="utf-8"/> <property name="allowLoadOnRequest" value="true"/> </properties> </configuration>
Once this is done, the next step is to check if the tasks.ltm file is present in ${ONTOPIA_HOME}/topicmaps, since we have told our web application to get its topic maps from there (by using the omnigator tm-sources.xml). Now everything is ready, and we can start using the tag libraries.
The first step is to update the index.jsp page as shown below.
The new index.jsp page
<%@ page contentType="text/html; charset=utf-8" %> <%@ taglib uri='http://psi.ontopia.net/jsp/taglib/tolog' prefix='tolog' %> <tolog:context topicmap="tasks.ltm"> <title>The task editor</title>
The task editor

Create new task <tolog:foreach query="instance-of($TASK, task)?">
<a href="task.jsp?id=<tolog:id var="TASK"/>"><tolog:out var="TASK"/> </tolog:foreach>

Create new person <tolog:foreach query="instance-of($PERSON, person)?">
<a href="person.jsp?id=<tolog:id var="PERSON"/>"><tolog:out var="PERSON"/> </tolog:foreach>

 </tolog:context>
So far we have only created an ordinary navigator application, and the time has now come to start making this into a web editor application. The first step would be to implement the page for editing individual people, which is what we do in the next section.
Once this is set up we are ready to create the page for editing "person" topics. The contents of this page are shown in the example below. (Note that it cannot be loaded before we have added one more file.)
The person.jsp page
<%@ page contentType="text/html; charset=utf-8" %> <%@ taglib uri='http://psi.ontopia.net/jsp/taglib/tolog' prefix='tolog' %> <%@ taglib uri='http://psi.ontopia.net/jsp/taglib/webed' prefix='webed' %> <tolog:context topicmap="tasks.ltm"> <tolog:set var="person" reqparam="id"/> <tolog:set var="name" query="topic-name(%person%, $NAME)?"/> <title>Editing '<tolog:out var="person"/>'</title>
Editing '<tolog:out var="person"/>'
 <webed:form actiongroup="person">
Name <webed:field action="set-name" params="name person" type="tfs"> <tolog:if var="name"><tolog:out var="name"/></tolog:if> </webed:field>
 <webed:button action="person" text="Change"/> <webed:button action="delete-person" text="Delete" params="person"/> </webed:form> </tolog:context>
The interesting parts of this page are the webed tags which set up the form used to change the name of the person. The main tag is the webed:form tag, which creates the form in which all of the components are placed. The actiongroup attribute gives the name of the action group which will handle the form when it is submitted. This action group is declared in the actions.xml file, which will be explained shortly.
The next part of interest is the webed:field tag, which creates a text input field. The content of the tag produces the initial content of the field, and the value that the user writes there will be set as the new value of the name. The action attribute gives the name of the action which will handle this form field when the form is submitted (the set-name action is declared in the actions file), while the type attribute tells the tag what template to use for this field (also declared in the actions file).
A very important attribute is the params attribute which contains the names of variables that will be passed to the action when the form is submitted. The first parameter holds the base name that is to be modified. This is necessary in order for the action to know which topic name to modify. The second parameter holds the topic that owns the topic name in case the base name has not been created yet. The action will then create a new base name, but will need to know what topic to attach it to.
Finally, we produce two buttons for the user to press. Each of these have actions associated with them (given in the action attribute) as well as objects (in the params attribute) and a label for the button (in the text attribute). The first button submits the changed page to the editor, while the second button deletes the current topic. (This is why the second button needs the current topic as a parameter: it needs to know what topic to delete.)
The result, once we add the actions file, will be the page shown in the diagram below.
Figure 4. Editing a person
The last piece necessary to make this work is the actions.xml file, to be added to the WEB-INF/config directory as shown below.
The actions.xml file
<actionConfig>  <classMap> <class shortcut="DummyAction" fullname="net.ontopia.topicmaps.webed.impl.actions.DummyAction"/> <class shortcut="ActionTopicMapCreateTopic" fullname="net.ontopia.topicmaps.webed.impl.actions.topicmap.CreateTopic"/> <class shortcut="ActionSetBasenameValue" fullname="net.ontopia.topicmaps.webed.impl.actions.basename.SetValue"/> <class shortcut="ActionDelete" fullname="net.ontopia.topicmaps.webed.impl.actions.tmobject.Delete"/> <class shortcut="ActionSetOccValue" fullname="net.ontopia.topicmaps.webed.impl.actions.occurrence.SetValue"/> <class shortcut="AssignRolePlayer" fullname="net.ontopia.topicmaps.webed.impl.actions.association.AssignRolePlayer"/> </classMap>  <fieldMap> <field name="tfs" type="text" columns="39" maxlength="255"/> <field name="tfm" type="text" columns="50" maxlength="255"/> <field name="tfl" type="textarea" columns="50" rows="3"/> </fieldMap>  <globalForwards> <forward name="frontpage" path="index.jsp"/> </globalForwards>  <actionGroup name="person">  <action name="set-name" class="ActionSetBasenameValue"/>  <action name="person" class="DummyAction"/> <action name="delete-person" class="ActionDelete" exclusive="true"/>  <forwardRules> <forwardDefault path="person.jsp"/> <forwardRule action="delete-person" forward="frontpage"/> </forwardRules> </actionGroup> </actionConfig>
The first part of the file (the classMap) declares shorter names for the Java classes used in the rest of the file. After this comes a declaration of the field types referenced from the webed:field tag (the fieldMap part).
After this follows global forwarding rules used by the ProcessServlet to decide where to send the user in cases where the action group does not declare explicit rules. In this case the only declaration we have is that the frontpage name is an alias for the index.jsp page. The idea with this is that it makes it possible to change the front page without having to change all forwarding rules that point to this page in the whole application.
Finally comes the declaration of the action group which corresponds to our page for editing "person" topics. The first declares our input field and maps it to the ActionSetBasenameValue action. This action takes a topic name object and sets its string value to that passed from the input field when the form is submitted.
The next is two actions, which correspond to the two buttons we declared. The first is the DummyAction, which is used for the "Submit" button, and which does nothing (the other actions take care of everything when you press this button). The second is the ActionDelete, which deletes a topic from the topic map.
Note that the delete-person action has been defined as exclusive. What this means is that if this action is triggered only it should run, and no other actions. This ensures that we don't waste time updating a topic that is to be deleted anyway, and also avoids problems if the delete-person action is not executed last (the other actions will then attempt to update objects which are no longer there). The last problem could be solved in this case by placing the action last in the group (since actions are executed in the order they are given), but this is not always possible.
Finally, we have the forwarding rules. The default is for the user to get the same person.jsp page back, but if the delete-person action is triggered we go to the front page instead.
And that's it. This is a complete page for editing topics of a particular type. You've now seen the main parts of the framework, and the rest of this guide is just about how to handle more kinds of situations.
The next step is to make it possible to create new people. To do this we need to modify the start page so that we can trigger action groups on the server that contain the necessary actions. This is done by creating little forms whose buttons trigger create actions. The new start page is shown below.
The new index.jsp
<%@ page contentType="text/html; charset=utf-8" %> <%@ taglib uri='http://psi.ontopia.net/jsp/taglib/tolog' prefix='tolog' %> <%@ taglib uri='http://psi.ontopia.net/jsp/taglib/webed' prefix='webed' %> <tolog:context topicmap="tasks.ltm"> <tolog:set var="topicmap" query="topicmap($TM)?"/> <tolog:declare> using t for s"#" </tolog:declare> <title>The task editor</title>
The task editor

<webed:form actiongroup="create-task"> <webed:button action="create-task" params="topicmap t:task" text="Create task"/> </webed:form> <tolog:foreach query="instance-of($TASK, task)?">
<a href="task.jsp?id=<tolog:id var="TASK"/>" ><tolog:out var="TASK"/> </tolog:foreach>

<webed:form actiongroup="create-person"> <webed:button action="create-person" params="topicmap t:person" text="Create person"/> </webed:form> <tolog:foreach query="instance-of($PERSON, person)?">
<a href="person.jsp?id=<tolog:id var="PERSON"/>" ><tolog:out var="PERSON"/> </tolog:foreach>

 </tolog:context>
The only change here is that we have added buttons to create new topics, and provided them with parameters: the containing topic map, and the type of the new topic, in that order. Note how the second parameter has a name beginning with t: in both cases; this makes use of the tolog URI prefix we declared with tolog:declare to refer to the topic type without having to create a variable for it. Using this parameter we can actually create topics that are instances of "person" and "task" as opposed to completely blank topics.
For this to work we need to add two more action groups after the first one in actions.xml:
Two new action groups
 <actionGroup name="create-person"> <action name="create-person" class="ActionTopicMapCreateTopic"/>  <forwardRules> <forwardDefault path="person.jsp"/> </forwardRules> </actionGroup>  <actionGroup name="create-task"> <action name="create-task" class="ActionTopicMapCreateTopic"/>  <forwardRules> <forwardDefault path="task.jsp"/> </forwardRules> </actionGroup>
Notice how in both cases we forward the user onto the page for editing topics of the given type, so that having created the topic we can edit it immediately. (The framework takes care of setting the right request parameters to pass the object ID to the editing pages.)
The next step is to start editing tasks, and this can be done quite easily by taking person.jsp as the starting point. This enables us to edit the name of the task, and then we only have to add the rest. As a first step we will add a description occurrence and an association to the person responsible for the task. The resulting JSP is shown below.
The task.jsp page
<%@ page contentType="text/html; charset=utf-8" %> <%@ taglib uri='http://psi.ontopia.net/jsp/taglib/tolog' prefix='tolog' %> <%@ taglib uri='http://psi.ontopia.net/jsp/taglib/webed' prefix='webed' %> <tolog:context topicmap="tasks.ltm"> <tolog:set var="task" reqparam="id"/> <tolog:declare> using t for s"#" </tolog:declare> <title>Editing '<tolog:out var="task"/>'</title>
Editing '<tolog:out var="task"/>'
 <webed:form actiongroup="task"> <tolog:set var="name" query="topic-name(%task%, $TN)?"/> <tolog:set var="description" query="occurrence(%task%, $OCC), type($OCC, description)?"/> <tolog:set var="people" query="instance-of($PERSON, person)?"/> <tolog:set var="person" query="assigned-to(%task% : assignment, $P : responsible)?"/> <tolog:set var="assign-assoc" query="select $A from role-player($R, %task%), association-role($A, $R), type($A, assigned-to)?"/>

Name <webed:field action="set-name" params="name task" type="tfs"> <tolog:if var="name"><tolog:out var="name"/></tolog:if> </webed:field>
Description <webed:field action="set-int-occurrence" type="tfs" params="description task t:description"> <tolog:if var="description"><tolog:out var="description"/></tolog:if> </webed:field>
Responsible person <webed:list action="assign-player" params="assign-assoc t:assigned-to task t:assignment t:responsible" collection="people" selected="person"/>
 <webed:button action="task" text="Change"/> <webed:button action="delete-task" text="Delete" params="task"/> </webed:form> </tolog:context>
On this page we've added a second webed:field for the description occurrence. This is very similar to that for the name, but uses a different action and also adds a parameter, so that the action can give the occurrence its type, if it has to create it for us.
The responsible person, however, is different, since in this case we don't want a text field, but a list of alternatives. This is done with the webed:list tag, which is similar to webed:field, but adds some new things. Here, we no longer produce the contents of the list using tolog:* tags, but instead pass it a variable containing the alternatives (this is what the collection attribute does). This is used by the tag to produce a drop-down list. The optional selected attribute holds the currently selected topic, if there is one.
The action used in this case will take an association as its object and assign a player to a specific role, creating the association if it does not already exist. This is why the params attribute contains so many values. The values are, in order, the association type, the role player on this side, the role of this topic, and the role of the topic being selected. This information is used both to select the right role to assign to and also to create new associations, if necessary.
At this point, the only thing that remains is to update the actions file with the action group for this page, as shown below.
Action group for tasks
 <actionGroup name="task">  <action name="set-name" class="ActionSetBasenameValue"/> <action name="set-int-occurrence" class="ActionSetOccValue"/> <action name="assign-player" class="AssignRolePlayer"/>  <action name="task" class="DummyAction"/> <action name="delete-task" class="ActionDelete" exclusive="true"/>  <forwardRules> <forwardDefault path="task.jsp"/> <forwardRule action="delete-task" forward="frontpage"/> </forwardRules> </actionGroup>
At this point the application is usable, if not very useful. Most of what remains is more of the same as what you have already seen, so the design of the application from this point on will be aimed more at showing you new aspects of the framework than at creating something useful.
It should be possible for a task to have dependencies on other tasks, and, most importantly, on any number of tasks. This means that we have to handle this association rather differently from the association between the task and the responsible person. It must be possible to create new associations as well as to delete old ones. Luckily, the AssignRolePlayer action is designed in such a way as to make this quite easy.
Adding the following code to the task.jsp page provides support for editing dependencies:
Editing dependencies
 <tolog:set var="tasks" query="instance-of($TASK, task), $TASK /= %task%?"/> <%-- make empty variable --%> <tolog:set var="empty"/>
Depends on <tolog:foreach query="role-player($R1, %task%), type($R1, after), association-role($ASSOC, $R1), association-role($ASSOC, $R2), type($R2, prior), role-player($R2, $OTHER)?"> <webed:list action="assign-player" params="ASSOC t:depends-on task t:after t:prior" collection="tasks" selected="OTHER"/>
 </tolog:foreach> <webed:list action="assign-player" params="empty t:depends-on task t:after t:prior" collection="tasks"/>

This code produces one drop-down list for each existing dependency association and afterwards adds one more drop-down list that can be used to create a new association. All of these lists are mapped to the AssignRolePlayer action. In the case of the drop-down lists for existing associations selecting a new topic will change the association, while selecting "Unspecified" will cause the association to be deleted. Similarly, if the user does not select a topic in the last drop-down list no association will be created. If the user does select one, however, an association will be created.
Note that all of this behaviour (creation, modification, and deletion of the association) is implemented by the AssignRolePlayer action, and if a different action is used, the behaviour will be different. (If you need more help on using this action, see section 4.4.)
By this point we have covered the bare minimum of what is necessary to know to create a web editor application, but there are some useful techniques that make developing with the web editor framework easier, and we will cover them in this section.
In most cases the framework takes care of passing the object ID of the current object being worked on (usually a topic) around for you, but sometimes you need to pass more parameters. When the user submits a form it goes to the ProcessServlet, which processes it, and then forwards the user on to the next page. This means that the ProcessServlet decides which parameters go to the next page, and ProcessServlet only passes on the id parameter, unless told to be more permissive.
The way to do this is to change the definition of the forward rules in the actions.xml file by adding reqParam elements inside the forward or forwardDefault elements. The example below shows one way of doing this:
Using reqParam
<forwardRules> <forwardDefault path="task.jsp"> <reqParam name="show-dependencies" value="yes"/> </forwardDefault>  </forwardRules>
This will cause the default forward to go to task.jsp?id=<objectid>&show-dependencies=yes. If you want the value of the extra parameter to be dynamic you can leave off the value attribute. In this case the ProcessServlet will pass on the value it receives for this parameter, or, if it doesn't receive the parameter at all, it will leave it out entirely.
What this means is that you must remember to pass the value of show-dependencies to the ProcessServlet. In other words, if the user is at otherpage.jsp?id=<objectid>&show-dependencies=yes and you have a forward like in the example above the value will not be carried forward. The reason is that although otherpage.jsp got a value for show-dependencies ProcessServlet did not, and so it could not pass it on. The solution is to add the following to otherpage.jsp:
Passing request parameters to ProcessServlet
<webed:form ...>  <input type=hidden name=show-dependencies value="<%= request.getParameter("show-dependencies") %>">  </webed:form>
This copies the value of show-dependencies from the current request and passes it to ProcessServlet.
Quite often one wants to do more than just create a topic of a particular type, for example one that has a topic name in a particular scope, and an association to some other topic. There are no ready-made tasks for this, and even if there were they would need an awful lot of parameters, and it would be really difficult to make tasks that could cover all eventualities. Instead, we created a task that accepts LTM fragments and reads the LTM fragment into the topic map. This allows you to describe what you would like to have added to the topic map in an easy and flexible way.
For example, imagine that we want to add to the task.jsp page the ability to create a new task that the one being edited depends on, and to give it a name immediately, so that the user can continue working with the current task.
To do this, all we have to do is to add a new text field for the name of the new task and attach it to the EvaluateLTM task, so that if the user enters a name the task is triggered and the new task created. To do this we add the following to the end of the table in the task.jsp page:
Adding the new field

New dependent task <webed:field action="evaluate" params="topicmap fragment"/>
This creates the field and sets everything up, passing the topic map and the LTM fragment to the action, which then will read the fragment into the topic map. We haven't yet created the fragment, however, so we have to do that. The snippet below creates the LTM fragment, and needs to be inserted in the page somewhere above the example above, so that the fragment variable is defined when the code in the example above is evaluated.
Defining an LTM fragment
<tolog:set var="fragment"> [%new% : task = "%value%"] depends-on(<tolog:id of="task"/> : prior, %new% : after) </tolog:set>
There are several things worthy of note here, and we'll go through them one by one. First, the LTM fragment is a string, so we use the tolog:set tag with content to create it. The contents of the tag form the LTM fragment, and we can use any tags we want to produce the fragment.
We can use topic IDs to refer to topics in the topic map. This works for topics that have source locators of the right form. We exploit this to refer to the typing topics, but also to create a reference to the current task, by using the tolog:id tag. Note that this requires the current task to have a source locator of the right form, since LTM doesn't support any other form of topic reference.
Finally, we see that the special syntax %new% and %value% is being used to refer to the new topic created by this action and the string value of the form field, respectively. Note that neither of these have to be used, and if the %new% token does not appear in the fragment, no new topic will be created when the fragment is evaluated.
The last thing we need to do to make this work is to add the evaluate action to the actions.xml file, but we leave this as an exercise for the reader.
In some cases one wants to delete not just a single topic, association, or occurrence, but a whole collection of objects. In this case it needs to be made clear which objects are going to be deleted, and this is where tolog comes in. The TologDelete action allows you to send a tolog query to the action, and the action will then delete all objects selected by the query.
One example in the context of the task editor might be that we want to delete all tasks which do not depend on any other task, nor have any tasks that depend on them. To do this we can use a tolog query that finds all these tasks and pass it to the TologDelete action, as shown below.
Using tolog for deletion
<tolog:set var="query"> select $TASK from instance-of($TASK, task), not(depends-on($PRIOR : prior, $TASK : after)), not(depends-on($TASK : prior, $AFTER : after))? </tolog:set> <webed:button action="delete" params="topicmap query" text="Delete"/>
This is actually all it takes, except for the actions.xml setup, which once again is left as an exercise for the reader.
Quite often it's necessary to attach a JavaScript event to a form control in order to implement some dynamic user interface functionality, or even to do some client-side validation of input. In HTML every form control has a number of such events, and the JavaScript is typically attached by putting a method call into an HTML attribute with the name of the event. However, when the control is rendered with the tag library, that isn't possible. So how to solve it?
Instead of adding one attribute for every event to the tag library, we've chosen a simpler solution. Every tag in the tag library that directly renders a form control, like field, list, checkbox, and button, has an id attribute. This will be reproduced in the HTML output as an ID attribute on the form control. This can then be used to attach JavaScript event handlers to the form control, as shown below.
Using the id attribute
<webed:button action="deleteAction" text="Delete" params="topic" id="delete"/>
It really is as simple as this. The only pitfall is that you must make sure that the script element appears below the form control, so that the element has been parsed first.
In some cases it may be necessary to take control over the rendering of forms controls, for example because you need to control in detail the rendering of a control. The tag libraries make this possible through the actionid tag, which let you pass parameters to the framework and get a form control name back.
The example below shows how this can be used.
Rendering a list box
<select name="<webed:actionid action="set-role-player" params="assoc ..."/>"> <tolog:foreach query="related-to(%topic% : start, $OTHER : end)?"> <option value="<tolog:oid var="OTHER"/>"><tolog:out var="OTHER" scope="myscope"/></option> </tolog:foreach> </select>
This simple example creates a list box where the topics in myscope have been used to select the names of the topic being shown. Otherwise it is exactly like an ordinary list rendered by webed:list. The magic here is performed by the webed:actionid tag which causes the parameters to be bound to a form control name, which is then output. This means that when the form is submitted the action is invoked in the usual way.
Note that there is one important difference between controls rendered this way, and controls rendered in the usual way. The usual controls only cause actions to be invoked when the value of the control changes, but since the framework does not know the initial value of a custom-rendered control it is always invoked. We are considering to fix this, but haven't yet done so.
In most cases when editing a topic there is not too many topics that it could be associated with, but occasionally a topic could be associated with any one of thousands of other topics. In these cases it's clearly not a good idea to create a drop-down list containing all these topics. So, what to do?
A common solution is to use a pop-up dialog to search for the topic you want to create an association to. You can create a text field (containing the name of the associated topic, if any) with a button to open the search pop-up next to it. Using JavaScript this can be quite easy, once you know the trick.
Imagine we are creating a page to edit books in a library system, and we want to make it possible to attach a new author. The author has to be selected from thousands of person topics, which means we need to use the search pop-up solution. The figure below shows what this might look like.
Figure 5. Selecting an author
The code to create this is shown below.
<webed:form actiongroup="edit-book" id="edit-book"> <%-- necessary variables already set --%>
Author  <input type=text id=author-name> <input type=hidden name="<webed:actionid action="assignPlayer" value="empty" params="empty o:author-of o:book o:work o:author"/>" id=author-oid> <input type="submit" value="Choose" onclick="return chooser('new-author')">
Now we've got the form controls we need, but we need to implement the chooser JavaScript function (and we need to do it higher up in the page than the previous fragment). That could be done as follows.

Now we've got the form controls, and they open a new window in which we get chooser.jsp with the appropriate parameters. So the next thing is to write chooser.jsp. It should display something like the figure below.
Figure 6. The chooser pop-up
When the user clicks one of the radio buttons the name and ID of the chosen topic are written back into the original form and the pop-up is closed. If the user clicks "Cancel" the form is closed, and nothing happens. The user can also type a new search and press search if the right topic doesn't appear in the list. The code to produce this window is shown below.
<tolog:context topicmap="library.xtm"> <% String search = request.getParameter("search"); String field = request.getParameter("field"); String form = request.getParameter("form"); %>
Choose author
 <form action="chooser.jsp" method="get"> <input type=hidden name=field value="<%= field %>"> <input type=hidden name=form value="<%= form %>">

Search <input type=text name="search" value="<%= search %>">
<input type=submit value="Search"> </form> <% if (search != null) { String query = "value-like($TN, \"" + search + "\"), " + "topic-name($AUTHOR, $TN), " + "instance-of($AUTHOR, person)?"; %>  <logic:set name="authors"> <tm:tolog query="<%= query %>" select="AUTHOR"/> </logic:set>
 <tolog:foreach query="<%= query %>"> <input type=radio name=whatever onclick="choose('<tolog:oid of="AUTHOR"/>', '<tolog:out var="AUTHOR"/>')" ><tolog:out var="AUTHOR"/>
 </tolog:foreach> <input type=button onclick="window.close()" value="Cancel"> <% } %> </tolog:context>
If you want to control the order in which actions are executed this is actually trivial: actions are executed in the order they are found within the actionGroup element in the actions.xml file.
Now that we have walked through the basics of creating a web editor application it is time to look at some of the more advanced aspects of building such applications.
When a form is submitted to the server the actions modify the underlying topic map, and once the entire form has been processed the changes will either be committed or, if there were errors, rolled back. This means that either all changes will be committed, or none. As the developer you do not have to worry about this; the framework will handle all the details for you.
If the topic map is stored in the RDBMS backend the changes will then be automatically persisted in the database, but if the in-memory implementation is used only the in-memory objects will change. In this case it will be necessary to export the topic map to a file in order to persist the changed topic map.
We do not recommend using the in-memory implementation with Web Editor applications. Persisting changes by saving the topic map to disk at intervals will cause problems if users modify the topic map while a save is in progress. Similarly, the in-memory implementation does not support transactions, and thus editing operations that fail can leave the topic map in an inconsistent state.
It is possible to use the in-memory implementation for development, piloting, and simple proofs-of-concept, however. If you really want to do this, despite our warnings, you can use the example code below.
<%@ page import="net.ontopia.topicmaps.core.*, net.ontopia.topicmaps.entry.*, net.ontopia.topicmaps.utils.*, net.ontopia.topicmaps.nav2.utils.*"%><% // look up navigator application TopicMapRepositoryIF rep = ContextUtils.getRepository(pageContext.getServletContext()); // retrieve topic map TopicMapStoreIF store = rep.createStore("mytopicmap.ltm", true); String filename = null; try { // work out correct path filename = pageContext.getServletContext().getRealPath("file.xtm"); // save it to disk ImportExportUtils.getWriter(filename).write(store.getTopicMap()); } finally { store.close(); } %>
 File successfully saved to <%= filename %>.

To use this code, add it as a JSP page to your application (for example as save.jsp). It must be modified so that the topic map ID and the file name are correct for your application. The topic map can then be saved by accessing the JSP page. This will write an XTM file into the root directory of your web application. The code can be modified to write to the Omnigator topic maps directory, or the topic maps directory of your application, if desired.
When more than one person uses the editor application it can easily happen that two different users access the same topic at the same time, which will cause the changes made by one user overwrite those made by the other.
In order to avoid this the web editor framework lets you lock a collection of objects when rendering a form. Typically, this collection will only contain the topic being modified, but there are occasions when you may want to lock dependent objects. To do this, simply use the lock attribute of the webed:form element, as shown below.
Using the lock attribute
<webed:form actiongroup="person" lock="person">
Name <webed:field action="set-name" object="name" type="tfs"> <tolog:out var="name"/> </webed:field>
 <webed:button action="person" object="person" text="Change"/> <webed:button action="delete-person" object="person" text="Delete"/> </webed:form>
This shows the form for editing the name of a 'person' topic modified to lock the person topic when the page is rendered. This means that until the form is submitted nobody else can edit this topic. The lock attribute must contain the name of a variable, and all the objects in the collection that variable is bound to will be locked. Should one of them fail to be locked none will be locked, and the page will fail to load with an error message.
You can control what page the user is to go to next should the locking fail by adding an element to the corresponding action group. Below is shown how this is done for the form shown above.
Action group for 'person' topics
<actionGroup name="person">  <action name="set-name" class="ActionSetBasenameValue"/>  <action name="person" class="DummyAction"/> <action name="delete-person" class="ActionDelete"/>  <forwardRules> <forwardDefault path="person.jsp"/> <forwardLocked path="locked-person.jsp"/> <forwardRule action="delete-person" forward="frontpage"/> </forwardRules> </actionGroup>
If the person topic being edited is locked, this will forward the user onto the locked-person.jsp page.
When a form is submitted the locks established by that form will be released, but it may well be that the user never submits the form. In this case the lock will expire after a timeout.
When using the RDBMS Backend Connector in a cluster the Web Editor locks will also have to be clustered, so that locks are being properly synchronized across the cluster. To do this one can use a tool called Open Terracotta. No code changes are required, but an active Terracotta server must be running. The JVM(s) running Ontopia must also be Terracotta-enabled.
To start the Terracotta server, first download and install the Terracotta software. Then start up the server with the following command:
cd $TERRACOTTA_HOME sh ./bin/start-tc-server.sh
Note that you may want to adjust the Terracotta server configuration to your needs. You may also want to have additional passive servers running so that you get failover support.
To make the JVM(s) running the Ontopia Terracotta-enabled a few system properties need to be passed on to the JVM on startup:
-Xbootclasspath/p:${TERRACOTTA_HOME}/lib/dso-boot/dso-boot-hotspot_XX_YYY_ZZ.jar -Dtc.install-root=${TERRACOTTA_HOME} -Dtc.config=${ONTOPIA_HOME}/rdbms/clustering/ontopia-terracotta.xml
Before you start the JVM make sure that you have created a boot jar for your specific JVM. The boot jar file can be found in ${TERRACOTTA_HOME}/lib/dso-boot/. A new boot jar can be created with the following command:
cd $TERRACOTTA_HOME sh /bin/make-boot-jar.sh
You may also want to make some changes to the default Terracotta client configuraton file that is shipped with Ontopia: ${ONTOPIA_HOME}/rdbms/clustering/ontopia-terracotta.xml.
If the Web Editor Framework does not contain the action you need to implement a specific piece of functionality you can always write your own action and plug it into the system. What you do is to create a class that implements the net.ontopia.topicmaps.webed.core.ActionIF interface.
An action object must have a method implementing the action, and that's all. This method is what actually performs the action when matching form data is received.
The action will be passed two parameters, one of which implements the ActionParametersIF. Through this object the parameters passed to the action can be retrieved, as well as any string values or objects passed by the form element. In addition there is the ActionResponseIF, which can be used to set request parameters for the forward page.
The interaction with transactions means that there are some important rules that action implementations must follow:
Never call the commit or abort methods on the transaction object from an action. This will interfere with the transaction handling of the framework and will have unpredictable consequences.
Do not keep any references to topic map objects between calls to the perform method. Topic map objects are bound to a specific transaction, and the next time the action is called the action may be executing in a different transaction. Trying to use objects retrieved from another transaction could have disastrous consequences.
Make sure your action object is thread-safe. That is, the perform method can be called by different threads and it may be called by one thread before having finished executing for another. So be very careful with storing state on the object.
If something goes wrong within the action the action should throw an exception. Errors reported by actions generally fall into two categories:
These are generally errors caused by misbehaviour on the part of the user (incorrect string values, operation performed that was not allowed, etc), which are detected by the action, and reported back to the user. Non-critical errors do not prevent other actions from running, nor do they cause the transaction to be rolled back.
These are generally caused by bugs or environment failures (full disk, database is down, etc). Critical errors prevent other actions from running and cause the transaction to be rolled back so that the state of the topic map is not affected.
The Web Editor Framework considers only ActionRuntimeExceptions which do not have the critical property set to be non-critical errors. All exceptions of other classes, as well as those which have the critical property set are considered critical.
The first problem people tend to run into when using this action is that they can't quite work out what the long list of parameters means, and usually this is because they don't really understand the structure of associations. This is not so strange, since associations are actually quite complicated. Even a binary association has eight different components, as shown in the diagram below.
Figure 7. The structure of associations
This diagram shows an association stating that one task depends on another, so this is an example of the associations we might be editing in section 2.6. The list below explains each numbered node in the diagram.
This is 'test-x', one of the tasks, which is to test software system X. So this is the topic being edited in section 2.6; the current task, if you like.
This is the role type 'after', which is played by the thing that depends on another. (So this association says that 'test-x' depends on 'implement-x'.) Note that this is a topic.
This is the association type 'depends-on', also a topic.
This is the role type 'prior', which is played by the thing that something depends on, and it's a topic, too.
This is 'implement-x', another task, which is to implement software system X. This is the topic that you would select in the drop-down list to create (or change) the association.
This is an association role, which has the type 'after' and is played by the 'test-x' topic.
This is the association itself, which has two roles and the type 'depends-on'.
This is the other association role, which has the type 'prior' and is played by the 'implement-x' topic.
Now we can walk through the list of parameters to the action and work out what each one means.
This parameter needs to contain the association itself (number 7 above). If it contains an association the action will change the topic at the other end of the association (that is, it will change number 5 to whatever topic is chosen in the list). If it is empty, the action will create a new association from scratch. (More on this below.)
This parameter needs to contain the association type, which is number 3 in the list above.
This is the topic being edited; number 1 in the list.
This is the type of the role played by the edited topic; number 2 in the list.
This is the type of the role played by the other topic; number 4 in the list.
In the explanation above, one thing that can be a bit tricky to understand is how the association parameter works. What's the difference between the parameter being empty and not being empty, and how can you make sure the value is right? Let's return to the example in section 2.6 and study it more carefully.
Drop-downs for existing associations

Depends on <tolog:foreach query="select $ASSOC, $OTHER from role-player($R1, %task%), type($R1, after), association-role($ASSOC, $R1), type($ASSOC, depends-on), association-role($ASSOC, $R2), type($R2, prior), role-player($R2, $OTHER)?"> <webed:list action="assign-player" params="ASSOC t:depends-on task t:after t:prior" collection="tasks" selected="OTHER"/>
 </tolog:foreach>
What we do here is to query for all depends-on associations and produce a drop-down list for each one. So inside the foreach-loop ASSOC will always be bound to node number 7 from the diagram, R1 will be node 6, R2 node 8, and OTHER will be node 5. The task variable was set outside the loop to the current topic, which is node 1.
This means that the first parameter will always have an association in it, and so the action will change the topic at the other end of that association to whatever is chosen in the list. (If nothing is chosen the association is deleted.) Compare the list of parameters in the example with the list above, and it should be clear what each one is.
Now we've seen how to edit existing associations, but not how to create new ones. Below is the relevant part of the example from section 2.6.
Creating new associations
<%-- make empty variable --%> <tolog:set var="empty"/> <webed:list action="assign-player" params="empty t:depends-on task t:after t:prior" collection="tasks"/>
The difference with the previous example is the first parameter, which is now set to the empty variable. The tolog:set tag doesn't get a value from anywhere, so the variable ends up being empty, that is, bound to nothing. If the user selects a task now, the action will see that there is no pre-existing association, and create a new one. Since it has the association type and role types, plus the topic on the near end, in its parameter list it has enough information to build the association from scratch.
There is one more situation in which this action is often used, and that is when the topic being edited only can have a single association of the edited type. Let's say that tasks can have a status (and only one), which is indicated with an association like this (in LTM):
has-status(implement-x : task, wait : status). This means the task is waiting for tasks it depends on to be finished. The example below shows how we would edit this type of association.
Drop-downs for single associations
<tolog:set var="status-assoc" query="select $ASSOC from role-player($R1, %task%), type($R1, task), association-role($ASSOC, $R1), type($ASSOC, has-status), association-role($ASSOC, $R2), type($R2, status), role-player($R2, $OTHER)?"/> <tolog:set var="status" query="has-status(%task% : task, $STATUS : status)?"/>
Status <webed:list action="assign-player" params="status-assoc t:has-status task t:task t:status" collection="statuses" selected="status"/>
The two queries here find the association (node 7) and the current status (node 5) for us, if the current task have them. If it doesn't, the status-assoc and status variables will be empty. This means that if we have an association already the task will change it, and if we don't have an association already, the task will modify it. (And this, of course, is why the task can both modify and create associations, since it makes editing in this situation very much easier than if these were different actions.)
It can be quite difficult to debug web editor applications, because you can't see what is happening "behind the curtain" when a form is submitted and the actions are executed. The best solution to this is to use log4j logging for your web application, and to enable logging from the ProcessServlet.
To do this, add the following line to your log4j.properties file:
log4j.category.net.ontopia.topicmaps.webed.servlets.ProcessServlet=DEBUG
This will make the ProcessServlet write lots of information to the log every time a form is submitted. For example, if I go to the page for the topic "Lars Marius Garshol" in the tasked application, and change the name to "Lars M. Garshol" the log output will be as shown below.
DEBUG "Param 'person6': '[Change]'" - ProcessServlet DEBUG "Param 'tm': '[tasks.ltm]'" - ProcessServlet DEBUG "Param 'set-name5': '[Lars M. Garshol]'" - ProcessServlet DEBUG "Param 'ag': '[person]'" - ProcessServlet DEBUG "Param 'requestid': '[rid4]'" - ProcessServlet DEBUG "Param 'id': '[larsga]'" - ProcessServlet DEBUG "Schema is not available, that might be ok." - ProcessServlet
This first part of the log just shows all the parameters received by the servlet, which can be useful to see exactly what is submitted with the form. The last line is just saying that no schema has been found for the topic map; you can ignore this.
DEBUG "Working on person6 (<ActionInGroup person net.ontopia.topicmaps.webed.impl.actions.DefaultAction@1f5b4d1>)" - ProcessServlet DEBUG "data: [ActionData person with 0 param(s) and 0 sub-action(s)]" - ProcessServlet DEBUG "Original value was: [null]" - ProcessServlet DEBUG "Parameter value now: [Change]" - ProcessServlet DEBUG "Action will be executed" - ProcessServlet DEBUG "Working on set-name5 (<ActionInGroup set-name net.ontopia.topicmaps.webed.impl.actions.basename.SetValue@a030d6>)" - ProcessServlet DEBUG "data: [ActionData set-name with 2 param(s) and 0 sub-action(s)]" - ProcessServlet DEBUG "Original value was: [Lars Marius Garshol]" - ProcessServlet DEBUG "Parameter value now: [Lars M. Garshol]" - ProcessServlet DEBUG "Action will be executed" - ProcessServlet DEBUG "Working on delete-person7 (<ActionInGroup delete-person net.ontopia.topicmaps.webed.impl.actions.tmobject.Delete@1e4eb5b>)" - ProcessServlet DEBUG "data: [ActionData delete-person with 1 param(s) and 0 sub-action(s)]" - ProcessServlet DEBUG "Original value was: [null]" - ProcessServlet DEBUG "Parameter value now: [null]" - ProcessServlet
In this next section, the servlet is going through all the actions in this form, and checking for each whether to run it or not. We can see that the 'person' action (attached to the "Change") button will be run, because its value has changed. This is logical, since this is the button that was pressed to submit the page. The 'set-name' action will also run, because the name was changed, but the 'delete-person' action will not run, since the value hasn't changed.
DEBUG "Changes made, since net.ontopia.topicmaps.webed.impl.actions.basename.SetValue@a030d6 will run" - ProcessServlet DEBUG "User <unknown> entered transaction phase" - ProcessServlet DEBUG "Invoking action [ActionParameters: ], <ActionInGroup set-name net.ontopia.topicmaps.webed.impl.actions.basename.SetValue@a030d6>" - ProcessServlet DEBUG "Invoking action [ActionParameters: ], <ActionInGroup person net.ontopia.topicmaps.webed.impl.actions.DefaultAction@1f5b4d1>" - ProcessServlet DEBUG "No forward page found; getting default" - ProcessServlet DEBUG "Transaction committed" - ProcessServlet DEBUG "User <unknown> left transaction phase" - ProcessServlet
First, the servlet notes that at least one action has run, so actions that had runIfNoChanges set to false should also run. Then we get to the transaction phase, where the servlet goes through each action to be executed and executes it. Then it notes that no action has set the forward page, so it picks the default. Then it commits the transaction. (In the in-memory version the commit step doesn't do anything.)
DEBUG "Forward page is: [ActionForwardPage: relativeURL=person.jsp, framename=, nextActionTemplate=, paramRule=net.ontopia.topicmaps.webed.impl.basic.IdentityParamRule@d5cabc, reqParams={}]" - ProcessServlet DEBUG "Initial forward URL: person.jsp?&tm=tasks.ltm&ag=person&id=larsga" - ProcessServlet DEBUG "Applying param rule: net.ontopia.topicmaps.webed.impl.basic.IdentityParamRule@d5cabc" - ProcessServlet DEBUG "URL after rules applied: person.jsp?&tm=tasks.ltm&ag=person&id=larsga" - ProcessServlet INFO "forward to person.jsp?&tm=tasks.ltm&ag=person&id=larsga" - ProcessServlet
Finally, the servlet works out where to forward to. It's picked the default rule for this action group, and that gives it the URL shown. No interesting param rules are attached, so that becomes the final URL.


Lesson 2: Notation and Formal Definitions
2.3
Strings and Languages
If you have been studying computer science for even a short amount of time, you probably know that strings of characters are a fundamental datatype in every programming language. When we discussed finite automata, we described them as taking in strings of characters and producing an output that is either ‘ACCEPT’ or ‘REJECT.’ Any string that is accepted by a given machine is in the language of the machine. In this lesson, we will be learning about how strings and languages are defined formally.
Alphabets (Formally)
Strings may seem to be really simple objects, but the formal definition used in mathematics and theoretical computer science may be less intuitive than the typical way we think about them when programming. Formally, strings are defined in terms of their alphabet set. An alphabet is any nonempty finite set, and its members are called symbols of the alphabet. We have already seen examples of alphabets, such as \( \{ 0, 1 \} \) or \( \{ a, b \} \). In these alphabets, each symbol is only one character. But, symbols of an alphabet can technically be many characters long. For instance, the very first automaton we saw was the automaton for a light switch. Its alphabet was simply one symbol: \( \{ \text{PRESS} \} \).
We often abbreviate long alphabets using ellipses (\( \dots \)): $$ \Sigma_1 = \{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9\} = \{ 0, 1, \dots , 9 \}$$ $$ \Sigma_2 = \{ \text{a}, \text{b}, \text{c}, \text{d}, \text{e}, \text{f}, \text{g}, \text{h}, \text{i}, \text{j}, \text{k}, \text{l}, \text{m}, \text{n}, \text{o}, \text{p}, \text{q}, \text{r}, \text{s}, \text{t}, \text{u}, \text{v}, \text{w}, \text{x}, \text{y}, \text{z} \} = \{ \text{a}, \text{b}, \dots , \text{z} \}$$
Strings (Formally)
A string over an alphabet is a finite sequence of symbols from that alphabet, usually written next to one another and not separated by commas. For example, some strings over \( \Sigma_1 \) are \( 30154\), \( 0093588 \), and \(<PHONE_NUMBER> \). \( \Sigma_2 \) is the alphabet used by all English strings.
If \( w \) is a string, then its length, written \( |w| \), is the number of symbols that it contains. The string \( w = \text{abracadabra}\) over the alphabet \( \Sigma_2 \) has length \( |w| = 11\). We introduced \( \varepsilon \), the empty string, briefly in other lessons. But now we have a better definition for it: it is the string of length \( 0 \) over any alphabet. If \( w \) over the alphabet \( \Sigma \) has length \( n \), we can write $$ w = w_1w_2 \dots w_n $$ where each \( w_i \in \Sigma \). Don't let the notation fool you, though. If \( n \) is one or zero, then the string only has one symbol or zero symbols!
If we have string a \( x = x_1 x_2 \dots x_n \) of length \( n \) and string \( y = y_1 y_2 \dots x_m \) of length \( m \), the concatenation of \( x \) and \( y \), written \( xy \), is the string obtained by appending \( y \) to the end of \( x \), as in \( x_1 x_2 \dots x_n y_1 y_2 \dots y_m\).
Languages (Formally)
Formally, a language is a (possibly infinite) set of strings. If we say that \( L = \{ \text{abc}, \text{cab} \} \) is a language, then it is the language containing the strings \( \text{abc} \) and \( \text{cab} \). Defining sets using set-builder form will come in handing when defining languages. In set-builder form, a set is described by a property that each of its members must satisfy. for instance, writing $$ S_1 = \{x : x \text{ is a positive number less than 6} \}$$ has the same meaning as $$ S_1 = \{ 1, 2, 3, 4, 5\}$$ and reads as "\( S_1 \) is the set of all elements \( x \) such that \( x \) is a positive number less than 6." When using set-builder notation, we can also define members of a set in terms of another set: $$ S_2 = \{x \in S_1 : x > 3\}$$ There are two main components to the meaning of \( S_2 \): first, "\( x \in S_1 \)" tells the reader to consider an element \( x \) in \( S_1 \), and "\( x > 3 \)" tells the reader that \( x \) must be greater than \( 3 \) in order to be a member of the set \( S_2 \). In short, this notation tells us that \( S_2 \) is the set of all elements in \( S_1 \) that are greater than \( 3 \). Considering what we know about \( S_1 \), we can see that \( S_2 = \{ 4, 5 \} \).
Set-builder notation makes defining sets much more intuitive. Recall that the Cartesian product of two sets is the set of all ordered pairs where the first element of the pair is in the first set, and the second element is in the second set. We can define the Cartesian product in a more intuitive way using set-builder notation: $$ A \times B = \{ (x,y) : x \in A \text{ and } y \in B \}$$ We can also define other set operations, such as the union of two sets: $$ A \cup B = \{ x : x \in A \text{ or } x \in B \} $$ Or the intersection of two sets: $$ A \cap B = \{ x : x \in A \text{ and } x \in B \} $$ Set-builder notation comes in handy when defining languages. In particular, we can define useful operations on languages, such as the star operation on a language \( L \): $$ L^* = \{ x_1x_2 \dots x_k : k \geq 0 \text{ and } x_i \in L \} $$ The star operator is particularly useful when concisely notating that some string is over a particular alphabet, since it can also be applied to alphabets. For example, to give a simpler way to express that \( w \) is a string over the alphabet \( \Sigma \), we can say \( w \in \Sigma^* \). This means that \( w \) is a string of zero or more symbols from the alphabet \( \Sigma \).
The language \( \emptyset \) is the empty language. Note that this is very different from \( \varepsilon \), the empty string. \( \emptyset \) is a language that contains no words/strings, and is not itself a string.


Garmin Connect Downloader
Download after this date
Download data
Activity
Wellness
Download directory
(valid only relative path from the default download directory)
Open Garmin Connect
Garmin Connect
download


--- # jekyll header --- {% include header.html %}
{% include container-start.html %}| Name | Definition |
| ClockDirection | A direction indicated by an angle relative to 12 o'clock. |
| CollectionSite | The body site where specimen was collected |
| DiagnosticService | A code that classifies the clinical discipline, department or diagnostic service that created the report (e.g. cardiology, biochemistry, hematology, MRI). This is used for searching, sorting and display purposes. |
| DistanceToNipple | The body site location in relation to the nipple. |
| Encounter | An abstract class that represents an encounter class. This class has been stubbed out to limit the scope of this implementation guide to classes relevant to this ballot concerning breast cancer. |
| MorphologyBehavior | A description of the morphology and behavioral characteristics of the cancer. |
| StageTimingPrefix | Indicates when the staging was done, in terms of treatment landmarks. |