OpenLLM-France/wikimedia huggingface dataset:
# Roman Culture/Gladiators

In Ancient Rome, gladiatorial fights were a form of entertainment. These fights were housed in structures called amphitheaters. One of the most famous amphitheaters is called the Coliseum. Gladiators consisted of condemned criminals, slaves, prisoners-of-war, or volunteers that were bound by an oath. There were many types of gladiators. Some of these types were the Murmillo, the Thraex, the Hoplomachus, the Provocator, the Secutor, and the Retiarius. The gladiators were separated into these types by body type and the weapons they used. Some gladiators, like the Murmillo, used a sword and a shield and some, like the Retiarius, used nets. In rare occasions women would fight as gladiators. Dunkle says about female gladiators, “Aristocratic women and men fought as an entertainment for Nero in 63 AD. Domitian had women fight by torchlight and on another occasion had women fight with dwarves. Romans loved these exotic gladiatorial combats."
The gladiatorial training was a serious business. The gladiators both lived and trained in gladiator schools. There were four major gladiator schools in Ancient Rome. The names of these schools were Magnus, Dacius, Gallicus, and Matutinus. These schools were run by a "Lanista", who was often an ex-gladiator. Later, these schools were taken over by the state. The gladiators were kept under lock and key when they were not training or fighting. Some of the ceilings in the schools were so low that the gladiators could only sit or lay down. The barracks were also very unclean. The foods gladiators often ate were very healthy, although gross.
Many gladiators were forced to learn the concept of death. When the gladiators were fighting, the emperor would give a Verso Pollice which was a twist of the thumb to tell the gladiators if he wanted the other to die or live. Most of the time the emperor would spare the gladiators’ lives, but when he sentenced them to death, the Gladiators would have to die honorably. The gladiatorial games were a major source of entertainment for the Roman people, and people from all over Rome would come to watch them fight.
EDIT: 12-10-11 Rojen: scanned for spelling and plagiarism. Work Cited
Dunkle, Roger. Gladiators: Violence and Spectacle In Ancient Rome. Great Britain: Pearson Education Limited, 2008. Print. Dunkle, Roger. "The Gladiator." Roman Gladiatorial Games. Web. 23 Nov. 2011.
Grant, Michael. Gladiators. Barnes & Noble, Inc, 1995. Print.
Meijer, Fik. The Gladiators: History's Most Deadly Sport. Netherlands: Atheneum- Polak & Van Gennep Amsterdam, 2003. Print.

## References

* ↑ The Gladiator, by Dunkle, R.
# Semantic Web/Resource Description Framework
## RDF - Resource Description Framework

A triple can simply be described as three URIs. A language which utilises three URIs in such a way is called RDF: the W3C have developed an XML serialization of RDF, the "Syntax" in the RDF Model and Syntax recommendation. RDF XML is considered to be the standard interchange format for RDF on the Semantic Web, although it is not the only format. For example, Notation3 (which we shall be going through later on in this article) is an excellent plain text alternative serialization.
Once information is in RDF form, it becomes easy to process it, since RDF is a generic format, which already has many parsers. XML RDF is quite a verbose specification, and it can take some getting used to (for example, to learn XML RDF properly, you need to understand a little about XML and namespaces beforehand...), but let's take a quick look at an example of XML RDF right now:-

## Why RDF?

When people are confronted with XML RDF for the first time, they usually have two questions: "why use RDF rather than XML?", and "do we use XML Schema in conjunction with RDF?".
The answer to "why use RDF rather than XML?" is quite simple, and is twofold. Firstly, the benefit that one gets from drafting a language in RDF is that the information maps directly and unambiguously to a model, a model which is decentralized, and for which there are many generic parsers already available. This means that when you have an RDF application, you know which bits of data are the semantics of the application, and which bits are just syntactic fluff. And not only do you know that, everyone knows that, often implicitly without even reading a specification because RDF is so well known. The second part of the twofold answer is that we hope that RDF data will become a part of the Semantic Web, so the benefits of drafting your data in RDF now draws parallels with drafting your information in HTML in the early days of the Web.
The answer to "do we use XML Schema in conjunction with RDF?" is almost as brief. XML Schema is a language for restricting the syntax of XML applications. RDF already has a built in BNF that sets out how the language is to be used, so on the face of it the answer is a solid "no". However, using XML Schema in conjunction with RDF may be useful for creating datatypes and so on. Therefore the answer is "possibly", with a caveat that it is not really used to control the syntax of RDF. This is a common misunderstanding, perpetuated for too long now.
# Semantic Web/Semantic Web Applications
## Semantic Web Applications

