Question mark

Summary

The question mark (also known as interrogation point, query, or eroteme in journalism) is a punctuation mark that indicates an interrogative clause or phrase in many languages. History In the fifth century, Syriac Bible manuscripts used question markers, according to a 2011 theory by manuscript specialist Chip Coakley: he believes the zagwa elaya ("upper pair"), a vertical double dot over a word at the start of a sentence, indicates that the sentence is a question. From around 783, in Godescalc Evangelistary, a mark described as "a lightning flash, striking from right to left" is attested. This mark is later called a punctus interrogativus. According to some paleographers, it may have indicated intonation, perhaps associated with early musical notation like neumes. Another theory, is that the "lightning flash" was originally a tilde or titlo, as in , one of many wavy or more or less slanted marks used in medieval texts for denoting things such as abbreviations, which wo

Official source

https://en.wikipedia.org/wiki/Question_mark

About this result

This page is automatically generated and may contain information that is not correct, complete, up-to-date, or relevant to your search query. The same applies to every other page on this website. Please make sure to verify the information with EPFL's official sources.

Related publications (3)

Related publications

Related people

Related units

Related concepts (10)

Related concepts

Related courses (17)

Related courses

Related lectures (32)

Related lectures

BPMN process generation and optimization for readability in the context of telemedecine

Charline Montial

In business, automated processes can be specified using the BPMN standard, which stands for Business Process Model and Notation. It is presented as flowcharts with standardized graphical elements to show the possible flows and activities of a process. These diagrams can be seen as a graph with logical expressions conditioning their edges. The telemedecine start-up Soignez-moi.ch uses BPMN to describe complex medical forms in a readable way. Soignez-moi.ch offers medical consultations via an online platform. The first step for the patient is to fill a questionnaire about his/her symptoms. In the second step, a doctor accesses to the answers and proceeds to call the patient for the teleconsultation. The complexity of these medical forms comes from the fact that the questions are adapted to the patient answers, which leads to different possible flows. Complex forms from another telemedecine website, Diaana, had to be translated to BPMN to be compatible and used at Soignez-moi.ch. Diaana is a contraction of the words diagnosis and anamnesis. The way these forms are specified is very different from what has been modeled in Soignez-moi.ch: instead of having separated branches, there is a sequential list of questions. In this list, every question is evaluated on its own to see if it is asked or not. The question conditions are Boolean expressions. If a direct translation to BPMN is performed, there is no branching to show the relationships between the questions. The aim of my work is to highlight similarities in the branch conditions to make the diagrams more readable and editable by humans. Doctors and collaborators read the medical BPMN processes and may modify them. It should be a pleasant experience for them to go through the diagrams. They should quickly understand in a visual way if questions are related, and how they are related. The BPMN process readability has been achieved by extracting patterns, showing the implications between the questions to have a readable diagram with meaningful branches. This translation has been applied to 18 questionnaires. Two questionnaires were not improved because they were only composed of one question. One questionnaire was also not improved because all its questions were unconditional, meaning that no relationship between the question conditions could be highlighted. Another questionnaire with conditional questions was not improved because its conditions were unrelated. 14/18 questionnaires have had their readability improved.

2022

Enabling the Automatic Generation of User Interfaces for Remote Laboratories

Denis Gillet, Wissam Halimi, Hagop Jamkojian, Christophe Salzmann

Remote laboratories are an important component of blended and dis- tance science and engineering education. By definition, they provide access to a physical lab in a distant location. Many architectures enabling remote laboratory systems exist, the most common of which are Client-Server based. In this con- text, the Server interfaces the physical setup and makes it software-accessible. The Smart Device Specifications revisit a Client-Server architecture, with the main aim of cancelling the dependencies which inherently exist between a Client and a Server. This is done by describing the Server as a set of services, which are exposed as well-defined APIs. If a remote laboratory is built following the Smart Device Specifications, any person with programming skills can create a personalized client application to access the lab. But in practice, teachers rely on the mediated contact with a lab provider to have information about what kind of experiment(s) the lab in question implements. Even though there is a complete description of the available sensors and actuators making up a lab and how to be accessed, it is not clear how they are connected (relationships). In this sense, a list of sensors and actuators are not enough to make a guided selection of compo- nents to create the interface to an experiment. Therefore, the aim of this work is to support teachers in choosing the experiments and creating the respective UI on their own, in a pedagogically oriented scenario and by taking into consideration the target online learning environment. This is done by revisiting the Smart Device Specifications and extending them, in addition to proposing a tool that will automatically generate the user interface of the chosen experiment(s).

Springer2017

A recent in-class exam in a software engineering course included a section in which students had to write code and/or tests under conditions they might face on real software engineering projects, including complex, multi-part coding questions in which later parts of the question build on earlier parts. To avoid "cascading penalties" on later questions that build on earlier ones, students could reveal the answer for any question during the exam for a "reveal penalty": If the student identified the correct place in the code to copy and paste the revealed answer, they would get 20% of the question points. That is, by simply revealing every answer and copy-pasting it correctly, even the weakest student should be able to achieve 20% of the points for the coding portion of the exam. In this paper, we study how students used this mechanism. Surprisingly, some students chose to take zero points for certain questions rather than revealing the answer, and some who asked for an answer to be revealed were unable to correctly incorporate it to get the question correct. We also find a correlation between student scores on the non-coding multiple-choice section of the exam, which had no hints/reveals available, and the coding section, even though students who performed poorly on the non-coding first half of the exam should have been able to score well on the coding part by using the reveal mechanism. That is, weak students did not benefit as much as would be expected from revealable answers. Pedagogical interpretation of these results informs our future use of the "buy a hint" format for coding-based exams.

ACM2019

BPMN process generation and optimization for readability in the context of telemedecine

Charline Montial

2022