dataesr/scientific-paragraphs-categorization huggingface dataset:
Concluding remarks COSMOS will implement harmonised and compatible data deposition strategies and contribute to annotation workflows, providing data producers involved in metabolomics experiments with a single point of submission, while allowing other data entry points through facilitation of interoperability. The data deposition and exchange workflow Fig. 1  Initial model for the COSMOS data deposition workflow system. The data deposition cycle is initiated when a Submitter (who has generated or owns the study material) submits his/her metabolomics study to a specific associated database (1). Once the data submission has been completed, fulfilling the requirement of the associated repository submission guideline, a unique COSMOS accession number will be generated. The COSMOS engine will then properly annotate, format and store the minimum agreed metadata according to proposed reporting standards suggested by COSMOS partners  (2, 3).
COSMOS will bring together publishers and other metabolomics repositories to come to final agreement on a data workflow specifying minimum metadata exchange, associated raw data, source code and any additional information that can be shared  (4, 5). Open access to the system will ensure that any interested party can benefit from the standardized resources in the COSMOS consortium will be formally defined, agreed, and documented in relation with MetaboLights and all partnering databases in Europe and worldwide that would like to participate, and we welcome discussions from other data providers and software houses. A guideline for submitted data will be generated and COSMOS will strive to make sure that all metabolomics data submitted to partner databases are exchangeable with this standard.
Since the adoption of minimal standards for metabolomics by the relevant journals is a major goal of this coordination action, we will consult with journal publishers and ensure data annotation quality and consistency, according to the required standard level set by each journal. For example, collaboration with data journals such as GigaScience and Nature's Scientific Data will be streamlined, given these journals already use the ISA-Tab format for data submission. We are also working closely with Metabolomics, which is the official journal of the Metabolomics Society. The COSMOS consortium ultimately develops the standards and infrastructure for-and with-the metabolomics and fluxomics community. For the most efficient interaction we have already, and will continue, to organise stakeholder meetings as satellite events to major metabolomics meetings, individual staff exchange between partners, as well as larger workshops.
Acknowledgments The authors would like to acknowledge the contribution of  Michael Wilson  and  David Wishart  in NMR standardisation work carried out within COSMOS. COSMOS advisory board;  Drs. David Wishart ,  Oliver Fiehn ,  Masanori Arita ,  Yulan Wang ,  Richard Beger ,  Rima Kaddurah-Daouk  and  Kurt Zatloukal ,  Finally European Commission framework seven for funding COS-MOS  grant  EC312941. Compliance with ethical requirements This article does not contain any studies with human or animal subjects.
TinyOS The first widely used system in this domain was TinyOS  (Levis et al. , 2005). It is an open-source OS, whose first stable release (1. 0) was published in september 2002. It is very lightweight, and as such well adapted to limited devices like WSN motes. It has brought many advances in this domain, like the ability to use Internet Protocol (IP) and routing (RPL) on 802. 15. 4 networks, including the latest IPv6 version, and to simulate networks of TinyOS motes via TOSSIM  (Levis et al. , 2003). Its main drawback is that one needs to learn a specific language-named nesC-to be able to efficiently work within it. This language is quite different from standard C and other common imperative programming languages, and as such can be difficult to master. The presence of that specific language is no coincidence: TinyOS is built on its own specific paradigms: it has an unique stack, from which the different components of the OS are called as statically linked callbacks.
Contiki The current reference OS in the domain of WSN and IoT is Contiki  (Dunkels et al. , 2004 ). It's also an open-source OS, which was first released in 2002. It is also at the origin of many assets: we can mention, among others, the uIP Embedded TCP/IP Stack  (Dunkels, 2003) , that has been extended to uIPv6, the low-power Rime network stack  (Dunkels, 2007) , or the Cooja advanced network simulator  ( Österlind et al. , 2006). While a bit more resource-demanding than TinyOS, Contiki is also very lightweight and well adapted to motes. Its greatest advantage over TinyOS is that it is based on standard, wellknown OS paradigms, and coded in standard C language, which makes it relatively easy to learn and program. It offers an event-based kernel, implemented using cooperative multithreading, and a complete network stack.
All of these features and advantages have made Contiki widespread, making it the reference OS when it comes to WSN. Contiki developers also have made advances in the MAC/RDC domain: many of them have been implemented as part of the Contiki network stack, and a specifically developed, Con-tikiMAC, has been published in 2011  (Dunkels, 2011)  and implemented into Contiki as the default RDC protocol (designed to be used with standard CSMA/CA as MAC layer). However, Contiki's extremely compact footprint and high optimization comes at the cost of some limitations that prevented us from using it as our software platform. Contiki OS is indeed not a real-time OS: the processing of "events"-using Contiki's terminology-is made by using the kernel's scheduler, which is based on cooperative multitasking.
This scheduler only triggers at a specific, pre-determined rate; on the platforms we're interested in, this rate is fixed to 128 Hz: this corresponds to a time skew of up to 8 milliseconds (8000 microseconds) to process an event, interruption management being one of the possible events. Such a large granularity is clearly a huge problem when implementing high-performance MAC/RDC protocols, knowing that the transmission of a full-length 802. 15. 4 packet takes bout 4 milliseconds (4000 microseconds), a time granularity of 320 microseconds is needed, corresponding to one backoff period (BP). To address this problem, Contiki provides a real-time feature, rtimer, which allows to bypass the kernel scheduler and use a hardware timer to trigger execution of user-defined functions. However, it has very severe limitations: • only one instance of rtimer is available, thus only one real-time event can be scheduled or executed at any time; this limitation forbids development of advanced realtime software-like high-performance MAC / RDC protocols-or at least makes it very hard; • moreover, it is unsafe to execute from rtimer, even indirectly, most of the Contiki basic functions (i.
This greatly hinders portability, since LiteOS is clearly strongly tied to the AVR microcontroller architecture. MansOS  (Strazdins et al. , 2010)  This system is very recent and offers many interesting features, like optional preemptive multitasking, a network stack, runtime reprogramming, and a scripting language. It is available on two MCU architectures: AVR and MSP430 (but not ARM). However, none of the real-time features we wanted seems to be available: e. g. only software timers with a 1 millisecond resolution are available. In any case, none of the alternative OSes cited hereabove offer the real-time features we were looking for. On the other hand, "bare-metal" programming is also unacceptable for us: it would mean sacrificing portability and multitasking; and we would also need to redevelop many tools and APIs to make application programming even remotely practical enough for third-party developers who would want to use our protocols.
We also envisioned to use an established real-time OS (RTOS) as a base for our works. The current reference when it comes to open-source RTOS is FreeRTOS (http://www. freertos. org/). It is a robust, mature and widely used OS. Its codebase consists in clean and well-documented standard C language. However, it offers only core features, and doesn't provide any network subsystem at all. Redeveloping a whole network stack from scratch would have been too time-consuming. (Network extensions exist for FreeRTOS, but they are either immature, or very limited, or proprietary and commercial software; and most of them are tied to a peculiar piece of hardware, thus ruining the portability advantage offered by the OS. ).
e. : like those introduced by the protothreads mechanism); • a clean and modular design, that makes development with and into the system itself easier and more productive. The first three features listed hereabove make RIOT a full-fledged real-time operating system. We also believe that the tickless kernel and the optimal use of hardware timers should make RIOT OS a very suited software platform to optimize energy consumption on battery-powered, MCU-based devices. A drawback of RIOT, compared to TinyOS or Contiki, is its higher memory footprint: the full network stack (from PHY driver up to RPL routing with 6LoWPAN and MAC / RDC layers) cannot be compiled for Sky/TelosB because of overflowing memory space. Right now, constrained devices like MSP430-based motes are limited to the role of what the 802.
OUR CONTRIBUTIONS For our work, we use-as our main hardware platform-IoT motes built around MSP430 microcontrollers. MSP430 is a microcontroller (MCU) architecture from Texas Instruments, offering very lowpower consumption, cheap price, and good performance thanks to a custom 16-bit RISC de-sign. This architecture is very common in IoT motes. It is also very well supported, especially by the Cooja simulator  ( Österlind et al. , 2006) , which makes simulations of network scenariosespecially with many devices-much easier to design and test. RIOT OS has historically been developed first on legacy ARM devices (ARM7TDMI-based MCUs), then ported on more recent microcontrollers (ARM Cortex-M) and other architectures (MSP430 then AVR). However, the MSP430 port was, before we improved it, still not as "polished" as ARM code and thus prone to crash.
running on MSP430-based devices also allows RIOT OS applications to be simulated with the Cooja simulator; this greatly improves speed and ease of development. 6. thanks to these achievements, we now have a robust and full-featured software platform offering all the features needed to develop highperformance MAC/RDC protocols-such as all of the time-slotted protocols. As a proof of concept of this last statement, we have implemented one of our own designs, and obtained very promising results, shown in the next section.
This paper considers the problem of refreshing a dataset. More precisely, given a collection of nodes gathered at some time (Web pages, users from an online social network) along with some structure (hyperlinks, social relationships), we want to identify a significant fraction of the nodes that still exist at present time. The liveness of an old node can be tested through an online query at present time. We call LiveRank a ranking of the old pages so that active nodes are more likely to appear first. The quality of a LiveRank is measured by the number of queries necessary to identify a given fraction of the active nodes when using the LiveRank order. We study different scenarios from a static setting where the Liv-eRank is computed before any query is made, to dynamic settings where the LiveRank can be updated as queries are processed.
Introduction One of the main challenges for large networks data mining is to deal with the high dynamics of huge datasets: not only are these datasets difficult to gather, but they tend to become obsolete very quickly. In this paper, we are interested in the evolution at large time scale of any large corpus available online. Our primary focus will be the Web, but our approach encompasses any online data with similar linkage enabling crawling, like P2P networks or online social networks. We thus focus on batch crawling, where starting from a completely out-dated snapshot of a large graph like the Web, we want to identify a significant fraction of the nodes that are still alive now. The interest is twofold. First, many old snapshot of large graphs are available today. Reconstructing roughly what remains from such archives could result to interesting studies of the long term evolution of these graphs.
While recrawling policies have been extensively studied for Web graph, other sources of online data such as social networks are less covered. Yet, it is possible to similarly crawl such networks. For example, one can explore the Twitter network by fetching information about user accounts that are linked by the follower-followee relations. However, crawling is much more restricted as all the data is possessed by a single company. This makes our approach even more relevant in such contexts where gathering a large amount can be extensively long. Interestingly, Kwak et al. [20]  show, among various observations, a correlation between number of followers and PageRank. On the other hand the activity of a user measured in number of tweets seems to be more correlated to his number of followees that his number of followers.
The cost function allows to capture this dilemma. • Keeping a low cost becomes hard as α gets close to 1: without some clairvoyant knowledge, capturing almost all active nodes is almost as difficult as capturing all actives nodes. For that reason, one expects that when α gets close to 1, the set of nodes any real LiveRank will need to crawl will tend to V , leading to an asymptotical cost n na. This will be verified in Section 4. • Lastly, one may have noticed that the cost function uses n a = |a(V )|, for which an exact value requires a full knowledge of active nodes. This is not an issue here as we will perform our evaluation on datasets where a is known. For use on datasets without ground truth, one could either use an estimation of n a based on a sampling or use a non-normalized cost function (for instance the fraction of active nodes obtained after i retrievals).
uk-2002 dataset The main dataset we use is the web graph uk-2002 2  from UbiCrawler  [5]. This 2002 snapshot contains 18,520,486 pages and 298,113,762 hyperlinks. The preliminary task is to determine a, which is for Web graphs the liveness of the pages of the snapshot. For each URL, we have performed a GET request and hopefully obtained a corresponding HTTP code. Our main findings are: • One third of the total pages are no longer available today, the server returns error 404. • One fourth have a DNS problem (which probably means the website is also dead). • For one fifth of the cases, the server sends back the redirection message 301. Most redirections for pages of an old site lead to the root of a new site. If we look at the proportion of distinct pages alive at the end of redirections, it is as low as 0.
1%. • Less than 13% of pages return the code 200 (success). However, we found out that half of them actually display some text mentioning that the page was not found. To handle this issue, we have fully crawled all the pages of the dataset with code 200 and filtered out pages whose title or content have either Page Not Found or Error 404. The results are summarized in Table  1. In the end, our methodology led to finding out 1,164,998 alive pages, accounting for 6. 4% of the dataset.
Twitter Dataset Lastly, we used the dataset twitter-2010 first introduced in [20] 4. The graph contains roughly 42 millions Twitter user accounts and 1. 5 billions followerfollowee relationships among them. Arcs in the graph are directed from followers to followees: there is an arc from node x to y if user x follows y. This orientation convention is in line with a PageRank approach: a user is important when she is followed by important users. Notice that information (tweets) traverses arcs in the opposite direction, from followees to followers. We consider that a user is active if she has posted a tweet recently. For that purpose, we can query the Twitter interface to recover the timestamp of the last tweet of the user associated with a given identifier. Recovering the timestamps of all 41 millions users using Twitter API  [1]  would be extremely slow: when we made our measurements (05/2014), an authorized Twitter account was limited to 350 API requests/hour so querying all the accounts would have taken 13 years.
Correlations The rationale behind the LiveRanks I and P is the assumption that the activity of nodes is correlated to the graph structure of the snapshot, so that a node with high in-degree or PageRank has more chances to stay active. To validate this, we plot in Figure  2  the cumulative distribution of in-degree (figure  2a ) and PageRank (figure  2b ) for alive, dead, and all pages of the uk-2002 dataset. We observe that the curve for active nodes is slightly shifted to the right compared to the other curves in each figures: active users tend to have slightly higher in-degree and PageRank than in the overall population. The bias is bigger for PageRank, suggesting that LiveRank (P) should perform better than  Figure  3  presents the same results for the twitter-2010 dataset. While the curves are qualitatively similar, the bias comparison is not as clearly in favor of PageRank.
LiveRanks evaluation After having proposed several LiveRanks in Section 2 and described our datasets in previous Section, we can now benchmark our proposals. All our evaluations are based on representations of the cost functions. In each plot, the x-axis indicates the fraction α of active nodes we aim to discover and the y-axis corresponds to the relative cost of the crawl required to achieve that goal. A low curve indicates an efficient LiveRank. Like said in Section ??: an ideal LiveRank would achieve a constant cost of 1; a random LiveRank is quickly constant with an average cost n/n a ; any non-clairvoyant LiveRank will tend to cost n/n a as α goes to 1.
The cost for gathering half of the alive pages is less than 4, and for 90% it stays under 10. but similar results were obtained for P a. Figure  5a  shows the impact of the size z of the sampling set (sampling the top PageRank pages). We observe some trade-off: as the sampling set grows larger, the initial cost increases as the sample does not use any fresh information, but it results in a significant increment of efficiency in the long run. For this dataset, taking a big training set (z=500 000) allows reducing the cost of the crawl for α ≥ 0. 4, and maintains a cost less than 4 for up to 90%. Another key aspect of the sampling phase is the qualitative choice of the sample set. Using z=100 000, we can observe in Figure  5b  that the performance of double adaptive P +/a is further improved by using a random sample set rather than selecting it according to the PageRank or by decreasing indegree.
uk-2006 dataset We have repeated the same experiments on the dataset uk-2006, where the update interval is only one year. Figure  7  shows the results for static and sample-based LiveRanks, using z=200 000 (because the dataset is larger) and random sampling. The observation are qualitatively quite similar to uk-2002. The main difference is that all costs are lower due to a higher proportion of alive pages ( n na ≈ 2. 81). The double-adaptive version still gives the lower relative cost among static and sample-based LiveRanks, staying under 1. 4 for a wide range of α.
Another advantage of our technique is the possibility to be applied to more general types of structured networks, like Twitter. However, it seems that the choice of an appropriate LiveRank is closely related to the type of network. Interestingly, we could not get significant gain when using fully dynamic Liv-eRanks. As noticed before, each of the two phases of the sample-based approach can be easily parallelized through multiple crawlers whereas this would be much more difficult with a fully dynamic approach. The sample-based method could for example be implemented with in two rounds of a simple map-reduce program whereas the dynamic approach requires continuous exchanges of messages between the crawlers. Our work establishes the possibility of efficiently recovering a significant portion of the active nodes of an old snapshot and advocates for the use of an adaptive sample-based PageRank for obtaining an efficient LiveRank.
Introduction Essentially, software validation aims at ensuring that the developed software complies with the original requirements. One of the most popular validation approaches is software testing, a process that involves producing a test suite and then executing the system with these test cases. The main drawback of this approach is that designing a test suite with a high code coverage -i. e. , covering as many execution paths as possible-is a complex and time-consuming task. As an alternative, one can use a tool for the random generation of test cases, but then we are often faced with a poor code coverage. Some hybrid approaches exist where random generation is driven by the user, as in QuickCheck  (Claessen and Hughes 2000) , but then again the process may become complex and time-consuming.
Recently, a new variant called concolic execution  (Godefroid et al. 2005; Sen et al. 2005 ) that combines both concrete and symbolic execution has been proposed as a basis for both model checking and test case generation. The main advantage is that, now, when the constraints in the symbolic execution become too complex, one can still take some values from the concrete execution to simplify them. This is sound and often allows one to explore a larger execution space. Some successful tools that are based on concolic execution are, e. g. , SAGE  (Godefroid et al. 2012)  and Java Pathfinder  (Pasareanu and Rungta 2010). In the context of the logic programming paradigm, one can find a flurry of static, complete techniques for software analysis and verification. However, only a few dynamic techniques for program validation have been proposed.
Dynamic, typically incomplete, techniques have proven very useful for software validation in other paradigms. In general, these techniques are sound so that they avoid false positives. This contrasts with typical static verification methods which may produce some false positives due to the abstraction techniques introduced to ensure completeness. Therefore, we expect concolic execution to complement existing analysis and verification techniques for logic programs. In this paper, we introduce a new, fully automatic scheme for concolic testing in logic programming. As in other paradigms, concolic testing may help the programmer to systematically find program bugs and generate test cases with a good code coverage. As it is common, our approach is always sound but usually incomplete. In the context of logic programming, we consider that "full path coverage" involves calling each predicate in all possible ways.
, H n , but does not match the heads of some other clauses, say H ′ 1 ,. , H ′ m. We provide a constructive algorithm for solving such unifiability problems. A prototype implementation of the concolic testing scheme for pure Prolog, called contest, is publicly available from http://kaz. dsic. upv. es/contest. html. The results from an experimental evaluation point out the usefulness of the approach. Besides logic programming and Prolog, our technique might also be useful for other programming languages since there exist several transformational approaches that "compile in" programs to Prolog, like, e. g. ,  (Gómez-Zamalloa et al. 2010). Omitted proofs as well as some extensions can be found in the online appendix.