Neuroplasticity
Neuroplasticity is the idea that the human mind and brain are continually developing in relation to experiences over time. Understanding that is is possible to actively work towards rewiring your mind and allowing it to become better at certain skills can be of benefit, because it provides motivation due to the fact that if you work in the right way you can become better at something, and a natural born gift isn’t everything - in fact for most people it is much less important than experience and attitude.
A lot of the material on the internet relates to children's brains as many researchers used to think that the development of the brain ceased after adolescence, but in the last decade or so, there is much published evidence to suggest that the brain can be developed in adulthood too.
A couple of observations that are useful for learning, is that visualisation exercises, where you imagine undertaking a task, help build neural connections, and can help you learn a task faster when you actually come to do it. This means the planning and mapping tasks out, which has a component of visualisation, and also explaining how a task might be done to others, reinforcing and accelerates learning.
Beyond the links provided in the Ensprial Dev Academy material, here are a couple of links in a New Zealand context. A teaser for a Nigel Latta documentary on the topic, and an interview on the topic on RNZ.
The foundations material states that there are three steps of Emotional Intelligence, I think more properly stated as three main areas that one can focus on to improve emotional intelligence.
The Nigel Latta documentary includes an example of a women who had a condition where she suffered a stroke and frequent seizures, was able to rewire her brain to the extent that the half that was causing the seizures was able to be removed, and she was able to still get by quite well, incredible...
This RNZ interview also has a facinating discussion on the topic.