Unfortunately, the Semantic Web is dissimilar in many ways from the World Wide Web, including that you can't just point people to a Web site for them to realise how it's working, and what it is. However, there have been a number of small-scale Semantic Web applications written up. One of the best ones is Dan Connolly's Arcs and Nodes diagrams experiment:-
Of course, this is a rather demonstration-oriented Semantic Web project, but it does illustrate the feasibility of applications being easily built using Semantic Web toolkits.
Another good example of the Semantic Web at work is Dan Brickley et al.'s RDFWeb. RDFWeb is a RDF database-driven hypermedia blogspace, a site where all information is stored as RDF, and then that RDF used to render XHTML. Plans are underway to incorporate more advanced Semantic Web principles into the site. What Can I Do To Help?
There are many ways in which one can contribute to creating the Semantic Web. Here's a few of them:-
There are many other ways in which one can help as well: ask in the community for more details. What Now? Further Reading
As of 2001-09, the amount of Semantic Web Education and Outreach materials can only really be described as "pitiful" (hence this introduction, for a start). Here's a short list of some of the good primers and materials currently available, in no particular order:-
For more information, all the latest news etc., Dave Beckett's Resource Description Framework (RDF) Resource Guide is absolutely brilliant.
Many Semantic Web and RDF developers hang out on the RDF IG IRC chatroom, on irc.openprojects.net, #rdfig.
# Semantic Web/Transformability: Small Scale to Medium Scale
## Transformability: Small Scale to Medium Scale

An example of a small-scale Semantic Web system joined together to make a medium-sized Semantic Web system could be two groups that have published address book formats wanting to make a larger and better address book format by merging the two current formats together. Anyone using one of the old address book formats could probably convert them into the new format, and hence there would be a greater sense of interoperability. That's generally what happens when one goes from a small-scale Semantic Web system into a medium-scale Semantic Web system, although this is often not without some disadvantages and incompatibilities. The Semantic Web takes the sting out of it by automating 99% of the process (it can convert field A into field B, but it can't fill in any new data for you... of course, new fields can always be left empty for a while).
# Semiconductor Electronics

* About this book
* Types of Materials

## Semi Conductors

* Semiconductor
* Depth in look of semiconductors

## Diode

* Diode
* Diode Applications

## Transistor

* Bipolar Junction Transistor
* DC Biasing-BJTs
* BJT Transistor Modelling
* BJT Small-Signal Analysis
* Transistor Applications

## FET

* Field Effect Transistor
* FET Biasing
* FET Small-Signal Analysis
* Systems Approach-Effects of R$_S$ and R$_L$
* BJT and JFET Frequency Response
* FET Applications

## Operational Amplifiers

* Operational Amplifiers
* OP-AMP Applications
* Op Amp Applications

## Other Topics

* Power Amplifiers
* Linear-Digital ICs
* Feedback and Oscillator Circuits
* Power Supplies
* Discrete Components Manufacture
* Integrated Circuits
* Software
* Reference
* Back Cover
# Semantic Web/Screen Scraping, and Forms

For the Semantic Web to reach its full potential, many people need to start publishing data as RDF. Where is this information going to come from? A lot of it can be derived from many data publications that exist today, using a process called "screen scraping". Screen scraping is the act of literally getting the data from a source into a more manageable form (i.e., RDF) using whatever means come to hand. Two useful tools for screen scraping are XSLT (an XML transformations language), and regular expression (in Perl, Python, and so on).
However, screen scraping is often a tedious solution, so another way to approach it is to build proper RDF systems that take input from the user and then store it straight away in RDF. Data such as you may enter when signing up for a new mail account, buying some CDs online, or searching for a used car can all be stored as RDF and then used on the Semantic Web.
# Semantic Web/The Power Of Semantic Web Languages

