dataesr/scientific-paragraphs-categorization huggingface dataset:
Semantics fo Human-Machine Dialog In the TATIN-PIC system, users wear headsets and can trigger specific actions through vocal commands given to virtual personal assistants who can understand natural language. These virtual personal assistants are coded in OMAS  (Barthès, 2011). In this environment, each assistant can have its own ontology for a semantic representation of the tasks and domain in which it is operating. Such local ontologies are derived from the general ontology of the TATIN-PIC project and is implemented using a representation language called MOSS. MOSS is a complex frame-based representation language, allowing us to describe concepts, individuals, properties, classless objects, default values, virtual concepts or properties. MOSS is centered on the concept of property and adopts a descriptive (typicality) rather than prescriptive approach, meaning that defaults are privileged.
Semantics for Exchanges among Agents OntoTATIN-PIC also helps defining the protocol by which the different software components of the platform exchange information. Though the details of the software architecture are outside the scope of this article, the components of this system (i. e. interactive tabletop, whiteboard, headset) each have numerous software processes responsible for sending and receiving information when a user performs an action. The TATIN-PIC system is composed of two multiagent platforms having different agent communication languages (ACL). Transfer agents (gateways) restructure the messages from and to the other platform. The exchange format follows the JSON grammar and syntax and use performatives derived from FIPA, e. g. inform, request, answer, cancel, or failure. The message content is also a JSON object, the properties of which correspond to concepts of the OntoTATIN-PIC ontology and are parameters of the action to perform by the agent receiving the message.
KEOD2013-InternationalConferenceonKnowledgeEngineeringandOntologyDevelopment OntoTATIN-PIC is an extension of the founding DOLCE-CORE ontology. This approach gives to the necessary rigor for defining the true nature of the different objects involved in actions. In particular, we distinguish the actions having effects only on inscriptions and the actions which can also have effects on the expressions of these inscriptions or on the entities they reference. Today we have an informal specification of our ontology in the language of the OntoSpec methodology and a partial implementation in the MOSS language. Two research opportunities emerge: on a conceptual level, it seems interesting to identify between DOLCE and the applicative concepts of OntoTATIN-PIC, an intermediate (and reusable) layer corresponding to an ontology of virtual reality; on an operational level, the issue of creating a detailed model of performed actions (by populating the identified classes with instances) is raised: it would help provide software agents with a better understanding of the work done.
The situation could become even worse when the number of services involved in the composition is large and the involved services are highly dynamic. For example, the recent SOA implementation of a Texas health and human resource system consists of over a hundred Web services and more than 20 composite services. 8 According to a recent Application Integration Survey, data integration accounts for about 40% of software development costs. 9 Another survey conducted in 2002 reveals that approximately 70% of the integration costs were spent on identifying interpretation differences and developing custom code to reconcile these differences  (Seligman et al. 2002). Therefore, it is important to develop a systematic and disciplined approach to addressing the various data misinterpretation problems for Web services composition.
Like traditional ontologies, the lightweight ontology has two relationships: is_a and attribute. For instance, concept openingPrice is a type of stockMoneyValue. An attribute is a binary relationship between a pair of concepts. For example, attribute dateOf indicates that the date concept is the "date of" attribute of concept stockMoneyValue. In practice, it is frequently straightforward to identify generic concepts among multiple independent services. For example, S3 has an output dailyMarketCap and CS has an output openingMarketCap. Both of them correspond to a generic concept marketCapital. However, S3 provides the data instances of dailyMarketCap using currency "USD" and scale factor "1000", while CS interprets and furnishes the data instances of openingMarketCap using currency "GBP" and scale factor "1".
Algorithm 1 is developed to identify explicit and implicit data transfers. Using Algorithm 1, three implicit and two explicit data transfers are identified in the composition process of Example 3, as shown in Table  4. Instead of explicitly using the <assign> activity, the output of S1 is directly transferred and consumed as the input of S3 through variable tickerQuoteDate. An implicit data transfer is thus identified, where the source and target interaction activities are the invocation of S1, S3, respectively. In Figure  3 , the composition process involves <receive>, <reply> and <invoke>; it does not involve <onMessage>.
As shown in Table  5 , data transfer dt3 is an implicit data transfer where a context conflict of date format occurs. To make dt3 explicit, a new variable tickerQuoteDate_t is declared using the same element type as variable tickerQuoteDate. Since tickerQuoteDate has two data elements dateofQuote and tickerSymbol, the <assign> activity inserted into dt3 has two <copy> activities for copying dateofQuote and tickerSymbol of tickerQuoteDate to that of tickerQuoteDate_t. Then, the input variable of the invocation of S3 is changed from variable tickerQuoteDate to variable tickerQuoteDate_t. After this step, all data transfers with context conflicts are made explicit. When a context conflict involves only one modifier, it can be reconciled using a predefined atomic conversion. For example, the context conflict cc1, as shown in Table  5 , involves modifier dateFormat of concept date.
PROTOTYPE IMPLEMENTATION We implemented a proof-of-concept prototype, named Context Mediation Tool (CMT), as a JAVA application, to demonstrate the reconciliation approach. The lightweight ontology with structured contexts is defined using the COIN Model Application Editor 14 which is a Web-based tool for creating and editing COIN-style ontology and contexts in RDF/OWL. Atomic conversions between the contexts are defined in a specification file. The WSDL descriptions of the composite and component services (e. g. , CS and S1 ~ S3 of Example 3) are annotated using our context annotation method. To facilitate the annotation task, we extended an open-source Eclipse plugin for semantic annotation (i. e. , Radiant 15 ) and developed the context annotation tool Radiant4Context. We assume naive BPEL composition processes with possible data misinterpretation problems are defined using any typical BPEL tool.
Evaluation The reconciliation approach is evaluated both qualitatively and quantitatively. The evaluation results are presented in the following two subsections. 5. 2. 1. Qualitative Evaluation. The qualitative evaluation of the reconciliation approach is conducted by checking whether it can handle more general and complicated composition situations. Specifically, we try to answer the following two questions: (1) What types of data misinterpretation problems can the approach address? and (2) What types of Web services composition can the approach support? The method of qualitative evaluation used in this paper is similar to the method of key feature comparison, which is a credible method for evaluating software engineering-based approaches  (VIDE 2009)  and recently used by  (Abeywickrama and Ramakrishnan 2012)  as well 17.
2A ). In line with these observations, EM analysis of the muscle ultrastructure showed a clear disorganization of the triads and the presence of dilated jSR in Mtm1-null muscles (Fig. 2B ). In addition, the intermyofibrillar space was enriched with membrane structures in the Mtm1-null muscles. To further characterize the organization of the lSR, we analyzed cross-sections of muscles at the A-band level. SR profiles were less prominent in the Mtm1-null (arrows) compared to the wild-type muscles, and SR membranes were found abnormally located within myofibrils (Fig. 2B ). These data sustained that lack of MTM1 is correlated to defects of the SR. Previous studies suggested an alteration of the T-tubule organization in the absence of MTM1 in mouse and in zebrafish, while the SR was not thoroughly considered  (Al-Qusairi et al.
, 2009; Dowling et al. , 2009). To address if SR defects are secondary to T-tubules abnormalities observed in Mtm1-null muscle, we investigate the ER in mouse and human muscle cells (myoblast) as myoblast cells lacks T-tubule and triad structures. The ER network, labeled with an antibody recognizing the ER retention KDEL sequence, was uniformly distributed in control myoblasts while it showed a perinuclear collapse in Mtm1 knock-down (KD) cells (Fig. 2C ). To confirm this observation, we next performed a study of the distribution of the ER network in cells. Five random plot profile per cell were created to scan the fluorescence using ImageJ software, measured from the nucleus towards the cell periphery, as illustrated in Fig. 2C. Using this method, we compared changes in the subcellular distribution of the ER network between different cell lines.
In nature, one typically finds the primitive (P), double diamond (D), and gyroid (G) surfaces  (Almsherqi et al. , 2006). We based our theoretical modeling on an existing cubic membrane simulation software ['cubic membrane simulation projection software'  (Deng et al. , 1999; Landh, 1995) ] to create a similar program. The underlying method is based on pattern and symmetry recognition. The surface P, D and G are approximated by their corresponding nodal surfaces from which the program generates two-dimensional (2D) projection catalogs with various surface parameters, projection directions, viewing angles and section thicknesses of an EM specimen (supplementary material Fig. S7 ). In a second step, we performed EM tomography analysis of 200 nm-thick muscle sections by intermediate voltage transmission-EM at multiple tilted angles, yielding a large number of projections (Fig.
Muscle histology, isolated fibers and immunofluorescence Transverse cryosections (8 mm) of mouse TA skeletal muscles were stained with Hematoxylin and Eosin (HE), succinate dehydrogenase (SDH) and viewed with a fluorescence microscope (DM4000; Leica Microsystems, Sunnyvale, CA). Crosssectional area (CSA) was analyzed on HE sections from TA mouse skeletal muscles, using the RoiManager plugin of ImageJ image analysis software (Rasband, W. S. , ImageJ, U. S. National Institutes of Health, Bethesda, Maryland, USA, http://rsb. info. nih. gov/ij /, 1997-2009). The percentage of TA muscle fibers with centralized or internalized nuclei was counted using the cell counter plugin of ImageJ image analysis software. Transverse cryosections (8 mm) sections of mouse TA skeletal muscles were prepared, fixed, and stained with the antibodies.
Acknowledgements We acknowledge  Olivier Dorchies  for patient cells,  Kinga Tomczak  and  Alan Beggs  for Mtm1 knockdown myoblasts,  Jude Samulski  for vectors,  Christine Kretz  for mouse genotyping,  Anthony Bonfrate  for help with the theoretical modeling, and  Coralie Spiegelhalter ,  Nadia Messaddeq  and  Marc Koch  for excellent technical assistance.
RESEARCH DESIGN AND METHODSdThis study combines four coordinated protocols sharing the same DiAs artificial pancreas technology conducted at the Universities of Padova (Italy) and Montpellier (France), the University of Virginia (UVA), and the Sansum Diabetes Research Institute, Santa Barbara, California. To test whether a smart phone is capable of running outpatient closedloop control, we have configured a system comprising available components, which were linked as follows: CGM → iDex ↔ DiAs (running all closed-loop computations, user interface, and communications to peripheral devices) ↔ iDex ↔ pump. The iDex is an experimental device manufactured by Insulet (Bedford, MA), which combines a DexCom Seven Plus receiver and OmniPod insulin pump. In addition, DiAs transferred data in real time to a central location allowing remote monitoring of patient state and system functions.
Procedure All protocols were approved by the review boards of the participating institutions. In addition, the United States-based studies received Food and Drug Administration approval (IDE #G120032) and the European studies received appropriate national-level certifications. All studies were registered with ClinicalTrials. gov (NCT01578980 for UVA/Sansum, NCT01447992 for Padova, and NCT01447979 for Montpellier). After consent and screening, subjects were trained to use the Omnipod insulin pump (Insulet) and participated in a 3-to 7-day pump initiation if needed. Two DexCom Seven Plus sensors (DexCom, San Diego, CA) were inserted 24-72 h before admission; throughout the trials, the sensors were calibrated per manufacturer's instructions using commercial glucometers. A calibration was performed before dinner at ;7:00 P.
Safety A study physician, a nurse, and a technician were located in nearby rooms to provide assistance if needed. Patient data were monitored remotely via a passwordprotected Web site. Reference blood glucose readings were measured simultaneously by finger stick with a HemoCue (HemoCue AB, Ängelholm, Sweden) and a commercial glucometer beginning at 7:00 P. M. on the evening of admission and continuing every 2 h during the day. Overnight, there were no scheduled finger sticks; reference blood glucose measurements were taken only if DiAs or the secondary sensor alarm indicated hypoglycemia or hyperglycemia, or if the two sensors had readings diverging by. 20%. Nursing staff checked DiAs and secondary CGM readings hourly overnight and system alarms were monitored remotely for the DiAs and with a baby monitor to capture alarms from the secondary CGM.
Control strategy DiAs operated in two modes, open-loop (first 13 h of each study) controlling the pump per each patient's preset basal/ bolus delivery instructions and displaying CGM and insulin delivery information or closed-loop (hours 14-42 of each study) running a closed-loop control algorithm. Both modes of operation included fully automated transfer of data from the sensor to DiAs and commands from DiAs to the insulin pump. User input was required only before meals and whenever the system signaled imminent risk for hypoglycemia or hyperglycemia. The closed-loop control algorithm included two modules: 1) safety supervision responsible for prediction of hypoglycemia, attenuation, or discontinuation of insulin delivery if hypoglycemia is anticipated and warnings if hypoglycemia is imminent and cannot be prevented by insulin discontinuation alone  (19)  and 2) rangecorrection module responsible for injecting correction boluses.
Remote monitoring In addition, DiAs transmitted data in real time through either 3G (telephone network) or WiFi to two servers (UVA and Montpellier), which allowed team members to log-in for remote observation from their locations. The server connections were one-directional: DiAs transmitted data out care. diabetesjournals. org but could not be controlled from a remote location for safety reasons. The transmitted data contained glucose traces, insulin infusion by the pump, and technical information about the functioning of the control algorithm but did not contain any subject identifiers; the monitoring Web sites were password-protected.
The subjects were free to move around the facility and in its vicinity. One subject used a hotel treadmill, one subject in Italy rode a bike, one subject in France walked to nearby museums, and five subjects took a shower with the pouch hanging just outside of the shower. Subjects also were free to entertain family and friends in their individual quarters. System wearability was evaluated in relative terms, comparing DiAs to previous laptop-based systems. With the transition to a smart phone as a system hub and to wireless data transmission, the weight of a closed-loop control system was reduced several-fold. Figure  2A  presents photos of DiAs displaying CGM and insulin delivery traces and the entire system worn by a study subject. DiAs communicated wirelessly with the iDex/ communication box; these devices are placed in a pouch on the patient's belt.
AcknowledgmentsdThis study was supported by the  JDRF Artificial Project ,  Award 22-2011-649 , and by  National Institutes of Health/National Institute of Diabetes and Digestive and Kidney Diseases  grant  RO1 DK 085623. B. P. K. , P. K. -H. , and M. D. B. hold patents or patent applications related to the study technology. B. P. K. is a consultant/advisor for Animas and DexCom and received research grant and material support from  Animas, Abbott, DexCom, Insulet, LifeScan, Tandem , and  Sanofi. E. R. is a consultant/advisor for  A. Menarini Diagnostics ,  Abbott, Cellnovo, Dexcom, Eli Lilly, Johnson & Johnson (Animas, LifeScan ),  Medtronic ,  Novo Nordisk, Roche Diagnostics , and  Sanofi  and received research grant/material support from  Abbott ,  Dexcom ,  Insulet , and  Roche Diagnostics.
Peer-to-Peer (P2P) systems have been very successful for large-scale data sharing. However, sharing sensitive data, like in online social networks, without appropriate access control, can have undesirable impact on data privacy. Data can be accessed by everyone (by potentially untrusted peers) and used for everything (e. g. , for marketing or activities against the owner's preferences or ethics). Hippocratic databases (HDB) provide an effective solution to this problem, by integrating purposebased access control for privacy protection. However, the use of HDB has been restricted to centralized systems. This chapter gives an overview of current solutions for supporting data privacy in P2P systems, and develops in more details a complete solution based on HDB.
Many communities use OLSNs to share data in both professional and non-professional environments. Examples of professional OLSNs are Shanoir 4 , designed for the neuroscience community to archive, share, search, and visualize neuroimaging data, or medscape  5  , designed for the medical community to share medical experience and medical data. There are also non-professional OLSNs for average citizens and amateurs in different domains such as Carenity  6  , designed for patients and their relatives to share medical information about them in order to help medical research. Another example is DIYbio 7  , dedicated to make biology accessible for citizen scientists, amateur biologists, and biological engineers, who share research results. The most popular OLSN, Facebook, with hundreds millions of users, enables groups of friends to share all kinds of personal information among themselves.
Inspired by the Hippocratic oath and its tenet of preserving privacy, Hippocratic databases (HDB)  [2]  have incorporated purpose-based privacy protection, which allows users to specify the purpose for which their data are accessed. However, HDB have been proposed for centralized relational database systems. Applied to P2P systems, HDBs could bring strong privacy support as in the following scenario. Consider an OLSN where patients share their own medical records with doctors and scientists, and scientists share their research results with patients and doctors. Scientists have access to patient medical records if their access purpose is for research on a particular disease. Doctors have access to research results for giving medical treatment to their patients. In this context, Hippocratic P2P data sharing can be useful.
Producing new P2P services that prevent peers from disclosing, accessing, or damaging sensitive data, encourages patients (resp. scientists) to share their medical records (resp. results) according to their privacy preferences. Thus, the challenge is to propose services to store and share sensitive data in P2P systems taking into account access purposes. This chapter is organized as follows. Section 2 surveys data privacy in P2P systems and gives a comparative analysis of existing solutions. Section 3 surveys HDBs. Section 4 introduces PriMod, a privacy model that applies HDB principles to data sharing in P2P systems. Section 5 describes PriServ, a privacy service that supports PriMod in structured P2P networks. Section 6 presents the PriServ prototype. Section 7 concludes.
Thus, trust and access control techniques can be used with replication in order to ensure data privacy. In addition, data digital checksums and encryption can be used to protect ownership rights as well as data from unauthorized reads. Past  [33] , OceanStore  [22] , and Mnemosyne  [12]  are examples of systems that use such techniques. Past is a large-scale, Internet-based, global storage utility that provides scalability, high availability, persistence, and security. It relies on Pastry and uses smartcards, self certifying data, and certified-based trust in order to protect data content from malicious servers. OceanStore is a cooperative infrastructure that provides a consistent, highlyavailable, durable, and secured storage utility. It relies on Tapestry and uses symmetric cryptography and access control techniques to protect data privacy from malicious peers.
However, ensuring user privacy may cause undesired effects on data privacy. Users want to protect their data privacy while remaining anonymous to behave freely, which increases the risk of violating the data privacy of others. This loop is probably the main reason we did not find in the literature systems that guarantee both data and user privacy. Protecting data privacy. Data privacy in massive data sharing systems can be illustrated with the following systems. Office SharePoint Workspace 8  , previously known as Office Groove, is a desktop application designed for document collaboration within teams (i. e. , workspaces). It is based on a partially centralized P2P system. Each user has a private editable copy of the workspace. Workspace copies are synchronized via the network in a P2P manner.
Office SharePoint Workspace uses access control, trust, and encryption techniques in order to protect data privacy. Piazza  [38]  is a data management system that enables sharing of XML documents in a distributed and scalable way. It is based on an unstructured P2P system. Although the goal and emphasis of Piazza is data sharing and not data privacy, the creators of Piazza proposed in  [27]  new techniques for publishing a single data instance in a protected form, thus enforcing data privacy. OneSwarm  [14]  is a P2P service that provides users with explicit control over their data privacy by letting them determine how data are shared. It relies on BitTorrent and was designed to provide privacy-preserving data sharing. OneSwarm uses asymmetric cryptography, access control, trust, and communication anonymity in order to protect data privacy.
Thus, data blocks are resistant to censorship and suppression. Censorship-resistant schemes protect data only from suppression. Data privacy is not fully protected since any user can access these data. Protecting user privacy. User privacy in massive data sharing systems can be illustrated with the following systems. They mostly use anonymity techniques to guarantee anonymous publishing and sharing. Freenet  [8]  is a free P2P system that ensures anonymous file sharing, browsing, and publishing. It provides users with freedom of behavior by ensuring their anonymity. Freenet has its own key-based routing protocol (similar to that of a DHT), uses symmetric cryptography, and user and communication anonymity in order to guarantee user privacy. SwarmScreen  [7]  is a privacy preserving layer for P2P systems that disrupts community identification by obfuscating users' network behavior.