CD audiobooks
A Boy Called Christmas, by Matt Haig, read by Stephen Fry
“You are about to read the true story of Father Christmas. It is a story that proves that nothing is impossible. If you are one of those people who believe that some things are impossible, you should put this book down right away. It is most certainly not for you. Because this book is full of impossible things. Are you still reading? Good. Then let us begin. A tale of adventure, snow, kidnapping, elves, more snow, and an 11-year-old boy called Nikolas, who isn’t afraid to believe in magic…”
The Secrets of the Superglue Sisters, by Susie Day, read by Charlie Sanderson
“Best friends Georgie and Jem aren’t just new at school; they’re new at being full-time sisters too. Georgie’s mum and Jem’s dad have finally bought a house together, and they get to share a home at last, just like they always wanted.
“School is a bit more challenging. Miss Eagle wants the whole class to start a self-esteem project.  Then disaster - the ball of secrets disappears! Soon everyone’s deepest secrets are being revealed to the whole school.”
World’s Worst Children 2, by David Walliams, read by David Walliams, Nitin Ganatra, James Goode & Morgana Robinson
Ten more stories about the gang of hilariously horrible kids.
OverDrive
The Vile Village, by Lemony Snicket, read by Tim Curry
The seventh book in the A Series of Unfortunate Events series features “such unpleasant matters as migrating crows, an angry mob, a newspaper headline, the Deluxe Cell, and some very strange hats.”
The Wishing Spell, written and read by Chris Colfer
“Alex and Conner Bailey’s world is about to change, in this fast-paced adventure that uniquely combines our modern day world with the enchanting realm of classic fairytales.
“Through the mysterious powers of a cherished book of stories, Alex and Conner leave their world behind and find themselves in a foreign land full of wonder and magic where they come face-to-face with the fairy tale characters they grew up reading about. But after a series of encounters with witches, wolves, goblins, and trolls alike, getting back home is going to be harder than they thought.”
Anne of Green Gables, by L. M. Montgomery, read by Shelly Frasier
“When Marilla and Matthew Cuthbert of Green Gables send for a boy orphan to help them out at their farm, they mistakenly get Anne Shirley, a feisty, independent but warm-hearted 11-year-old girl. Fortunately her sunny nature and quirky imagination win the hearts of her reluctant foster parents and everyone in the community. But not a day goes by without some memorable adventure or prank in the tragicomedy of her life. Early on she accidentally dyes her “cursed” red hair green. Later, in an effort to impress a neighbor she bakes a cake, but with liniment instead of vanilla.”
BorrowBox
Fantastic Beasts and Where to Find Them, by Newt Scamander & J. K. Rowling, read by Eddie Redmayne
“A set textbook at Hogwarts School of Witchcraft and Wizardry since publication, Newt Scamander’s masterpiece has entertained wizarding families through the generations. Fantastic Beasts and Where to Find Them is an indispensable introduction to the magical beasts of the wizarding world.
“Scamander’s years of travel and research have created a tome of unparalleled importance. Some of the beasts will be familiar to readers of the Harry Potter books – the Hippogriff, the Basilisk, the Hungarian Horntail … others will surprise even the most ardent amateur Magizoologist.”
Frogkisser!, by Garth Nix, read by Marisa Calin
“Talking dogs. Mischievous wizards. An evil stepstepfather. Loads and loads of toads. Such is the life of a Frogkisser.
“Princess Anya needs to see a wizard about a frog. It’s not her frog, it’s her sister’s. And it’s not a frog, it’s actually a prince. A prince who was once in love with Anya’s sister, but has now been turned into a frog by their evil stepstepfather. And Anya has made a ‘sister promise’ that she will find a way to return Prince Denholm to human form …
“So begins an exciting, hilarious, irreverent quest through the Kingdom of Trallonia and out the other side, in a fantastical tale for all ages, full of laughs and danger, surprises and delights, and an immense population of frogs.”
Epic Adventure (Kind Of), by Liz Pichon, read by Russell Tovey
“The 13th hilarious audiobook in the ever-popular Tom Gates series!
“Having two sets of grandparents is turning out to be VERY GOOD for me.
“The wrinklies are KEEN on giving presents AND they’re planning a FAMILY OUTING too, which is going to be EPIC.
“Delia wants to come as well. (Why?)
“I can always ignore her.”
Amelia Fang and the Barbaric Ball, by Laura Ellen Anderson, read by Zoe Thorne
“Welcome to the world of Nocturnia, where darkness reigns supreme, glitter is terrifying and unicorns are the stuff of nightmares! Amelia Fang would much rather hang out with her pet pumpkin Squashy and her friends Florence the yeti (DON’T CALL HER BEAST!) and Grimaldi the reaper than dance at her parents’ annual Barbaric Ball.
“And when the King’s spoiled son Tangine captures Squashy, Amelia and her friends must escape the party to plan a daring rescue! In their race against time, they begin to realise things in Nocturnia may not be quite what they seem …
“Join Amelia on her very first adventure. She won’t bite!”
The Wizards of Once, by Cressida Cowell, read by David Tennant
“This is the story of a young boy Wizard and a young girl Warrior who have been taught since birth to hate each other like poison; and the thrilling tale of what happens when their two worlds collide.
“Xar is a Wizard boy who has no Magic, and will do anything to get it. Wish is a Warrior girl, but she owns a banned Magical Object, and she will do anything to conceal it.
“In this whirlwind adventure, Xar and Wish must forget their differences if they’re going to make it to the dungeons at Warrior Fort, where something that has been sleeping for hundreds of years is stirring…”
Frenemies Forever and Crush Catastrophe, by Rachel Renée Russell, read by Jenni Barber
In the 11th and 12th books in the Dork Diaries series, Nikki Maxwell is on an exchange week at North Hampton Hills, her arch nemesis MacKenzie Hollister’s new school. Nikki and MacKenzie find themselves having to work together against Tiffany, a queen bee even meaner than MacKenzie.
The Princess and the Suffragette, by Holly Webb, read by Amy Enticknap
“It is 1913, nine years after the end of A Little Princess saw Sara Crewe escape Miss Minchin’s orphanage.
“Lottie, the smallest girl from the original story, learns about the Suffragette movement from Sara, who returns to visit from time to time. Soon Lottie finds herself sneaking out of the orphanage to attend a demonstration, in defiance of her cold, distant father. A father who has a secret to hide about her own missing mother …
“A story about lost mothers turning up in unexpected situations, the power of friendship and female empowerment.”
Winnie and Wilbur Volume 1, by Laura Owen, read by Amy Enticknap
“Join Winnie and Wilbur on their wild and wacky adventures. From going back to the time of the dinosaurs to saving school children from slavery in ancient Egypt, from organising a treasure hunt for a pirate to rustling up some batburgers in the kitchen, this collection will keep young listeners entertained for hours!”
The Little Prince, by Antoine de Saint-Exupéry, read by Humphrey Bower
“A pilot stranded in the desert awakes one morning to see, standing before him, the most extraordinary little fellow. ‘Please,’ asks the stranger, ‘draw me a sheep.’ And the pilot realises that when life’s events are too difficult to understand, there is no choice but to succumb to their mysteries. He pulls out pencil and paper…
“And thus begins this wise and enchanting fable that, in teaching the secret of what is really important in life, has changed forever the world for its readers.”
The Elmer Treasury 3, by David McKee, read by Stephen Thorne
A modern classic, Elmer the colourful patchwork elephant has been a nursery favourite since his creation in 1989 and has sold over four million copies around the world. Elmer is not your normal grey elephant – his colourful exuberance cannot be contained for long! With his trademark cheeky humour, Elmer shows us that it’s OK to be different.”


browse other examples
Adapter (updatable scroller)
New mechanism of scroller data custom processing is introduced.
Single datasource but two different viewports with two different processing adapters.
The firstListAdapter is initially defined on ctrl $scope as a first level object with some property.
The second.list.adapter chain is not defined on ctrl $scope. The scroller defines it during linking.
1st list
...data loading...
1st list is loaded
update this list
add new 3d item
remove even items
{{item.content}}
2st list
...data loading...
2nd list is loaded
update this list
add new 5th item
remove odd items
{{item.content}}