The main power of Semantic Web languages is that any one can create one, simply by publishing some RDF that describes a set of URIs, what they do, and how they should be used. We have already seen that RDF Schema and DAML are very powerful languages for creating languages.
Because we use URIs for each of the terms in our languages, we can publish the languages easily without fear that they might get misinterpreted or stolen, and with the knowledge that anyone in the world that has a generic RDF processor can use them. The Principle Of Least Power
The Semantic Web works on a principle of least power: the fewer rules, the better. This means that the Semantic Web is essentially very unconstraining in what it lets one say, and hence it follows that anyone can say anything about anything. When you look at what the Semantic Web is trying to do, it becomes very obvious why this level of power is necessary... if we started constraining people, they wouldn't be able to build a full range of applications, and the Semantic Web would therefore become useless to some people. How Much Is Too Much?
However, it has been pointed out that this power will surely be too much... won't people be trying to process their shopping lists on an inference engine, and suddenly come up with a plan for world peace, or some strange and exciting new symphony?
The answer is (perhaps unfortunately!) no. Although the basic parts of the Semantic Web, RDF and the concepts behind it are very minimally constraining, applications that are built on top of the Semantic Web will be designed to perform specific tasks, and as such will be very well defined.
For example, take a simple server log program. One might want to record some server logs in RDF, and then build a program that can gather statistics from the logs that pertain to the site; how many visitors it had in a week, and so forth. That doesn't mean that it'll turn your floppy disc drive into a toaster or anything; it'll just process server logs. The power that you get from publishing your information in RDF is that once published in the public domain, it can be repurposed (used for other things) so much easier. Because RDF uses URIs, it is fully decentralized: you don't have to beg for some central authority to publish a language and all your data for you... you can do it yourself. It's Do It Yourself data management.
# Semiconductor Electronics/About this book
## Philosophy

Hello, readers. This book is sponsored by Mind As Lab publication, a company which I started to create free and open-source documentation and software creation. When I buy technical books in India, they are surely substandard. Books that are sold in USA and Europe have color prints, hence they helps those students understand better. Those copies that were printed for India, Pakistan and other nations had only black and white content. They were done so to make those books cheap.
Here in Wikipedia I have the opportunity to create a book for electronics with Multimedia content. Once the books has enough volume, it will be converted to PDF and published on the internet for free (free over here stands for freedom like free speech, not like free beer).
This book aims to provide software to make student life easy. Currently Mind As Lab is experimenting with animation. If it becomes a success, in the far future this book will provide built-in movies explaining selected concepts.

## Target

Semiconductor Electronics is a book that is targetted at students studying electronics. This book was initially started by A.K.Karthikeyan to provide comprehensive material for students.

## Authors

* A.K.Karthikeyan
If you have contributed to this book, feel free to add your name.

## Support

Thanks to many for their support in writing this book. Special thanks to Mind As Lab, which will publish this book in full color print in the Indian subcontinent. Thanks to Chitra and Sohail, graphic designers at Mind As Lab, for providing many SVG images that will enhance the book. Thanks to all open-source programmers who have released various tools under the GPL license (specially under GPL v.3); it is really them who need to be credited.
Thanks to the Mind As Lab accounting team for providing funding worth Rs.200/week to make this book a reality. I wish more funds be forthcoming.
# Scriptapedia/Memo on Variation of Scripts

