Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
734
datasets available to search
ShareScore release 0.9.0
Dataset results
734 results for “IP”
Study of Efficacy of WELT-IP in Insomnia (WCTP-I-B-02)
ClinicalTrials.gov study NCT05809544. IPD Sharing: NO. Countries: 1. Publications: 1.
Study Comparing Two Ventilation Modes NAVA (Neurally Adjusted Ventilatory Assist) Mode and Spontaneous Breathing With Inspiratory Pressure Support (IPS) Mode in Consecutive Patients Hospitalized for A
ClinicalTrials.gov study NCT02018666. IPD Sharing: Not stated. Countries: 1. Publications: 1.
A Study to Evaluate Efficacy of IP on Alertness and Mental Fatigue
ClinicalTrials.gov study NCT02816827. IPD Sharing: NO. Countries: 1. Publications: 1.
Tolerance of Intraperitoneal (IP) Nivolumab After Extensive Debulking Surgery and Hyperthermic Intraperitoneal Chemotherapy (HIPEC) in Patients With Advanced Ovarian Carcinoma
ClinicalTrials.gov study NCT03959761. IPD Sharing: Not stated. Countries: 1. Publications: 1.
Study of Efficacy of WELT-IP in Insomnia (WCTP-I-B-01)
ClinicalTrials.gov study NCT05822999. IPD Sharing: NO. Countries: 1. Publications: 1.
Effect Of Intrapartum Oropharyngeal (IP-OP) Suction on Meconium Aspiration Syndrome
ClinicalTrials.gov study NCT01328483. IPD Sharing: Not stated. Countries: 1. Publications: 1.
Study of Safety & Biological Activity of IP IMNN-001 (also Known As GEN-1) with Neoadjuvant Chemo in Ovarian Cancer
ClinicalTrials.gov study NCT02480374. IPD Sharing: NO. Countries: 1. Publications: 2.
Data from: How differential management strategies affect Ips typographus L. dispersal
Open the record for dataset details and reuse information.
Data from: RNA-Seq reveals adaptive genetic potential of the rare Torrey pine (Pinus torreyana) in the face of Ips bark beetle outbreaks
Open the record for dataset details and reuse information.
Behaviour of European spruce bark beetle - Ips typographus (L.) on poisoned traps
Open the record for dataset details and reuse information.
MERLIN H2020 Project: Building the right IP for your business (podcast)
<p>Interview with Mrs. Esther Ford and Mr. Simon Portman of Marks & Clerk about IP management and protection. July 2019.</p>
Preprocessed UC Berkeley Home IP Web Traces
<p>This is a acommulated version of the <a href="https://doi.org/10.5281/zenodo.3749536">UC Berkeley Home IP Web Traces</a>. Unlike the original dataset this records are stored in plain text format. The source dataset was provided by Steven D. Gribble and the conversion was done by Florian Wörister.</p> <p> </p> <p><strong>Acknowledgements</strong></p> <p>Steven D. Gribble contributed the traces to the ITA. He also maintains the official UC Berkeley page dedicated to this tracing effort.</p> <p>For inquiries, contact Steve Gribble at <em>gribble [at] gmail [dot] com</em>.</p> <p><em>These traces, documentation, and associated trace tools were created by Steve Gribble with the assistance of Armando Fox, Ian Goldberg, Eric Brewer, and Cliff Frost.</em></p>
UC Berkeley Home IP Web Traces
<p><strong>Description</strong></p> <p>This dataset consists of 18 days' worth of HTTP traces gathered from the Home IP service offered by UC Berkeley to its students, faculty, and staff Home IP provides dial-up PPP/SLIP IP connectivity using 2.4 kb/s, 9.6 kb/s, 14.4 kb/s, or 28.8 kb/s wireline modems, or Metricom Ricochet (approximately 20-30 kb/s) wireless modems. These client traces were unobtrusively gathered through the use of a packet sniffing machine placed at the head-end of the Home IP modem bank; the tracing program used was a custom module written on top of the Internet Protocol Scanning Engine (IPSE) created by Ian Goldberg. Only traffic destined for port 80 was traced; all non-HTTP protocols and HTTP connections for other ports were excluded from these traces.</p> <p>The traces contain the following information:</p> <ul> <li>a total of <strong>9,244,728</strong> references spanning the period from <strong>Friday, November 1st, 1996 at 15:18:59 PST</strong> through <strong>Tuesday, November 19th, 1996 at 05:52:03 PST</strong>. 8,377 unique clients were seen in the traces.</li> <li>the time at which the client made the request</li> <li>the time at which the first byte of the server response was seen</li> <li>the time at which the last byte of the server response was seen</li> <li>the client IP address (suitably anonymized)</li> <li>the client port</li> <li>the server IP address (suitably anonymized)</li> <li>the server port (always 80 for these traces)</li> <li>the presence of the <code>no-cache</code>, <code>keep-alive</code>, <code>cache-control</code>, <code>if-modified-since</code>, and <code>unless</code> client headers.</li> <li>the presence of the <code>no-cache</code>, <code>cache-control</code>, <code>expires</code>, and <code>last-modified</code> server headers.</li> <li>the values of the client <code>if-modified-since</code>, the server <code>expires</code>, and the server <code>last-modified</code> headers, if present.</li> <li>the length of the response HTTP header</li> <li>the length of the response data</li> <li>the request URL (suitably anonymized)</li> </ul> <p><strong>Format</strong></p> <p>For the sake of storage efficiency, the (gzipped) traces are stored in a binary representation. This archive of tools includes the following code to parse and manipulate the archives:</p> <ul> <li><strong>showtrace</strong>: this program will print out a human readable ASCII representation of what is in the traces. To use, type: <p><code>gzcat <tracefile> | showtrace </code></p> Take a look at the source file <code>showtrace.c</code> to see how you can use <code>logparse.[ch]</code> to write code that parses and manipulates the traces. All times displayed are as reported by the <code>gettimeofday()</code> system call. <p> </p> </li> <li><strong>anon_clients</strong>: this is the program that we used to anonymize the traces. I include this program under the principle that the anonymization used is strong enough that distributing the anonymization code cannot help anybody break the anonymization. <p> </p> </li> <li><strong>timeconvert</strong>: a program that accepts a calendar time (i.e. time in seconds since the Epoch, as reported by showtrace and as used in the trace filenames) and outputs the local time corresponding to that calendar time.</li> </ul> <p>The <strong>showtrace</strong> tool will display lines in the following format:</p> <pre>848278028:829593 848278028:893670 848278028:895350 23.240.8.98:1462 207.36.205.194:80 2 8 4294967295 4294967295 835418853 170 844 37 GET 9168504434183313441..gif HTTP/1.0 </pre> <ul> <li>848278028:829593 is the time at which the client made the request</li> <li>848278028:893670 is the time at which the first byte of the server response was seen</li> <li>848278028:895350 is the time at which the last byte of the server response was seen</li> <li>23.240.8.98:1462 is the anonymized client IP address and the client port number</li> <li>207.36.205.194:80 is the anonymized server IP address and the server port number</li> <li>2 is the decimal representation of the client headers bitfield</li> <li>8 is the decimal representation of the server headers bitfield</li> <li>the first 4294967295 is the if-modified-since client header value (note that 4294967295 is 0xFFFFFFFF, which means this header value was not present for this entry)</li> <li>the second 4294967295 is the expires server header value (again not present)</li> <li>835418853 is the last-modified server header value</li> <li>170 is the length of the HTTP response header</li> <li>844 is the length of the response data</li> <li>37 is the length of the anonymized request URL</li> <li>"GET 9168504434183313441..gif HTTP/1.0" is the anonymized request URL.</li> </ul> <p>The interpretation of the client and server header bitfields are as defined in the <strong>logparse.h</strong> header in the tools code.</p> <p>The tools code has been tested on both Linux and Solaris. The provided Makefile assumes Solaris - you may have to play with the LIBS definition for other platforms. HPUX is a mess; I didn't even try, but it should be possible to get these tools to work with little effort. If you do, please let me know what you did so that I can make your changes available to the world.</p> <p> </p> <p><strong>Measurement</strong></p> <p>The Home IP population gains IP connectivity using PPP or SLIP across their 2.4 kb/s, 9.6 kb/s, 14.4kb/s or 28.8kb/s wireline modem, or their (approximately) 20-30kb/s wireless Metricom Ricochet modem. There are a total of roughly 600 modems available via the Home IP bank. All traffic from these modems ends up feeding over a single 10Mb/s shared Ethernet segment, on which we placed a network monitoring computer (a Pentium Pro 200Mhz running Linux 2.0.27). The monitor was running the IPSE user-level packet scanning engine and a custom-written HTTP module that reconstructed HTTP connections from the gathered IP packets <em>on-the-fly</em> and emitted an unanonymized trace file. Each trace file was then anonymized and transmitted to our research workstations for further postprocessing and analysis.</p> <p>The trace gathering engine was brought down and restarted approximately every 4 hours (for administrative and address-space-growth reasons). This implies that there are two weaknesses in these traces that you should be aware of:</p> <ol> <li>any connection active when the engine was brought down will have a possibly incorrect timestamp for the last byte seen from the server, and a possibly incorrect reported size. We estimate that no more than 150 such entries (out of roughly 90000-100000) are misreported for each 4 hour period. <p> </p> </li> <li>any connection that was forged in the very small time window (about 300 milliseconds) between when the engine was shut down and restarted will not appear in the logs. We estimate that no more than 30 such drops occur for each 4 hour period.</li> </ol> <p>The packet capture tool reported no packet drops. Considering that a Pentium Pro 200MHz was used to capture the traces on a 10 Mb/s Ethernet segment, it is virtually certain that no trace drops besides those mentioned above occurred. There may be periods of uncharacteristically low activity in the traces - these correspond to network outages from Berkeley's ISP, rather than trace failures.</p> <p>The traces do contain entries for requests issued by the client but that weren't completed (because, for instance, the user pressed the STOP button and the TCP connection was shut down before the request completed). Unknown timestamps in the traces contain the value 0xFFFFFFFF (reported by showtrace as 4294967295), and incomplete requests contain header and data length values that report as much header/data was seen.</p> <p>The trace data is sorted by completion time (i.e. the time at which the last bye of the server response was seen, or the time at which the connection was dropped). However, because of inaccuracies and apparent time travel in the Linux system clock, some trace entries appear slightly out of order.</p> <p>All timestamps within the traces are as reported by the gettimeofday() system call, so these timestamps ostensibly have microsecond resolution.<br> </p> <p><strong>Privacy</strong></p> <p>To maintain the privacy of each individual Home IP user, we have stripped identity information out of the traces through a post-processing phase. Because it is very trivial to identify a user based solely on the pages that the user has visited, we were forced to anonymize the URL and destination IP address of each web request as well as the source IP address. All anonymization was done using a keyed MD5 hash of the data (32 bits for client and server IP addresses, 64 bits for URLs). <strong>We ourselves do not know the key used to salt the MD5 hash</strong>, so don't bother asking us for it. Similarly, don't bother asking us for unanonymized traces.</p> <p>In order to preserve <em>some</em> information about the URLs, the post-processed URLs have the following format:</p> <p> </p> <p><strong><code>COMMAND URLHASH.[flags][.suffix] [HTTPVERS]</code></strong></p> <p>where:</p> <ul> <li><strong><code>COMMAND</code></strong> is one of <code>GET</code>, <code>HEAD</code>, <code>POST</code>, or <code>PUT</code>, <p> </p> </li> <li><strong><code>URLHASH</code></strong> is the string representation of the 64-bit MD5 hash of the URL, <p> </p> </li> <li><strong><code>flags</code></strong> contains the character <strong>q</strong> to indicate that a question mark was seen in the URL, and the character <strong>c</strong> to indicate that the string <strong>CGI</strong> or <strong>cgi</strong> was seen in the URL, <p> </p> </li> <li><strong><code>suffix</code></strong> is the filename suffix, if present, and <p> </p> </li> <li><strong><code>HTTPVERS</code></strong> is the HTTP version field of the HTTP command issued by the client, and is one of <ul> <li>HTTP/1.0</li> <li>HTTP/1.1</li> <li>the NULL string (indicating HTTP/0.9).</li> </ul> To our knowledge, however, no HTTP 1.1 requests were observed during the tracing period.</li> </ul> <p>Here are some examples of URLs contained in the traces:</p> <ul> <li><strong><code>GET 8252631242092696791.q.map HTTP/1.0</code></strong> - the client issued a GET request, the URL contained a question mark, the URL ended in the suffix .map, and HTTP/1.0 was used by the client. An example of a request that may generate this anonymized URL is <code>GET /foo.map?BAR=BAZ HTTP/1.0</code>. <p> </p> </li> <li><strong><code>POST 36782605103285618862.c HTTP/1.0</code></strong> - the client issued a POST, the URL contained the substring CGI or cgi, the URL did not end with a dotted suffix, and HTTP/1.0 was used by the client. An example of a request that may generate this anonymized URL is <code>POST /cgi-bin/foo HTTP/1.0</code>. <p> </p> </li> <li><strong><code>GET 103551731373256697..gif HTTP/1.0</code></strong> - the client issued a GET request, the URL contained neither the substring [CGI|cgi] nor a question mark, the filename ended with the .gif suffix, and HTTP/1.0 was used. An example of a request that may generate this anonymized URL is <code>GET /image.gif HTTP/1.0</code>. <p> </p> </li> <li><strong><code>GET 41438582632480924518. HTTP/1.0</code></strong> - the client issued a GET request, the URL contained neither the substring [CGI|cgi] nor a question mark, the filename didn't end with a dotted suffix, and HTTP/1.0 was used. An example of a request that may generate this anonymized URL is <code>GET /foo HTTP/1.0</code>.</li> </ul> <p>Privacy was the firstmost concern during this trace gathering experiment - UC Berkeley and the CS department consider the privacy of the student body to be paramount, and whenever we had the choice of putting more information in these published logs at the cost sacrificing the privacy of the traced users, we have invariably chosen to maintain the users' privacy at the cost of losing this information. It is our hope that someday the web protocols and servers will become secure enough to make a tracing effort of the kind we have done impossible.</p> <p><strong>Acknowledgements</strong></p> <p>Steven D. Gribble contributed the traces to the ITA. He also maintains the official UC Berkeley page dedicated to this tracing effort.</p> <p>For inquiries, contact Steve Gribble at <em>gribble [at] gmail [dot] com</em>.</p> <p><em>These traces, documentation, and associated trace tools were created by Steve Gribble with the assistance of Armando Fox, Ian Goldberg, Eric Brewer, and Cliff Frost.</em></p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p>
Data from: Exploring data interaction and nucleotide alignment in a multiple gene analysis of Ips (Coleoptera: Scolytinae)
The possibility of gene tree incongruence in a species-level phylogenetic analysis of the genus Ips (Coleoptera: Scolytidae) was investigated based on mitochondrial 16S rRNA and nuclear Elongation factor-1α sequences, and existing Cytochrome Oxidase I and non-molecular data sets. Separate cladistic analyses of the data partitions resulted in partially discordant most-parsimonious trees but revealed only low conflict of the phylogenetic signal. Interactions among data partitions, which differed in the level of sequence divergence (COI > 16S > EF-1α), base composition, and homoplasy, revealed that much of the branch support only emerges in the simultaneous analysis, in particular for deeper nodes in the tree which are almost entirely supported due to "hidden support" (sensu Gatesy et al., 1999). Apparent incongruence between data partitions is in part due to suboptimal alignments and bias of character transformations, but there is little evidence to invoke incongruent phylogenetic histories of genetic loci. There is also no justification for eliminating or downweighting gene partitions based on their level of homoplasy or apparent incongruence with other partitions, as the signal only emerges in the interaction of all data. In comparison to the traditional taxonomy, the pini, plastographus and perturbatus groups are polyphyletic, whereas the grandicollis group is monophyletic except for the inclusion of the (monophyletic) calligraphus group. The latidens group and some European species are distantly related and closer to other genera within Ipini. Our robust cladogram was used to revise the classification of Ips. We provide new diagnoses for Ips and four subgeneric taxa.
Assessment of poisoned trap trees, logs, and slot traps in trapping of Ips cembrae
Open the record for dataset details and reuse information.
Supplementary material 2 from: Ramirez-Ahuja ML, Davila-Barboza JA, Talamas EJ, Moore MR, Bobadilla-Utrera C, Ponce-Garcia G, Rodriguez-Sanchez IP, Flores AE (2021) First record of Telenomus fariai Costa Lima, 1927 (Hymenoptera, Scelionidae, Telenominae) as a parasitoid of Triatoma dimidiata (Latreille, 1811) (Hemiptera, Reduviidae, Triatominae) eggs in Mexico. In: Lahey Z, Talamas E (Eds) Advances in the Systematics of Platygastroidea III. Journal of Hymenoptera Research 87: 309-322. https://doi.org/10.3897/jhr.87.73546
Newick tree file
Supplementary material 1 from: Ramirez-Ahuja ML, Davila-Barboza JA, Talamas EJ, Moore MR, Bobadilla-Utrera C, Ponce-Garcia G, Rodriguez-Sanchez IP, Flores AE (2021) First record of Telenomus fariai Costa Lima, 1927 (Hymenoptera, Scelionidae, Telenominae) as a parasitoid of Triatoma dimidiata (Latreille, 1811) (Hemiptera, Reduviidae, Triatominae) eggs in Mexico. In: Lahey Z, Talamas E (Eds) Advances in the Systematics of Platygastroidea III. Journal of Hymenoptera Research 87: 309-322. https://doi.org/10.3897/jhr.87.73546
Sequences of COI barcodes from Telenomus and Baeoneurella outgroup
Figures 8-13 from: Ramirez-Ahuja ML, Davila-Barboza JA, Talamas EJ, Moore MR, Bobadilla-Utrera C, Ponce-Garcia G, Rodriguez-Sanchez IP, Flores AE (2021) First record of Telenomus fariai Costa Lima, 1927 (Hymenoptera, Scelionidae, Telenominae) as a parasitoid of Triatoma dimidiata (Latreille, 1811) (Hemiptera, Reduviidae, Triatominae) eggs in Mexico. In: Lahey Z, Talamas E (Eds) Advances in the Systematics of Platygastroidea III. Journal of Hymenoptera Research 87: 309-322. https://doi.org/10.3897/jhr.87.73546
Figures 8-13 Telenomus fariai, female (FSCA 00091199) 8 mesosoma, dorsal view 9 mesosoma, lateral view 10 mesosoma, posterolateral view 11 mesosoma, ventrolateral view 12 metasoma, dorsal view 13 T6–T7, dorsal view.
Figures 14-15 from: Ramirez-Ahuja ML, Davila-Barboza JA, Talamas EJ, Moore MR, Bobadilla-Utrera C, Ponce-Garcia G, Rodriguez-Sanchez IP, Flores AE (2021) First record of Telenomus fariai Costa Lima, 1927 (Hymenoptera, Scelionidae, Telenominae) as a parasitoid of Triatoma dimidiata (Latreille, 1811) (Hemiptera, Reduviidae, Triatominae) eggs in Mexico. In: Lahey Z, Talamas E (Eds) Advances in the Systematics of Platygastroidea III. Journal of Hymenoptera Research 87: 309-322. https://doi.org/10.3897/jhr.87.73546
Figures 14-15 Telenomus fariai14 male genitalia, ventral view 15 female (FSCA 00091164), wings, dorsal view. Annotations. al: aedeagal lob; av: aedeago-volsellar shaft; di: digitus; dt: digital teeth; lv: laminae volsellares.
Figures 4-7 from: Ramirez-Ahuja ML, Davila-Barboza JA, Talamas EJ, Moore MR, Bobadilla-Utrera C, Ponce-Garcia G, Rodriguez-Sanchez IP, Flores AE (2021) First record of Telenomus fariai Costa Lima, 1927 (Hymenoptera, Scelionidae, Telenominae) as a parasitoid of Triatoma dimidiata (Latreille, 1811) (Hemiptera, Reduviidae, Triatominae) eggs in Mexico. In: Lahey Z, Talamas E (Eds) Advances in the Systematics of Platygastroidea III. Journal of Hymenoptera Research 87: 309-322. https://doi.org/10.3897/jhr.87.73546
Figures 4-7 Telenomus fariai4 female (FSCA 00091199), head, anterolateral view 5 female (FSCA 00091199), head, dorsal view 6 female (FSCA 00091199), ventral frons, anterior view 7 female (USNMENT01795654), head and mesosoma, anterior view.
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.