Today's HR software environment
Human resources (HR) software is a classic long tail industry. A few very large integrated talent management (ITM) suites
try to cover all the bases from hire to retire. Alongside them, a long tail of thousands of small, agile SaaS players brings
innovative solutions to every area of the HR continuum, from recruitment marketing to employment branding.
With TAS, we wanted to offer an integration marketplace where customers can simply click to assemble these exciting long
tail solutions into a secure, working HR technology stack for recruiting, growing and managing talent.
To you, the SaaS app developer, Talent App Store provides access to a large audience of potential customers who can
trial and buy your software instantly. Because Talent App Store is an integration platform, not a PaaS, you don't need
to change your programming environment or the way you host or develop your application.
Goals for TAS
At its heart, TAS is an open integration marketplace where:
- developers build apps that:
- communicate with other apps via APIs
- protect their own web pages with single sign on (SSO)
- customers (tenants):
- click to install apps, enabling API traffic to flow securely
- specify SSO rules (e.g. that candidates can sign in with Google or Facebook)
Our specific goals for TAS were:
- Click to install. We wanted to make installing HR software literally as easy as installing apps on a smartphone.
- Plug and play. We wanted to remove the tight coupling of today's HR systems, where apps are strongly subservient to a single master system. For example, if you've built a career site app that pulls jobs from an applicant tracking system (ATS), then your app should continue working as that ATS is swapped out and replaced with a different one. TAS protects your app development investment.
- Try before you buy. We wanted to provide practical, sandbox based environments where customers can install and trial new software in minutes, but in an integrated setting, working with their existing HR stack.
- Security. While keeping it easy for customers to click to install apps into their environment, we wanted to provide powerful, overarching security, enforced even if individual apps are compromised, based on industry standards such as OAuth, SAML and HMAC.
- Open. We wanted developers and customers to enjoy an open environment, free from IP concerns. Any developer can add APIs to TAS, and all APIs fall under an open source license that prevents IP restrictions or caveats. You are free to fork or adapt any TAS APIs in any way you need.
- High performance. We set a goal that TAS should impose no practical performance penalty over other API platforms not offering plug and play. This goal led to some key architectural decisions, such as that TAS should not be middleware, and API traffic should flow directly between apps and not through TAS.
- Platform independant. We wanted app developers to be able to build apps in any programming language, on any framework, and host their apps anywhere.
Non-goals for TAS
We designed TAS to be as thin as possible - to do just what's needed to allow HR SaaS microservices to work
together, and no more. This philosophy means there are many things that TAS is not:
- TAS is not a central list of APIs that apps can use to talk to each other (though it does hold definitions of APIs). TAS does authorize and guide API traffic between apps based on the tenant's choices, but it does not specify what those APIs are. Where platforms like Force.com allow developers to create multitenant add-on applications that integrate into the mothership Salesforce.com application, in TAS, all apps are equal. Since there is no mothership application, just apps calling APIs on each other and protecting their resources via SSO, it follows that app developers are free to use any existing APIs, or to define their own.
- TAS is not a programming language or a framework. You write your apps in your language of choice, be it .NET, Java, php, python/django, golang, Clojure, Grails or any other modern web platform. You store your data in your chosen database, and produce and consume RESTful APIs using your framework of choice.
- TAS is not an SDK or library. Instead, apps embed or use a hosted TAS network proxy, which shields the app from dealing with security and cryptography.
- TAS is not an IaaS (like AWS) **or a hosting platform or PaaS** (like Salesforce's Force.com), but rather an iPaaS. You host your apps on your own infrastructure.
- TAS is not an ESB (Enterprise Service Bus) like Mulestoft or WSO2. API traffic flows directly between apps, and does not pass through any central server. TAS is not a bottleneck or a point of failure.
- TAS is not an IdP (identity provider) like OpenAM, WSO2 or OneLogin. TAS allows tenants to hook up their own chosen SAML IdPs and/or popular OpenID-based platforms such as Google, LinkedIn or Facebook, and to augment with additional rules (e.g. only users with email addresses like<EMAIL_ADDRESS>can log in). TAS then concentrates all of the tenant's multiple identity providers by acting as a SAML proxy so that your app (acting as a SAML service provider) sees a single, unchanging IdP which handles authentications for your app.
- TAS is not an API gateway, like Mashape Kong or Axway. Since API calls flow directly between apps, and do not pass through TAS, you might still want to place your app behind some API gateway to achieve rate limiting, analytics/metrics capture and logging, security filtering (checking the content on incoming messages for attacks), or redirection/traffic routing to different endpoints in your own infrastructure depending on the sender or the request. TAS does provide API gateway behaviour related to access control, for example the context for verifying OAuth tokens.


Lets hash out these objects
September-30th-2015
So, we are all thinking about it. Do I need to be the only one to bring it up? Okay fine! I guess I will be that guy.... So have you ever noticed a Javascript object looks a lot like a hash in Ruby? There! I SAID IT!!! lets let the dust settle for a second and figure out just where we stand. I know this may be hard for some of us to handle, we have spent our whole lives knowing but not saying this little fact. But lets all come together and talk about this right now.
So why do they look the same? How can they be considered the same and how are they different? So we have spent a lot of time in ruby and nowe are onto JavaScript. It is a new and exciting(very scary) world out there DBC people! We know that in Ruby a hash is a |key, value| pair. When you declare a Hash you are going
blah = {key => value} or blah ={key => value, other_key => other_value}They key is used to access the value (Weird right?) so that if you went \n blah.key you would get the value (super weird!). Now JaveScript objects act the same way!
An object in JavaScript is a way of declaring something that will hold many key value pairs. It is mainly used for OOP (but we will get into that another time) They are declared many ways, but the only way I like (and that means it is the only way you like damn it!) is the var blah = { }. Lets look at just what this means by creating an object car and putting things into it.
var car = { type: "BMW", year: 2015, horse_power: 320 }So what is going on there? We look and we have made a variable called car. This variable is then made an object by the {}. Inside these brackets we declare a key, and a value for that key. We can then call these keys to get new information.
car.type => "BMW"And like a hash in Ruby, the value can be anything. It can be a string, a boolen, a number, MORE OBJECTS!, functions... you get where I am going with this.  This is just one small look into how they are the same. More to be added later DBC crew!.


|
This technical report defines version 1.3 of the Linear Topic Map Notation, also known as LTM. It provides both an introduction and a formal definition, the latter in the form of a complete EBNF specification given in section 3.
Please note that this document is not a formal specification from any recognized standards body, but a Technical Report published by Ontopia, a commercial company, for the convenience of all interested parties. ISO is currently finishing standardization of an alternative standardized syntax called CTM. For more information, see the CTM home page.
The Linear Topic Map notation (LTM) is a simple textual format for topic maps. Just like XTM, the XML interchange format, it represents the constructs in the topic map standard as text, but unlike XTM it is compact and simple. The notation can be written in any text editor and processed by topic map software that supports it, or converted into the XML format supported by such software.
The XML-based topic map interchange format is defined in such a way as to make it easy to understand for humans and to develop software for, and these purposes it fulfills very well. However, this has the cost of making it awkward to read and write for humans. Humans were not really intended to do this, of course, they were intended to use specialized topic map editors, which would insulate their users from the syntactical details of the interchange format.
Despite the existence of editors there is still a need for a simple textual format that can be used to concisely and clearly express topic map constructs in emails, discussions and similar contexts. Such a format also makes it easy to quickly create and maintain small topic maps for demonstration and personal purposes.
While you may find that this syntax provides you with a convenient and easy way to maintain your topic maps, please note that the only standardized form for interchangeable topic maps remains the XTM 1.0 syntax.
The notation has been developed by Ontopia. Steve Pepper came up with the original idea, based on the linear notation for conceptual graphs. The notation has since been refined by Lars Marius Garshol, with input from Geir Ove Grønmo, Steve Pepper, and Kal Ahmed. Useful contributions from Murray Altheim, Akio Yamamoto, Robert Barta, Michael Chapman, Thomas Flemming, Are D. Gulbrandsen, Kaj Hejer, Eirik Jensen Opland, Tom-Anders N. Røst, and Ian Meikle are also gratefully acknowledged. Lars Heuer pointed out a number of mistakes in and suggested one improvement to version 1.3.
While the copyright to both this description and the format itself is held by Ontopia, Ontopia reserves only the right to be recognized as the originator of the notation. Permission to use it in any way for any purpose whatsoever is hereby granted in perpetuity to all potential users.
The following changes have been made in version 1.3 relative to version 1.2:
The #INCLUDE directive has been added.
The #VERSION directive has been added.
The #PREFIX directive (and support for qualified, or prefixed, names) has been added.
Support for reification has been added.
Support for variant names has been added.
The escape syntax for Unicode characters (and quotes) in strings has been added.
The following features of XTM 1.0 are not supported:
Variant names that are external resources referred to by URI.
When merging in external topic maps with the MERGEMAP directive it is not possible to add scopes to the merged-in topic characteristic assignments. This is not properly an unsupported model construct, but is still a feature of the XTM 1.0 syntax that is missing from LTM.
Untyped occurrences, associations, and association roles.
Association roles with unspecified players.
In addition, none of the new features of the upcoming Topic Maps Data Model and XTM 1.1 specifications are supported.
The basis of the notation is the ability to define topics, which is done by writing the ID of the topic in square brackets. An example is shown below.
[ltm]
This represents a topic map consisting of a single topic that has the ID 'ltm', but no other characteristics. If you want, you can provide it with a base name and a sort name as well, as in the example below. The sort name is optional.
[ltm = "The linear topic map notation"; "linear topic map notation, the"]
You can even add a display name. If you have a display name the sort name is optional, but you need two semicolons to tell the parser that the second name is a display name and not a sort name. The example below shows a topic with all three name types.
[foo = "basename"; "sortname"; "dispname"]
The topic can also be typed. The example below adds the type 'format' to the ltm topic. Multiple type IDs can be listed after the colon, separated by whitespace, if the topic has more than just one type.
[ltm : format = "The linear topic map notation"; "linear topic map notation, the"]
Note that even if no topic with the ID 'format' is defined anywhere in the LTM file this reference will cause the topic to be created by the LTM processor. The 'format' topic will have an ID, but no other characteristics. Note also that LTM is oblivious to whitespace. You can add as much whitespace as you want anywhere (except inside strings) without having any effect on the resulting topic map.
LTM also supports providing subject indicators for topics, as shown below. The URL of the subject indicator is quoted and preceded by an '@' character. Any number of subject indicators can be given.
[ltm : format = "The linear topic map notation"; "linear topic map notation, the" @"http://www.ontopia.net/download/ltm.html"]
For topics which represent information resources it is not necessary to use a proxy resource (a subject indicator) to indicate the identity of the subject; it can instead be referred to directly. LTM supports this, by using a '%' character followed by the quoted URL of the resource. An example is shown below.
[xmlspec : specification = "The XML 1.0 specification" %"http://www.w3.org/TR/REC-xml"]
The final construct supported by LTM for topics is scoping of names. This can be done for the base name, sortname, dispname-trinity as a whole, by appending a topic ID preceded by a slash after the name, as shown below. Multiple topic IDs are allowed, separated by whitespace.
[ltm : format = "Den lineære emnekart-notasjonen"; "lineære emnekart-notasjonen, den" / norwegian @"http://www.ontopia.net/download/ltm.html"]
Note that if this example and the previous [ltm] example were to appear in the same LTM file it would cause a single topic to be created with the union of the characteristics of these two definitions. That means that the topic would have the 'ltm' ID, the format type, the two different name sets and the given subject indicator.
Note also that there are no requirements on the order in which constructs appear in LTM files. A topic type can be used before it is defined, for example.
The LTM notation also supports defining associations. In the example below the LTM topic defined above is associated with a topic with the ID 'topic maps' by an association that has the format-for type. ('format-for' is of course the ID of the topic that types that association.)
format-for(ltm, topic-maps)
The meaning of this example is that LTM is a serialization format for topic maps. This should perhaps be made clearer by adding association role types. The example below does this.
format-for(ltm : format, topic-maps : standard)
Note that if the association role type is omitted the role type will default to the type of the topic (provided it has one). If the topic has more than one type, one of these will be selected at random. The rationale for this was that it is a useful shorthand for a commonly occurring construction; we urge caution in the use of this construct, however, as it can cause difficulties when topics have multiple types or when their types change.
As a shorthand it is allowed to specify a topic in the role player position, instead of just referencing it. All the constructs used when defining topics can be used here, which means that it is possible to define topics with their characteristics in the associations they participate in without defining them anywhere else. The example could therefore also have been written as follows.
format-for(ltm, [topic-maps : standard = "Topic maps"])
Associations can also be scoped, as with base names, by appending a slash followed by the IDs of the scoping topics, separated by whitespace. The example below illustrates this.
[lmg : person = "Lars Marius Garshol"] format-for(ltm : format, topic-maps : standard) / lmg
LTM also supports defining occurrences. This is done using the notation shown below, where the occurrence information is given in curly braces. Three pieces of information, all of which are required, appear inside the braces, separated by commas. The first is the ID of the topic which has the occurrence, the second is the ID of the occurrence role type and the third is the locator of the occurrence in double quotes.
{ltm, specification, "http://www.ontopia.net/download/ltm.html"}
You can also specify the resource data of an occurrence inline in the LTM file, as shown below.
{ltm, description, [[A simple text-based format for topic maps.]]}
Occurrences are scoped in the same way as associations:
{ltm, specification, "http://www.ontopia.net/download/ltm.html"} / english
Below is given a more complete example of an LTM topic map. Note that text appearing between '/*' and '*/' is comments.
/* topic types */ [format = "Format"] [standard = "Standard"] [organization = "Organization"] /* association types */ [format-for = "Format for"] [defined-by = "Defined by"] /* occurrence types */ [specification = "Specification"] [homepage = "Home page"] /* topics, associations and occurrences */ [topic-maps : standard = "Topic maps" = "ISO/IEC 13250 Topic Maps" / fullname] {topic-maps, specification, "http://www.y12.doe.gov/sgml/sc34/document/0129.pdf"} [xtm : format = "XTM Syntax"] [ltm : format = "The linear topic map notation"; "linear topic map notation, the" @"http://www.ontopia.net/topicmaps/ltm-tech-report.html"] {ltm, specification, "http://www.ontopia.net/topicmaps/ltm-tech-report.html"} format-for(ltm, topic-maps) format-for(xtm, topic-maps) defined-by(ltm, ontopia) defined-by(xtm, topicmaps.org) [ontopia : organization = "Ontopia AS"] {ontopia, homepage, "http://www.ontopia.net"} [topicmaps.org : organization = "TopicMaps.Org"] {topicmaps.org, homepage, "http://www.topicmaps.org"}
Variant names are used to represent names that are alternative forms of a base name. An example of this might be:
[xml = "Extensible Markup Language" ("XML" / acronym) ("Extended Markup Language" / erroneous)]
The canonical name for XML is "Extensible Markup Language", but there are two related forms of it: "XML", which is the acronym, and "Extended Markup Language", which is an often found (but wrong) form of it. The example above represents these as variants of the base name. Note that all variants must have a scope.
Note that sort name, display name, and base name scope must come before the variants, as shown below.
[xml = "Extensible Markup Language"; "extensible markup language" / english ("XML" / acronym) ("Extended Markup Language" / erroneous)]
Reification may sound scary, but it's actually quite simple. If you have a name, or association, or occurrence, or association role that you want to say more about, how do you do it? For example, imagine that you have an association like the one below, which states that I work for Ontopia.
employed-by(lmg : employee, ontopia : employer)
What if you want to say when I started working for Ontopia? It's possible to do this by turning the employment into a topic and using two associations (one from me to the employment and another from the employment to Ontopia), but if you don't want to do that you are stuck, because topic maps don't let you put an occurrence on an association.
This is where reification comes in: you create a topic that represents the association (that is, the topic reifies the association). Then you can assign an occurrence to the reifying topic, and all is well.
The way to do this in LTM is to add ~ topicid after the construct you want to reify. The ID is the ID of the reifying topic, which you can use directly. So for the example above it would be:
employed-by(lmg : employee, ontopia : employer) ~ lmg-employment {lmg-employment, start-month, [[2000-04]]}
Similarly, to reify an occurrence, you could do this:
{topicmaps.org, homepage, "http://www.topicmaps.org"} ~ tm.org-hp last-modified-by(tm.org-hp : modified, lmg : modifier)
This would say that I'm the last person to modify this occurrence. For names, the syntax would be as shown below.
[ltm : syntax = "LTM" / acronym ~ltm-name] [ltm-name : name = "The name 'LTM'"] invented-by(ltm-name : invention, steve-pepper : inventor)
Special syntax is needed to reify the topic map; for that, see section 2.7.1.
LTM has a concept of so-called "syntax directives", which are used not to represent topic map constructs, but to provide information related to processing. There are six different directives, each covered in a separate section below.
The TOPICMAP directive is used to make it possible to reify the topic map itself. (How to reify other parts of the topic map is shown in section 2.6.) This is useful, since it makes it possible to attach metadata to the topic map using topic map constructs. What the directive does is to create a topic that reifies the topic map, and give it an ID.
Below is an example.
#TOPICMAP ~topicmap [topicmap = "An example topic map"]
This creates a topic topicmap, which reifies the topic map. This could then be used to add metadata about the topic map, such as:
#TOPICMAP ~topicmap [topicmap = "An example topic map"] {topicmap, publication-date, [[2005-01-12]]}
The MERGEMAP directive is used to merge external topic maps into the LTM topic map. The external topic maps can be in any syntax, but if this syntax is not LTM it must be declared what syntax it is. An example is shown below.
#MERGEMAP "geography.xtm" "xtm"
This directive causes the topic map at the given URI to be loaded according to the rules of the syntax it is written in and merged with the current topic map once the loading is complete. This means that topics defined in the loaded topic map will be merged with topics in this topic map when they have the same subject indicator or subject locator, but not because they have the same ID. (For this behaviour, see section 2.7.3.) Note that the URI is allowed to use any URI scheme, although there is no guarantee that an LTM processor will understand any URI schemes beyond 'file'.
LTM processors are required to recognize the syntaxes listed below, but not necessarily to support them. XTM and LTM must be supported, while the other syntaxes are optional. It is an error if the LTM processor is asked to merge in a topic map in a syntax it does not understand. Note that the syntax names are case-insensitive. If no syntax is specified, the default is LTM.
Directives declared in the merged-in file have no effect in the parent file, except, of course, for MERGEMAPs and INCLUDEs.
The INCLUDE is very similar to MERGEMAP, the difference being that with INCLUDE the file merged in will use the same namespace for IDs. This means that topics with the same IDs in the two files will be merged (as will topics with the same subject indicators or locators).
To use the INCLUDE directive, simply write:
#INCLUDE "other-file.ltm"
Note that unlike MERGEMAP the INCLUDE directive only supports LTM files, and the same limitations on URI schemes apply. Directives declared in the included file have no effect in the parent file, except, of course, for MERGEMAPs and INCLUDEs.
This directive is used to change the base URI against which relative URIs in the document are resolved. It works exactly like the xml:base attribute in XML Base, or the BASE element in HTML. Below is shown an example.
#BASEURI "http://www.ontopia.net/"
All URIs occurring after the directive will resolve against the given URI, which must be absolute, rather than against the URI of the LTM document itself. This applies to URIs in MERGEMAP, PREFIX, and INCLUDE directives, subject locators, subject indicators, and the URIs of occurrences. (More formally, it applies to all instances of the grammar symbol uri.) Note that the BASEURI directive does not apply inside any files included with MERGEMAP or INCLUDE.
Note that having more than one BASEURI directive in the same file is an error. Note also that same-document references, that is, URI references that consist only of a fragment identifier (of the form #foo) are relative to the file URI, not to the base URI set with this directive.
In some cases one wants to refer to a topic using its subject indicator (or, less often, subject locator) for example because it's defined in a different file that is loaded with MERGEMAP. To do that using a topic ID you have to create a new topic with an ID and give it the subject indicator, and then refer to it with the ID. The PREFIX directive makes it possible to refer to the topic directly using its subject indicator.
Below is a simple example topic map that uses this capability.
#MERGEMAP "core.xtm" "xtm" /* load superclass-subclass and other topics */ #PREFIX xtm @"http://www.topicmaps.org/xtm/1.0/core.xtm#" [sentient-being = "Sentient being"] [human = "Human"] [giraffe = "Giraffe"] xtm:superclass-subclass(sentient-being : xtm:superclass, human : xtm:subclass) xtm:superclass-subclass(sentient-being : xtm:superclass, giraffe : xtm:subclass)
The PREFIX directive here declares that the xtm prefix is used for topics whose subject indicators (that's what the @ means) begin with http://www.topicmaps.org/xtm/1.0/core.xtm#. The part after the xtm: is added to get the full subject indicator.
This can also be used for topic maps that define a lot of subject indicators, so that you could write an LTM version of core.xtm like this:
#PREFIX xtm @"http://www.topicmaps.org/xtm/1.0/core.xtm#" [xtm:superclass-subclass = "Superclass/subclass"] [xtm:superclass = "Superclass"] [xtm:subclass = "Subclass"]
These three topics would only have subject indicators and no IDs, since when declaring the topics the subject indicator is used where the topic ID would normally be.
This directive is used to indicate what version of LTM the file is written in. It has no particular effect in LTM 1.3, but if later LTM versions are incompatible with version 1.3 it is possible that parsers will use this information to process LTM 1.3 files with a different parser.
To make it clear that your LTM file is using LTM 1.3, just write:
#VERSION "1.3"
Note that the VERSION directive has to appear first of all the directives, if it is present. This restriction is there in case new directives are introduced in later versions.
Strings in LTM (that is, anything enclosed in double quotes) support two different escape syntaxes. Firstly, if you need to include a double quote in a string in LTM you can do it by writing it twice, as in the example below.
[doublequote : character = "The '""' character"]
The name of this topic will be The '"' character.
There is also a general escape syntax for all Unicode characters: \u0000. Four, five, or six hexadecimal digits can be used to give the number of the Unicode character you want to write (digits can be written in both upper- and lowercase). Thus the example above could also have been written as shown below.
[doublequote : character = "The '\u0022' character"]
The Unicode escape syntax is mostly useful for writing characters not available on your keyboard. For example, if I wanted to write 'Katakana' in Japanese, I would do it as shown below.
[katakana : syllabary = "Katakana" = "\u30AB\u30BF\u30AB\u30CA" / native]
Below is a table containing the escape sequences for some useful characters that may be needed in LTM files.
| Escape sequence | Character |
|---|---|
| \u0022 | " |
| \u0027 | ' |
| \u005B | [ |
| \u005D | ] |
| \u007B | { |
| \u007D | } |
This section defines the LTM syntax using a formal extended BNF grammar. Lexical tokens are given either as single-quoted strings directly in the grammar, or as upper-case names of token types. The token types are defined separately further below.
topic-map ::= encoding? version? directive* (topic | assoc | occur) * encoding ::= '@' STRING directive ::= topicmapid | mergemap | baseuri | include | prefix topicmapid ::= '#' 'TOPICMAP' WS (NAME | reify-id) mergemap ::= '#' 'MERGEMAP' WS uri (WS STRING)? baseuri ::= '#' 'BASEURI' WS uri include ::= '#' 'INCLUDE' WS uri version ::= '#' 'VERSION' WS STRING prefix ::= '#' 'PREFIX' WS NAME WS ('@' | '%') STRING topic ::= '[' qname (WS ':' qname+)? (topname)* subject? indicator* ']' subject ::= '%' uri indicator ::= '@' uri topname ::= '=' basename ((';' sortname) | (';' sortname? ';' dispname))? scope? reify-id? variant* scope ::= '/' qname+ basename ::= STRING sortname ::= STRING dispname ::= STRING variant ::= '(' STRING scope reify-id? ')' assoc ::= qname '(' assoc-role (',' assoc-role)* ')' scope? reify-id? assoc-role ::= (topic | qname) WS (':' qname )? reify-id? occur ::= '{' occ-topic ',' occ-type ',' resource '}' scope? reify-id? resource ::= uri | DATA occ-topic ::= qname occ-type ::= qname uri ::= STRING qname ::= NAME ':' NAME | NAME reify-id ::= '~' WS? NAME
The lexical token types defined below use Perl-style regular expressions for their definitions. Note that while whitespace (represented by the WS token type) is implicitly allowed between any two tokens, it is explicitly required in the 'topic' and 'assoc-role' productions in the above grammar. This is to avoid problems caused by the fact that a colon is allowed in topic IDs.
NAME = [A-Za-z_][-A-Za-z_0-9.]* COMMENT = /\*([^*]|\*[^/])*\*/ STRING = "[^"]*" DATA = \[\[(([^\]]+\])*|\])\] WS = [\r\n\t ]+
The NAME token type is slightly modified compared to the definition in the XML recommendation. The colon is no longer allowed as a name start character, since otherwise a single colon could be both a name and a separator.
All tokens are case-sensitive.
Comments can occur anywhere where whitespace is allowed.
All LTM files are to be processed as if they were composed of Unicode characters. Files may be in any encoding, but if that encoding is not ISO 8859-1 it should be declared using the encoding production. If the encoding declaration appears in the file it must appear at the very beginning. Support for this construct is optional, but all processors must allow it to be present and at least ignore it.
The encoding names used are those defined by IANA, which are the same as those used by XML. The IANA character encoding identifier registry can be found at http://www.isi.edu/in-notes/iana/assignments/character-sets.
Below is shown a simple example of an LTM file that uses the UTF-8 character encoding.
@"utf-8" [grove : person = "Geir Ove GrÃ¸nmo"]
(The name is of course Geir Ove Grønmo, encoded in UTF-8, but viewed as if it were ISO 8859-1.)
This section provides some clarifications for implementors in lieu of a proper specification based on TMDM.
Any topic referred to by its ID in an LTM file, but never defined anywhere by an explicit occurrence of the topic production with that topic, is automatically generated by the LTM processor. All occurrences of the same topic ID are considered to be references to the same topic.
When an instance of the topic production is found, and a topic with the same ID has already been found, the two topic definitions are merged as follows:
The types of the resulting topic are considered to be the union of the types found in each definition.
The names of the resulting topic are considered to be the union of the names found in each definition.
The occurrences of the resulting topic are considered to be the union of the occurrences found in each definition.
The associations of the resulting topic are considered to be the union of the associations found in each definition.
The subject indicators of the resulting topic are considered to be the union of the subject indicators found in each definition.
If more than one subject locator for the topic is found, the one occurring last in the file is used.
If two topic definitions are found which have different topic IDs, but in which the same name occurs in the same scope, no specific behaviour is guaranteed. Possible results are that the topics may be merged, that they may remain distinct and that an error may be signalled. Topics with equal subject locators or subject indicators but different IDs are merged.
Note that although display names and sort names have a syntax that is different from the general syntax for variant names they are still considered variant names with the 'sort' and 'display' scopes from XTM 1.0.
The INCLUDE directive requires special handling in the parser. What happens (during all LTM processing, whether INCLUDE is used or not) in terms of the Topic Map Data Model (TMDM) is that topic IDs turn into source locators of the form uri-of-ltm-file#topic-id. When a file is included with INCLUDE all topics in the included file get two source locators, one with the URI of the included file, and one with the URI of the file that includes. (This is what causes the merge by ID across the files.)
The reify-id production works as follows in TMDM terms (where id is the id given in the reify-id production):
If no topic with the id exists, one is created. If a topic exists, that is the topic used below.
A source locator of the form uri-of-file#--reified--id (replace 'id' with the reification id) is added to the topic map construct being reified.
A subject identifier of the form uri-of-file#--reified--id (replace 'id' with the reification id) is added to the reifying topic.
#TOPICMAP ~tm
In the example above, a topic with the id tm would be created, and have the source locator file.ltm#tm assigned to it. The topic map would have the source locator file.ltm#--reified--tm assigned to it, and the same URI would be assigned to the created topic as a subject identifier.
The PREFIX directive causes qualified names like foo:bar to be interpreted as references to the topic with the expanded URI (the prefix URI + the part after the colon) as its subject indicator (if the prefix declaration used '@') or locator (if '%' was used). Note that qualified names can also be used in a topic definition as below:
[xtm:superclass-subclass = "Superclass/subclass"]
This topic has no source locator (since it has no topic ID); instead the qualified name gives it a subject indicator.


Liverpool midfielder Fabinho out until January with injury
by The Canadian PressLIVERPOOL, England — Liverpool says defensive midfielder Fabinho will be out until January with a knee injury, putting more strain on the Premier League leaders with a packed schedule coming up.
Fabinho went off injured in Liverpool’s 1-1 draw with Napoli in the Champions League on Wednesday with ankle ligament damage.
The Brazilian has started all five of Liverpool’s games in the Champions League this season and 12 of 13 in the Premier League.
Liverpool has 10 games to play before the end of the year — six in the Premier League, a Champions League match against Salzburg, two games at the Club World Cup and one in the League Cup.
___
More AP soccer: https://apnews.com/Soccer and https://twitter.com/AP_Sports


I am currently pursuing Bachelors of Technology in Computer science with specialization Cybersecurity and Forensics.
To enhance my educational and professional skills in a stable and dynamic workplace. I enjoy creative problem solving and getting exposure on multiple projects, and I would excel in the collaborative environment on which your company prides itself. Also to secure a challenging position in a reputable organization to expand my learnings, knowledge, and skills.
Hobbies


Man held for cheating women
by Special CorrespondentMan held for cheating
A 41-year-old man was arrested on Friday in Mylapore for allegedly exploiting women he befriended on social media and stealing their jewellery and valuables on the pretext of marriage. Jayachandran was arrested based on a complaint by a 31-year-old woman physiotherapist in Mylapore. He would target divorced or estranged women over social media, and get their phone numbers. He then made false promises of marriage, the police said.


Club Championship 2021 Juveniles
| Juveniles |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
| Name |
Current rank |
Events
Completed |
Best 9 |
Thorpe Langton 10 |
Naseby 10 |
Thorpe Langton 10 |
Naseby 10 |
Naseby 10 |
Kibworth 10 |
Kibworth 10 |
Middleton 25 |
Kibworth 10 |
Bruntingthorpe 10 |
Bruntingthorpe 10 |
Bruntingthorpe 10 |
Bruntingthorpe 10 |
Kibworth 10 |
Husbands Bosworth 25 |
Hill Climb |
Flying 5 |
| Dominic
Switzer |
1 |
13 |
540 |
55 |
60 |
60 |
60 |
60 |
60 |
0 |
0 |
60 |
60 |
60 |
60 |
60 |
0 |
0 |
60 |
60 |
| Alex
Smith |
2 |
11 |
515 |
60 |
0 |
55 |
0 |
55 |
0 |
60 |
60 |
55 |
55 |
0 |
0 |
55 |
60 |
0 |
55 |
55 |
| Jamie
Kershaw |
3 |
8 |
425 |
0 |
55 |
0 |
0 |
51 |
0 |
55 |
0 |
0 |
51 |
51 |
51 |
51 |
0 |
60 |
0 |
0 |
| Huw
Wilson |
4 |
6 |
315 |
51 |
0 |
51 |
55 |
0 |
0 |
0 |
0 |
0 |
0 |
55 |
55 |
48 |
0 |
0 |
0 |
0 |
| Florence
Switzer |
5 |
2 |
102 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
51 |
51 |
| Ruby
Isaac |
6 |
2 |
94 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
48 |
0 |
0 |
46 |
0 |
0 |
0 |
0 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|