Scripts are documented basic behavior units in Group Model Building (Hovmand, Rouwette, Andersen, Richardson, Calhoun, Rux, Hower, 2011). Variations of scripts can be added to the scripts under "notes". For instance, in Reflector Feedback (Hovmand), the script can be used interactively rather than for presentation, as indicated by the notes section of the script. However, if significant changes have been made between the original and the current version, then it may qualify as an entirely new script (Hovmand, Rouwette, Andersen, Richardson, Calhoun, Rux, Hower, 2011). An example would be Cookie Exercise which is similar to, but significantly different from the Water Glass Demonstration.
Hovmand, P. S., Andersen, D. F., Rouwette, E., Richardson, G. P., Rux, K., & Calhoun, A. (2012). Group model‐building ‘scripts’ as a collaborative planning tool. Systems Research and Behavioral Science, 29(2), 179-193.
# Scriptapedia/Model Review
## Model Review

This script is used to summarize dynamic insights and stories, clarify fuzzy ideas, capture additional information about model structure, and elicit feedback from participants after causal structures have been developed, typically at the end of a session.

### Status

Best practices

### Primary nature of group task

Convergent

### Time

Preparation time: 5 minutes
Time required during session: 15 minutes
Follow-up time: 0 minutes

### Materials

* Screen
* Projector

### Inputs

* Diagram of model

### Outputs

* List of main feedback loops and dynamics identified
* List of insights gained from the connection circle exercise and subsequent model

### Roles

* Modeler with experience building models
* Reflector with extensive experience building and analyzing system dynamics models
* Recorders with note-taking experience

### Steps

* At the start of the model review, the modeler moves up to the front of the room.
* The modeler describes the causal loop diagram and stresses that this is another reflection of the exact same linkages and variables discussed during the exercise and that none of these elements have been changed. Modeler notes that plus and minus signs mean the same as in the previous exercise.
* In a causal diagram, the modeler takes care to explain reinforcing and balancing loops by tracing examples within the model (if available). Modeler introduces the reflector so that the reflector can discuss more insights regarding feedback within the model.
* The reflector reviews key insights from the causal map and reads back the stories associated with major reinforcing and balancing feedback loops, intervention points, etc.
* After the reflector has reviewed the diagram, the reflector then initiates questioning regarding what didn’t get recaptured or is missing from the diagram. The reflector assesses confirmation of the adequacy of the diagram as a representation of the group thinking. The recorders document the insights shared.
* The reflector also will point out subsequent, important changes in structure, help the group identify what is happening with the modeling, and highlight model-based insights that emerge.

### Evaluation Criteria

* A revised causal loop diagram that is based on an initial discussion
* A shared understanding of the changes in the model and insights that have emerged

### History

Based on the original script “Causal Mapping from Discussion” by Peter Hovmand, created on April 19, 2010.

### Revisions

Revised May 22, 2012 by Alison Kraus and Peter Hovmand.
Revised March 4, 2012 by Meagan Colvin and Peter Hovmand.

### References

Richardson, G. P. (1997). Problems in causal loop diagrams. System Dynamics Review, 13(3), 247-252.
# Scriptapedia/Initial Policy Options
## Initial Policy Options

This script is used to help the group model building team frame the problem and elicit variables implicitly, or by implication, toward the beginning of a group model building session.

### Status

Best practices

### Primary nature of group task

Divergent

### Time

Preparation time: 5 minutes
Time required during session: 45 minutes
Follow-up time: 0 minutes

### Materials

* Markers
* 8.5x11” (or A4) paper
* Glue sticks, blue tack, and/or masking tape for posting on the wall

### Inputs

None

### Outputs:

The list of specific candidate policy options

### Roles

* Facilitator with modest experience in SD
* Wall-builder to cluster the policy options on the wall and describe the resulting theme groups (clusters)

### Steps

* The facilitator sets up the task by asking participants to write short phrases naming policies that participants would like to see discussed, modeled, and simulated in the course of the work. There should be one policy per page. They could be policies tried currently or in the past, or policies being talked about for the future. This includes ideas that are considered realistic, as well as “wild” ideas that exceed expectations for what is feasible.
** The participants may work in pairs to build confidence and share thinking while still keeping the divergent nature of the group task.
* The facilitator collects policy pages one at a time (receiving one page per pair and going on to the next pair to assure complete involvement) and asks each pair to talk about their proposed policy option.
* The wall-builder posts the policy pages on the wall, clustering them on the fly according to emerging themes.
* Repeat steps 2 & 3 until done, or time runs out.
* The facilitator asks the wall-builder to describe the theme groups (clusters), justify the choice of clusters, and talk about what he or she sees in the clustering.

### Evaluation Criteria:

* Long list of candidate policy options
* List of realistic and appropriate policy options
* List of policy options helpful for the model building

### Authors

Unknown

### History

This script was used by Andersen & Richardson, individually and as a team, for years. This script could be said to stem from Nate Mass’s 1980 observation on a draft of the Richardson-Pugh text (expressed to Richardson) that defining problems dynamically is only part of the story, that many times consultants and modelers have only lists of policy options to use to begin the modeling process.

### Revisions

Some revisions have probably been made, but because the script is simple, revisions would have been few and probably hard to identify. Clustering could have been a revision early on.

### References

None

### Notes

None
# Scriptapedia/License

Content in Scriptapedia is licensed under the Creative Commons Attribution-ShareALike 3.0 Unported License. Anyone is free to share (copy, distribute, and transmit the work) and remix (adapt the work) under the following conditions: (1) users must attribute the work in a manner specified by the author of the content, but not in a way that suggests that they endorse or are using adaptation, and (2) if a user alters, transforms, or builds upon another author's or authors’ works, users can distribute the resulting work only under the same or similar license as this one. With this understanding, any of the above conditions can be waived if the user gets permission from the copyright holder.
If any or all of the elements of the work is already in public domain under applicable law, that status is in no way affected by the license. The following rights are also unaffected by the license: (1) users fair dealing or fair use rights, or other applicable copyright exceptions and limitations, (2) author's moral rights, and (3) rights other persons may have either in the work itself or in how the work is used, such as publicity or privacy rights. For any reuse or distribution, the user reusing or distributing Scriptapedia and its contents must make clear to others the license terms of this work. The best way to do this is by copying this page or linking to the Creative Commons Attribution-ShareALike 3.0 Unported License website.
# Scriptapedia/Logistics and Room Set Up
## Logistics and Room Set Up

This script is used to create an inviting and conducive environment for GMB participants before the GMB session begins.

### Status

Best practices

### Primary nature of group task

Offline

### Time

Preparation time: 30 minutes
Time required during session: 45 minutes
Follow-up time: 0 minutes

### Materials

* The materials needed for group model building session

### Inputs

A drawing for how the room should be set up

### Outputs

A plan for room set-up

### Roles

* Facilitators experienced in GMB and the design of the workshop

### Steps

* Arrange the table, chairs, and flip charts in the room in a manner conducive to upcoming activities and scripts. Consider how participants should be sitting:
** In a semicircle facing either the wall where a model is projected, the white board, or the chalkboard.
** In clusters of tables so participants can work in small groups.
* Arrange power cords, tables, and chairs for members not sitting at the table with participants (e.g., recorders, modelers, coaches).
** Secure any power cords and extension cables with tape to minimize the risk that people may trip.
* Arrange refreshments in a place that is convenient for participants to get up and access during the session.

### Evaluation Criteria:

* Thoughtful room set-up that will contribute to participants’ comfort, engagement, and understanding

### Authors

Andersen and Richardson

### History

Documented by Annaliese Calhoun in 2010 based on Luna-Reyes et al. (2006).

### Revisions

Revised by Peter Hovmand in 2013 to provide more details on room arrangements.

### References

Luna-Reyes, L. F., Martinez-Moyano, I. J., Pardo, T. A., Cresswell, A. M., Andersen, D. F., & Richardson, G. P. (2006). Anatomy of a group model-building intervention: Building dynamic theory from case study research. System Dynamics Review, 22(4), 291-320.

### Notes

Successful GMB sessions require the qualities and comfort of the physical facilities and the smooth handling of logistics for the sessions. This should include removing the participants from their phones and work site, and providing a relaxing change from routine work. Multi-day sessions should be located and planned to provide high-quality lodging, meals, and opportunities for social interaction.