DOI Metadata Guidelines¶
Note
This page is under constructions. Contributions, comments, and improvements welcome in our Github Issues
ROOT
This is the root of the submission file document, and thus required.
Note that the content of the <resource> element is defined under an xs:all group, so that the immediate child nodes can appear in any order. The order here reflects the order in which they are listed in the schema.
REQUIRED
This is the assigned DOI identifier and must begin with the DataCite prefix “10.”
Required attribute: identifierType. This must have a value of DOI. For example:
<identifier identifierType="DOI">10.12345/abcde</identifier>
REQUIRED
This is the author list or equivalent. Creators should appear in priority order. Both individuals and institutions/organizations can be credited as creators.
If the only list we have is a list of editors, then it goes here, but also indicate in the <contributors> section that each person in the list is a contributor with the role of Editor. This is not an optimal solution, but it will do for now. |
REQUIRED, repeatable
This class contains the identifying information for one creator. It is repeated for each creator. Note that the metadata schema does not distinguish between “authors” and “editors”. If some of the creators listed are editors rather than authors, repeat their creator information in the <contributors> section and indicate a role of “Editor”.
Fill out as much of this class as possible with information that was apropos at the time of the publication. So, if you know given name, include it; if you know the institutional affiliation, include it; if you can find and confirm the correct ORCID, include it; etc. This all helps in linking the data set into the literature and the author’s network. |
REQUIRED
The string representing the name as it should appear in citations. For personal names, the format is “Family, Given” (all one string). Full first names are preferred for the metadata, in order to help identify authors unambiguously. (It is also relatively easy to turn a complete name into an initial.) For organizational names, use the full, formal name of the organization.
This tag has one optional XML attribute, nameType, which takes one of these values:
Organizational Personal
Best practice is to always include this attribute for creatorName.
OPTIONAL
For personal names, this should contain the string corresponding to the given name in the <creatorName> element. This should not be present for organizational names (but that is not enforced by the DataCite schema).
OPTIONAL
For personal names, this should contain the string corresponding to the family name (surname, patronymic, etc.). This should not be present for organizational names (but that is not enforced by the DataCite schema).
Note: For PDS purposes, at least, we should consider where to associate suffixes (Jr., Sr., III, etc.). If DataCite, ADS, or the AAS journals have a convention, we should follow that. |
OPTIONAL, repeatable
This attribute provides a formal identifier for an individual or organization - for example, an author’s ORCID, or an organizational DOI. Only public identifiers should appear here, of course. If there is more than one applicable identifier, this element may be repeated.
Required attribute: nameIdentifierScheme. The value should be the common name or acronym for the identifier given (like “ORCID”). Optional attribute: schemeURI. The value should be the URI of the defining organization or schema (“http://orcid.org”, e.g.).
Where it can be obtained directly from the creator, or where we can be certain about a creator’s ORCID, we should add it to the metadata.
OPTIONAL, repeatable
This attribute provides an organizational affiliation (as free-format text) for the creator. It may be repeated. Organizational “creators” may also have affiliations, if that makes sense.
Optional attribute: affiliationIdentifier. The value should be a formal, permanent, unique identifier for the affiliated organization, beyond the name that is the value of the <affiliation> element. For example, a Research Organization Registry (ROR) ID would be ideal here.
Optional attribute: affiliationIdentifierScheme. The (human-recognizable) name of the identifier system (e.g., “ROR” would be sufficient in the above case.
Optional attribute: schemeURI. The URI of the identifier scheme, typically a URL.
REQUIRED
This class lists names or titles for the resource being identified. At least one title must be provided. This is the title that will be used to format citations, and it is also the title that users will see returned by various search interfaces. It needs to make sense in a general, non-PDS search context, so avoid acronyms and assuming that users will know that, for example, “Deep Impact” is also the name of a spacecraft and NASA mission.
Remember the primary title has to make sense in the context of an ADS-type search. Users may not know that data sets are included in their result set. The title we put here will be used to formulate citations of the data set as well as helping users to identify data of potential interest. So avoid acronyms (no matter how obvious they seem now) unless they include the full name. For example, “DIF” is not good on its own, but “Deep Impact Flyby (DIF) Spacecraft” is very good - explicit and contains the acronym that knowledgeable users might search on as well. |
===
===
REQUIRED, repeatable
This element contains a single title. It may be repeated for alternate titles where appropriate.
Optional attribute: titleType. This must have one of the following values: :* AlternativeTitle
:* Subtitle
:* TranslatedTitle
:* Other
For PDS purposes, the formal title should always be listed first without a titleType attribute, and additional titles should probably always be either alternatives or translations and identified accordingly through the titleType attribute.
Optional attribute: xml:lang. This should contain one of the standard ISO 2- or 3-letter codes (but this is not validated). Note that this indicates only the language of the associated title string, not the language of the resource.
PDS documents are required to be in English, so we should have no use for this. Our IPDA partners, however, might. In that sort of context, it would be prudent to include the xml:lang attribute for all <title> elements, not just the one identified as the TranslatedTitle.
REQUIRED
This attribute identifies the publisher/distributor/curator of the resource. It is used in creating citations.
For PDS4 data sets that have LIDs that begin with urn:nasa:pds, this should always be NASA Planetary Data System. If we are assigning DOIs for other publishers (like ESA), we should first determine what their publisher title should be, and we should probably be using a DOI prefix that can be unique to that publishing archive. If we are assigning a DOI and also serving the data for a non-PDS publisher, then we should list our node and facility in the <contributors> section, with a role of DataCurator. (The first time this comes up we should think about this again, just in case.) |
Optional attribute: xml:lang. This attribute is used to indicate the language (using the standard ISO codes) of the publisher name. Unless otherwise specified, this is assumed to be in English.
REQUIRED
The year the resource was made available to the public. This is used in creating citations.
For PDS data sets, this must be the four-digit year in which the data were publicly posted in the format and version associated with this DOI. This may or may not be the same year as listed in the CITATION_DESC field for legacy data sets. When in doubt, assume the DATA_SET_RELEASE_DATE is correct unless you have documentation that proves it is not - and then use the date in that documentation and note the discrepancy and resolution in an additional <description> field (following) with a descriptionType of Other. This date must agree with the Available date (see below) provided for ADS processing. There are other date fields in which significant dates can be indicated if needed or desired. |
REQUIRED
This element takes a free-format text description of the type of resource associated with the DOI.
Required attribute: resourceTypeGeneral. This must have one of the following values:
{| cellpadding=”10”
|- | valign=”top” |
Audiovisual
[New in Schema 4.4] Book
[New in Schema 4.4] BookChapter
Collection
[New in Schema 4.4] ComputationalNotebook
[New in Schema 4.4] ConferencePaper
[New in Schema 4.4] ConferenceProceeding
| valign=”top” |
DataPaper
Dataset
[New in Schema 4.4] Dissertation
Event
Image
InteractiveResource
[New in Schema 4.4] Journal
| valign=”top” |
[New in Schema 4.4] JournalArticle
Model
[New in Schema 4.4] OutputmanagementPlan
[New in Schema 4.4] PeerReview
PhysicalObject
[New in Schema 4.4] Preprint
[New in Schema 4.4] Report
| valign=”top” |
Service
Software
Sound
[New in Schema 4.4] Standard
Text
Workflow
Other
|}
Best/recommended practice is to consider the resourceTypeGeneral as the broader term which is then modified by the value string, so that a classification can be formed by concatenating the two with ‘/’. So, for example:
<resourceType resourceTypeGeneral="Dataset">PDS4 Refereed Data Collection</resourceType>
would read as “Dataset/PDS4 Refereed Data Collection”.
[New in Schema 4.4] The value “Text” is deprecated except as a last resort before going with Other. Wherever possible, please use a more specific reference to a type of textual publication (i.e., JournalArticle or Dissertation).
Here are the values to use for non-text SBN cases:
In general, we should aim to be consistent with Dublin Core usage for these terms, but decisions here will have consequences elsewhere in the database. Consistency across PDS would be highly desirable here.
OPTIONAL
This element lists keyword-type classifications as are commonly associated with journal articles.
OPTIONAL
This element provides a string that corresponds to a keyword or similar classifier for the resource. It may be repeated as desired. Each occurrence should contain only a single taxonomic-type entry, and the taxonomy should be indicated via the optional attributes as far as possible.
Optional attribute: subjectScheme. This should be the name of the taxonomy or authority. There is no controlled value list. Optional attribute: schemeURI. This should be a reference to the taxonomy definition or reference site. Optional attribute: valueURI. If there is a URL, for example, for the definition of the specific term being used, include it here. Optional attribute: xml:lang. Use this attribute to provide the standard ISO abbreviation for the language of the term. [4.4 addition] Optional attribute: classificationCode. Use this to provide the code within a system that does not have individual valueURIs but does have an internal code for each concept. (SBN data sets should use the UAT which does have valueURIs, so this attribute should not be used.)
For PDS and SBN data sets, subject keywords should be from the Unified Astronomy Thesaurus, which does provide valueURIs. Here’s a sample ** referencing the UAT:
<subject subjectScheme="UAT" schemeURI="http://astrothesaurus.org" valueURI="https://astrothesaurus.org/uat/280">Comets</subject>
If you cannot find an appropriate value in the UAT, please let SBN know and we’ll suggest an update.
OPTIONAL
This element provides a means for identifying people and organizations, other than the previously identified <creator>, who contributed to the creation, management, curation, distribution, etc., of the resource being described.
OPTIONAL
This element identifies a person or organization who made or makes some contribution to the resource. There is a required attribute to define the type of contribution. The element may be repeated as needed.
Required attribute: contributorType. This must have one of the following values:
{| cellpadding=”10”
|- | valign=”top” |
ContactPerson
DataCollector
DataCurator
DataManager
Distributor
Editor
HostingInstitution
| valign=”top” |
Producer
ProjectLeader
ProjectManager
ProjectMember
RegistrationAgency
RegistrationAuthority
RelatedPerson
| valign=”top” |
Researcher
ResearchGroup
RightsHolder
Sponsor
Supervisor
WorkPackageLeader
Other
|}
These are all defined in the appendix to the DataCite schema description document, but interpreting them into a PDS context should be done with care.
Here are some suggestions:
{| class=”wikitable” style=”background-color:lime”
! Contributor Role !! Use for |- | Data Collector || People involved in collection or compiling the data object but not otherwise involved in generating labels or archive support information, and are not otherwise credited as authors or editors. |- | Data Curator || The PDS Node/Subnode where the primary copy of the data physically reside. |- | Editor || Someone who formatted or otherwise altered the content of data product files or archive labels created by someone else. |- | Producer || Someone who is involved in designing and creating the PDS4 archive labels and support files, who is not otherwise credited. |- | colspan=”2” | Other contributor roles may be used if appropriate, but generic roles should be avoided and no role should be used gratuitously. Do not use the ContactPerson, or RelatedPerson roles in particular, as these do not age well in an archive and will not be maintained - at least not by me. |}
REQUIRED
The name of a single person or organization contributing. As in the case of <creator>, this should be in the format “Family, Given” for personal names, and the formal name for organizations.
Optional attribute: nameType. It must have one of these two values: :* Personal
:* Organizational
Best practice is to use the optional attribute.
OPTIONAL
The given name of a personal name, analogous to the same field for <creatorName>.
OPTIONAL
The surname or patronymic of a personal name, analogous to the same field for <creatorName>.
OPTIONAL
A formal identifier for a person or organization, such as a personal ORCID or an organizational DOI. It may be repeated if there is more than one applicable identifier.
Required attribute: nameIdentifierScheme. This is the type of the identifier (“ORCID” or “DOI”, e.g.). Optional attribute: schemeURI. This is a URI reference to the identifier definition or defining organization.
OPTIONAL
This element contains the name of an organization or institution with which the named contributor is affiliated. It is a free-format text field. It should be repeated for each unique affiliation when there is more than one.
In the archiving case, this must be interpreted as “affiliation at the time of publication of the product(s)” - in other words, affiliation on the date given for ‘’<publicationYear>. |
Optional attribute: affiliationIdentifier. The value should be a formal, permanent, unique identifier for the affiliated organization, beyond the name that is the value of the <affiliation> element. For example, a Research Organization Registry (ROR) ID would be ideal here.
Optional attribute: affiliationIdentifierScheme. The (human-recognizable) name of the identifier system (e.g., “ROR” would be sufficient in the above case.
Optional attribute: schemeURI. The URI of the identifier scheme, typically a URL.
OPTIONAL
This element provides a way to include various significant dates in the DOI database record.
OPTIONAL
One significant date for the resource. Dates should be in ISO 8601 format and can be to any precision (but this is not schematically enforced). This element may be repeated as needed for each date.
Required attribute: dateType. This indicates the significance of the date and must be one of the following values:
{| cellpadding=”10”
|- | valign=”top” |
Accepted
Available
Collected
Copyrighted
Created
Issued
| valign=”top” |
Other
Submitted
Updated
Valid
Withdrawn
|}
These are defined in the DOI Schema description document.
Optional attribute: dateInformation. This should be a very brief clarification of the dateType, where necessary.
Wherever it is possible to do so, SBN must include an <Available> date that is the year and month of publication - so the year must agree with the previously listed <publicationYear> value. This date is the date ADS will use in generating statistics over various periods, so it is important that at least the month be present whenever it is known. As with <publicationYear>, the PDS3 DATA_SET_RELEASE date should usually be considered authoritative. |
OPTIONAL
The natural language of the resource. This is defined as being of type xs:language, which provides syntax validation but does not actually fully enforce that values come from the “IETF BCP 47, ISO 639-1 language code,” as specified in the description.
For most purposes, “English” is assumed and there is no need to attempt to distinguish between American, Canadian, British, or any other sub-categories of modern English. If you’re a completionist, though, feel free to include <language>en</language> in your DOI metadata. |
OPTIONAL
This element lists alternate identifiers for the same instance of the resource (as opposed to physically distinct, duplicate copies with their own identifiers). The identifiers should be unique and controlled within some context which should be specified.
In the DOI metadata context, PDS3 Data Set IDs and PDS4 LIDVIDs are “alternate identifiers”. Typically we would want the DSID or LIDVID to be included in a citation, so we need to pay particular attention to content here to make sure it is consistent and thus programmatically retrievable. PDS4 LIDs without the version ID are not identifiers in the context of DOIs, because the thing they point to is not permanently fixed (a LID alone refers to the “latest available version”, which may change).
For PDS Product: |
Use: |
|---|---|
PDS3 Product |
DSID:PRODUCT_ID |
PDS3 Data Set |
DATA_SET_ID |
PDS4 Product |
Product LIDVID |
PDS4 Collection |
Collection LDVID |
PDS4 Bundle |
Bundle LIDVID* |
*Note that a Bundle that does not change its own version ID every time a collection it contains changes its version ID should not have its own DOI. The DOI needs to be associated with an unchanging entity. If the bundle doesn’t change when any of its collections changes, then it is not an “unchanging entity”. |
OPTIONAL
This element provides one instance of an alternate identifier for the resource. It may be repeated as desired.
Required attribute: alternateIdentifierType. This string must describe the source or context of the identifier.
{| class=”wikitable” style=”background-color: lime”
! For PDS Identifier: !! Use alternateIdentifierType: |- | PDS3 DSID:PRODUCT_ID || PDS3 Product ID |- | PDS3 DSID || PDS3 Dataset ID |- | PDS4 Product LIDVID || PDS4 Product ID |- | PDS4 Collection LIDVID || PDS4 Collection ID |- | PDS4 Bundle LIDVID || PDS4 Bundle ID |}
OPTIONAL
This element lists identifiers for other resources related to this resource in some specific way. This is an important attribute to include in our DOI metadata. This is where we tie into the published literature, so some effort should be put into getting this right. It’s also where we can related different versions of the same PDS product (each of which will have its own DOI).
Citation Considerations
This is where we indicate which papers and other data sets are cited by the data set getting the DOI. This is not a “reading list”. When in doubt, consider the data set/product as if it were being prepared for publication in a refereed journal. If the citation would be appropriate in that context, then it is likely appropriate in this one.
Citing Conventions¶
Here are some draft guidelines developed at SBN/UMD during a discussion among the node personnel for where to look for citations to include in DOI metadata as relatedIdentifiers of the type Cites or isCitedBy:
Raw and Calibrated Data
Cites any inline citation in the text of the overview and/or intro document
Cites any published papers describing the mission and/or relevant instrumentation referenced by the archive
Calibrated data Cites raw data and calibration data; raw and calibration data isCitedBy calibrated data
High-level Data
Cites immediate precursor products (e.g., mosaic Cites calibrated images; resampled data Cites full-resolution data); precursor data isCitedBy high-level data
Cites published paper describing the derivation/processing, if any.
Calibration Data
Cites mission and hardware papers, as appropriate.
Other Relationships
The next most important relationship to note here is that between older and newer versions. Where both things have DOIs, the metadata should be updated in both cases to provide bi-directional pointing. This can also be used to indicate predecessors even when there are multiple predecessors that were combined, or one that was split.
Other relationships should be documented if that makes sense both in the context of the DOI metadata as well as the PDS archive. Some of the likely ones to occur are listed following.
OPTIONAL
This element is a single related identifier. It can be repeated as needed for additional identifiers. Note that it has half a dozen attributes, only two of which are required, to help in defining the relationship. Standard values are defined in the DataCite schema documentation.
Required attribute: relatedIdentifierType. The value must come from the following list:
{| cellpadding=”10”
|- | valign=”top” |
ARK
arXiv
bibcode
DOI
EAN13
EISSN
| valign=”top” |
Handle
IGSN
ISBN
ISSN
ISTC
LISSN
| valign=”top” |
LSID
PMID
PURL
UPC
URL
URN
w3id
|}
Do not include more than one <relatedIdentifier> for the same publication/work to be cited or related. For general use, DOI is the preferred identifier for all relationship types. For citation, bibcode is acceptable, but should only be used if there is no DOI available. When both exist, ADS (who issue bibcodes) have specifically requested that we only use the DOI in this list to cite the other work. ISBN and arXiv might also be available and could be used in cases where this is no DOI.
Required attribute: relationType. The value must come from the following list:
{| cellpadding=”10”
|- | valign=”top” |
IsCitedBy
Cites
IsSupplementTo
IsSupplementedBy
IsContinuedBy
Continues
IsNewVersionOf
IsPreviousVersionOf
IsPartOf
HasPart
[New in Schema 4.4] IsPublishedIn
| valign=”top” |
IsReferencedBy
References
IsDocumentedBy
Documents
IsCompiledBy
Compiles
IsVariantFormOf
IsOriginalFormOf
IsIdenticalTo
HasMetadata
IsMetadataFor
| valign=”top” |
Reviews
IsReviewedBy
IsDerivedFrom
IsSourceOf
Describes
IsDescribedBy
HasVersion
IsVersionOf
Requires
IsRequiredby
Obsoletes
IsObsoletedBy
|}
Following is a summary of the relationships most likely to be useful in our context.
{| class=”wikitable” style=”background-color:lime”
! relationType !! Use for: |- | Cites/IsCitedBy || Standard citation of previous/subsequent work |- | IsVariantFormOf || PDS4 versions of PDS3 data sets, where the PDS3 data set has a DOI and no substantive changes (i.e., an external peer review was not required for the PDS4 version) have been made in migrating the data from PDS3 to PDS4. This should be included in the DOI metadata for both the PDS3 and PDS4 versions. |- | IsNewVersionOf/IsPreviousVersionOf || Datasets that are new/previous versions (that is, same ID but different version number) of datasets that also have DOIs; in this case both DOIs should have their metadata updated. Also, if a PDS3-to-PDS4 migration did require substantive changes to the data file, then this is the appropriate relationship between the two. |- | Obsoletes/IsObsoletedBy || When a dataset supersedes a dataset with a different ID (in the same ID system), use this relationship. |- | IsSupplementTo || Data that is the basis of or direct result of a journal article, but that was not published as part of the article - especially where the data set is mentioned in that publication |- | IsReferencedBy/References || Bibliographic references (as opposed to citations) |- | IsDerivedFrom/IsSourceOf || Raw-Calibrated relationships; high-order products and the contributing source products |- | IsPartOf/HasPart || Bundles and their constituent collections when both have DOIs. IsPartOf can also be used when a data product comprises one or more tables that were published (in their entirety) as part of a journal article or book. |- | colspan=”2” | Other relationships can and should be used where they seem useful. |}
Optional attribute: resourceTypeGeneral. This attribute is identical to the one of the same name in <resourceType>, above.
These optional attributes should only be used when the value of the relationType attribute is either IsMetadataFor or HasMetadata (this is not validated):
Optional attribute: relatedMetadataScheme. This indicates the ID or name of a metadata definition standard. Optional attribute: schemeURI. This should be the URI of the named metadata standard. Optional attribute: schemeType. The DataCite definition is not clear, but this looks like a specific file format type for the referenced metadata standard (such as “XSD”).
[New in Schema 4.4]¶
OPTIONAL
This element is used for two purposes:
1. To provide reference information for a traditional publication that has no DOI; and 2. To provide additional information about the publication context of a reference that does have a DOI (for example, to document the book that contains a chapter in the citation list).
SBN will generally be using this element for the first purpose. Note that no verification is done by DataCite for the publication information in this class even when a DOI is present, so type carefully and check it twice.
OPTIONAL
A single instance of “related item” information. Like <relatedIdentifier>, this element has several attributes.
Required Attribute: relatedItemType. This must have a value from the same list as the resourceTypeGeneral attribute of the <resourceType> element above.
Required Attribute: relationType. This must have a value from the same list as the relationType attribute of the <relatedIdentifier> element above.
OPTIONAL
If the related item has a digital identifier, it should be specified here in the same manner as would be used for <relatedIdentifier>, above.
Optional Attribute: relatedItemIdentifierType. This must have a value from the same list as relatedIdentifier, above. Unlike <relatedIdentifier>, however, this attribute is optional.
Optional Attributes: relatedMetadataScheme, schemeURI, and schemeType. These are used in the same circumstances and in the same way as for <relatedIdentifier>, above. For SBN data sets, these are very unlikely to be relevant.
OPTIONAL
This is a grouping element for the creator list of the related item.
OPTIONAL
This element is similar to the <creator> element for the resource itself, but does not allow specification of a nameIdentifier or affiliation.
REQUIRED
As with the creators listed for the resource, the name should be given in the format “familyName, givenName”.
Optional Attribute: nameType, which must be either Organizational or Personal.
Optional Attribute: xml:lang, which can be used to indicate the language in which the name is expressed.
OPTIONAL
The given name of the creator.
OPTIONAL
The family name of the creator.
OPTIONAL
This container class is used to hold the title of the related item, and any alternate titles for that item.
OPTIONAL
This element holds the title of the related item, if it has one. It may be repeated if that seems appropriate.
Optional Attribute: titleType. If there is more than one title, then the secondary titles should have an associated titleType to explain their existence. The values come from the same list as used for the title of the resource, above.
Note there is not an enclosing <titles> class in this case.
OPTIONAL
If the related item has aassociated volume identifier (numeric or otherwise), here’s where it goes.
OPTIONAL
If the related item has an associated issue identifier (numeric or otherwise), it goes here.
OPTIONAL
This element is for an associated sequence number, or similar (possibly non-numeric) identifier.
Optional Attribute: numberType. Use the attribute to indicate what kind of number (corresponding to common prefixes in reference list formats) the element contains. It must have one of these values:
{| cellpadding=”10”
|- | valign=”top” |
Article
Chapter
Report
Other
|}
OPTIONAL
This and the following element are for specifying a start and end page for the item within the enclosing volume, issue, etc. If only one page is known, assume it is the starting page and use <firstPage> without <lastPage>.
OPTIONAL
This is for specifying the end of the page range of the related item within its containing publication. If only one page is known, assume it is the starting page and use <firstPage> without <lastPage>.
OPTIONAL
This element indicates the publisher of the related item, not the resource receiving the DOI.
OPTIONAL
The year in which the related item was made publicly available. As with the <publicationYear> of the resource, this must be in the range [0..9999].
OPTIONAL
This element is used to provide an edition or version number for the related item.
OPTIONAL
This is an enclosing element to hold a list of contributors to the related item.
OPTIONAL
This element identifies a single contributor.
Required Attribute: contributorType. This indicates the role the named contributor filled. This must come from the same controlled-value list as listed above for the contributors to the resource.
REQUIRED
As with the contributors listed for the resource, the name should be given in the format “familyName, givenName”.
Optional Attribute: nameType, which must be either Organizational or Personal.
Optional Attribute: xml:lang, which can be used to indicate the language in which the name is expressed.
OPTIONAL
The given name of the contributor.
OPTIONAL
The family name of the contributor.
OPTIONAL
This element provides unstructured size information. In other words, it is not required to be numeric and there are no syntax constraints on the content.
OPTIONAL
A single size specification string, like “18GB” or “Three volumes”. This element may be repeated as needed or desired.
Some Examples |
|---|
<size>55GB</size> |
<size>3250 tables<size> |
<size>235 FITS images<size> |
<size>24 documents in multiple formats<size> |
OPTIONAL
This class indicates the physical/digital format(s) of the resource.
OPTIONAL
This element contains a text description of the format. It is not constrained and may be repeated as appropriate.
Best practice is to use a file extension or MIME type string as the value.
PDS should be more formal about the content here. We also need to think about possible mixed-format products, like single documents that comprise multiple files, some of which are text and some images/graphics, and the best way to describe format for collections (if at all). |
Some Examples |
|---|
<format>text/plain</format> |
<format>text/plain;charset=utf-8</format> |
<format>text/csv</format> |
<format>text/tab-separated-values</format> |
<format>text/vnd.ascii-art</format> |
<format>application/pdf</format> |
<format>application/msword</format> |
<format>text/xml</format> |
<format>image/fits</format> |
<format>application/fits</format> |
Other media types (MIME types) may be found by referencing the list provided by the Internet Assigned Number Authority (IANA) at https://www.iana.org/assignments/media-types/media-types.xhtml. There is no media type corresponding to PDS3 .img images, or plain raster images (as far as I can tell).
OPTIONAL
A version number associated with the resource.
Best practice is to obtain a new DOI for a major version change of something that already has a DOI.
Because of the traceability and reproducability concerns involved in research data, PDS should never use this element for archival data. New versions of PDS products with DOIs should get their own DOIs. The <relatedIdentifier> element can be used to link the two versions in the DOI database. |
OPTIONAL
This element typically contains only a single <rights> member to indicate the rights management for the resource, although it may contain multiple <rights> elements in complex cases.
OPTIONAL
A single rights license with management information (e.g., “Creative Commons”, or “GNU General Public License”). This should be as explicit as possible, with a complete management statement where appropriate. Embargo information should also be recorded here.
Optional attribute: rightsURI. This should be the URI to the full text of the license. Optional attribute: rightsIdentifier. A short, standardized license name. Best practice is to use one of the identifiers on the SPDX list: https://spdx.org/licenses/ Optional attribute: rightsIdentifierScheme. The name of the scheme for the identifier, immediately preceding. If the identifier same from the SPDX list, for example, then this attribute should have the value SPDX. Optional attribute: schemeURI. The URI corresponding to the definition of whatever is in rightsIdentifierScheme. In general, those two attributes should be used together. Optional attribute: xml:lang. This indicates the language of the license.
PDS data is in the public domain for some values of “public domain”, but this is not a well-defined term. Also, in order to be considered FAIR, PDS data must have an explicit statement of license. “U.S. Government Work” might be correct, but this is typically applied to documents. Repeated requests to PDS and NASA for direction have gone nowhere. |
OPTIONAL
This element provides a place for additional information that does not fit into other categories.
OPTIONAL
A single, free-format description of the specified (via attribute) type. This field may be repeated as needed.
It looks like formatting is not preserved for this text, but you may use the <br/> tag to insert a paragraph break.
Best practice is to provide at least one description of some type. It is probably not a good idea to provide multiple <description> elements with the same descriptionType value, but this is not validated.
Required attribute: descriptionType. This indicates the category of information being provided. It must have one of these values: :* Abstract
:* Methods
:* SeriesInformation
:* TableOfContents
:* TechnicalInfo
:* Other
All PDS DOIs must have at least one <description> field with a descriptionType of Abstract. Note that if you create a DOI through the Fabrica interface, the description you enter there is not tagged as an abstract. If other description types seem appropriate, add them. |
Optional attribute: xml:lang. This indicates the language of the description being provided, not of the resource.
OPTIONAL
This element is used to define relationships (either on the creation or application side) between the resource and a defined patch on the surface of the Earth. I don’t see a way to apply it as it currently exists to celestial coordinates, and that might seriously confuse applications that process this sort of metadata harvested from DOI databases. It’s included here for completeness.
OPTIONAL
This element defines one specific patch of Earth where the data were taken or on which the resource is focused. It may be repeated as desired.
OPTIONAL
A name for the location being defined.
Note that the text provided in the schema that describes the points comprising the following elements as having values which are “a single latitude-longitude pair, separated by whitespace”. This is not true. In all cases there are tags specifically defining latitude and longitude as separate and distinct elements.
It is also possible to define any single <geoLocation> as being simultaneously a single point, a single box, and any number of polygons. This seems irrational, yet it appears to be deliberate.
OPTIONAL
This element specifies a single point on the globe.
REQUIRED
Longitude in degrees in the range +/- 180.
REQUIRED
Latitude in degrees in the range +/- 90.
OPTIONAL
A box is defined by its four sides - east and west longtude, and north and south latitude.
REQUIRED
Westward bounding longitude in degrees in the range +/- 180.
REQUIRED
Eastward bounding longitude in degrees in the range +/- 180.
REQUIRED
Southward bounding latitude in degrees in the range +/- 90.
REQUIRED
Northward bounding latitude in degrees in the range +/- 90.
OPTIONAL
This element defines an arbitrary polygon as a sequence of points around the perimeter in which the last point must have the same definition as the first point (though this is not validated, nor is the nature of the path). There must be at least 4 points provided.
Oddly, the schema allows this element to be repeated.
REQUIRED
Longitude and latitude of one point on the perimeter of the polygon.
REQUIRED
Longitude in degrees in the range +/- 180.
REQUIRED
Latitude in degrees in the range +/- 90.
OPTIONAL
If you are intending to define an area that is larger than half the total surface of the Earth, then you must use this element to define a point somewhere inside the area of interest. Otherwise the smaller enclosed area is assumed to be the area of interest. The actual point can be random, as long as it is inside the intended area.
REQUIRED
Longitude in degrees in the range +/- 180.
REQUIRED
Latitude in degrees in the range +/- 90.
OPTIONAL
This element identifies sources of funding related to creating or maintaining the resource.
This is not information that PDS has traditionally collected, but as it is used to trace results back to funding in the literature databases, we probably should. In the case of ROSES data preparers, I’d make that “definitely should”. |
OPTIONAL
This element identifies a single source of funding. It may be repeated as needed.
REQUIRED
Name of the funding source. This should be the formal name.
OPTIONAL
This is a string that uniquely identifies a funding source under some public scheme, like “Crossref Funder” or ISNI.
Required attribute: funderIdentifierType. This string is the source of the corresponding identifier. It must have one of these values: :* ISNI
:* GRID
:* Crossref Funder ID
:* ROR
:* Other
NASA’s Crossref Funder ID is 10.13039/100000104.
OPTIONAL
Grant number or similar code assigned by the funding organization.
Optional attribute: awardURI. This attribute can be used to provide a link to a page at the funding organization website that describes the award/grant program.
OPTIONAL
The title on the grant/award - that is, the title of the proposal that was submitted and funded.


iPTMnet is a bioinformatics resource for integrated understanding of protein post-translational modifications (PTMs) in systems biology context. It connects multiple disparate bioinformatics tools and systems text mining, data mining, analysis and visualization tools, and databases and ontologies into an integrated cross-cutting research resource to address the knowledge gaps in exploring and discovering PTM networks.
Error in obtaining the iPTMnet network, please try again later!
This table shows the enzymes that targets the PTM/Protein.
| PTM/Protein | PTM | Amino Acid | Site | Type | Enzyme | Score | {{gene.PTMProtein}} | {{gene.PTM}} | {{gene.amino}} | {{gene.site}} | {{gene.type}} | {{gene.enzyme}} | {{gene.score}} |
|---|
Kinase network of phosphorylated genes reflects the connection between kinases and gene products phosphorylated at specific sites. Solid lines mean known relations between the kinases and target genes (in Known_Kinase_TargetGene) or exact matching between the kinase target and the peptide sequence in (Known+Predicted_Blosum50_Kinase_TargetGene and Known+Predicted_Probability_Kinase_TargetGene). Dashed lines show probable inkage between kinase and target genes based on blosum50 similarity scores or phosphosite plus connectivity networks.
Error in obtaining the Kinase-Gene network network, please try again later!
This table shows the known and predicted kinases targeting the input PTM proteins. The kinases shown here are based on the known kinases in the phosphositePlus and predicted kinases based on the blosum50 similarity score of the phosphosite sequence and known kinase target sequences.
Error in obtaining the kinases to targeted Phosphosite network, please try again later!
| PTM/Protein | Amino Acid | Sequence | Kinase | Kinase Organism | Kinase Target Sequence | Blosum50 Score | {{gene.phosphoGene}} | {{gene.amino}} | {{gene.geneSequence.slice(0,7)}}{{gene.geneSequence.slice(7,8)}}{{gene.geneSequence.slice(8,gene.geneSequence.length)}} | {{gene.kinase}} | {{gene.kinaseOrganism}} | {{gene.kinasePeptide.slice(0,7)}}{{gene.kinasePeptide.slice(7,8)}}{{gene.kinasePeptide.slice(8,gene.kinasePeptide.length)}} | {{gene.blosum50ScorePercent}}/{{gene.blosum50MaxScore}} |
|---|
{{ctrl.numberOfAllValidGenes}} out of {{ctrl.numberOfAllInputGenes}} input genes are common with Homo Sapiens.
non conforming genes with Homo Sapiens genes: {{nonValid}},| Gene Symbol | Gene Name | HGNC ID | Gene Family | Previous Symbols | Uniprot IDs | {{gene.symbol}} | {{gene.name}} | {{gene.hgnc_id}} | {{gene.gene_family_name}} |
{{symbol}} |
{{uniprot}} |
|---|
Pathway view network shows network of pathways or perturbations that target the input genes.
Gene-Pathway analysis error, Please try again.
Pathway view network shows network of pathways or perturbations that target the input genes.
Gene-Pathway analysis error, Please try again.
Enrichment view identifies pathways or proteins that are over-represented in a large set of genes or proteins, and may have an association with disease phenotypes.
Enrichment analysis error, Please try again.
| Pathway | P Value | Gene List | {{item.pathway}} | {{item.pValue}} | {{gene_id}}, |
|---|
Kinase network view shows network of kinases phosohorylating the input genes and list of genes getting phosphorylated by the input genes.
Gene-Kinase analysis error, Please try again.


Natural gas is increasingly used in residential, commercial, and industrial applications. Using Green Button subscriptions to benchmark usage as well as to measure and monitor growth


Getting started with Pixen
You're about to start working with the Mac's best pixel art software. To begin, you must create a new document.
To create a new document:
Use the File > New (⌘N) menu item.
Pixen will prompt you for the size you'd like your new document to be, but don't worry: you can always change it later. Now that you've got a document open, take a look over at the tool palette, which looks like this:
Simply select a tool by clicking on it to begin using it with your image. All tools operate with a simple click-and-drag operation, just as they would in any other graphics program. See the topics below for more information:


Web app to find a driving school tailored to the user's needs.
This is a replica of Newsweek site built using the Bootstrap framework.
The simple restaurant page is built with the Javascript and Webpack of a minimal amount of HTML code.
This project is a Weather application. Used technologies such as async JS, promises, async / await, and also implemented the ability to connect third-party API services.
Web App For Planning And Cost Accounting In Various Groups And Categories, Can Be Used By One Or More Users.


datetime-input in
iron-form
Prevent automatic form redirection
hour12 format
property for value:
datetime
date
time
valueAsNumber
year
month
day
hour
minute
second
millisecond
name:
job:
first day (required):
expected retirement:
last job (required):
return:
Submit
Validate


#include <openjpeg.h>
Data Fields | |
| OPJ_UINT32 | tx0 |
| tile origin in x = XTOsiz | |
| OPJ_UINT32 | ty0 |
| tile origin in y = YTOsiz | |
| OPJ_UINT32 | tdx |
| tile size in x = XTsiz | |
| OPJ_UINT32 | tdy |
| tile size in y = YTsiz | |
| OPJ_UINT32 | tw |
| number of tiles in X | |
| OPJ_UINT32 | th |
| number of tiles in Y | |
| OPJ_UINT32 | nbcomps |
| number of components | |
| opj_tile_info_v2_t | m_default_tile_info |
| Default information regarding tiles inside image. | |
| opj_tile_info_v2_t * | tile_info |
| information regarding tiles inside image |
|
|
Default information regarding tiles inside image.
|
|
|
number of components
|
|
|
tile size in x = XTsiz
|
|
|
tile size in y = YTsiz
|
|
|
number of tiles in Y
|
|
|
information regarding tiles inside image
|
|
|
number of tiles in X
|
|
|
tile origin in x = XTOsiz
|
|
|
tile origin in y = YTOsiz
|


|
User: Kent Profile completed 60% |
Uploaded Audio Files |
Uploaded Video Files |
|
User: Kent Profile completed 60% |
Uploaded Audio Files |
Uploaded Video Files |


The angular-datatables
provides a datatables
directive you can add to your

:
| ID | First name | Last name |
|---|---|---|
| 1 | Foo | Bar |
| 123 | Someone | Youknow |
| 987 | Iamout | Ofinspiration |
The angular-datatables
provides a datatables
directive you can add to your

:
| ID | First name | Last name |
|---|---|---|
| 1 | Foo | Bar |
| 123 | Someone | Youknow |
| 987 | Iamout | Ofinspiration |
| ID | First name | Last name |
|---|---|---|
| 1 | Foo | Bar |
| 123 | Someone | Youknow |
| 987 | Iamout | Ofinspiration |


Permission¶
The Permissions are created between SensorGroups and UserGroups in Building Depot which come together to form the access control lists.Here we select a User Group and a Sensor Group and a permission value with which we want to associate these both. There are three levels of permission defined in BuildingDepot which are ‘d/r’ (deny read) ,’r’ (read), ‘r/w’ (read write) and ‘r/w/p’ (read write permission). If there are multiple permission mappings between a user and a sensor then the one that is most restrictive is chosen. Permissions can be defined in the CentralService at http://www.example.com:81/central/permission.
Create Permission¶
This request creates a new Permission link between a UserGroup and a SensorGroup.
-
POST
/api/permission
¶
| JSON Parameters: | |||||||
|---|---|---|---|---|---|---|---|
|
Example request:
POST /api/permission
{
"data":{
"sensor_group":"Test Sensor Group",
"user_group":"Test User Group",
"permission":"r"
}
}
Example response (for success):
HTTP/1.1 200 OK
Content-Type: application/json
{
"success": "True"
}
Example response (for failure):
HTTP/1.1 200 OK
Content-Type: application/json
{
"success": "False",
"error": " User group does not exist"
}
{
"success": "False",
"error": " Sensor group does not exist"
}
{
"success": "False",
"error": " Permission value does not exist"
}
Read Permission¶
This request retrieves Permission level assigned for existing SensorGroup and UserGroup.
-
GET
/api/permission?user_group=<user_group>&sensor_group=<sensor_group>
¶ Parameters: - user_group (string) – Name of UserGroup (compulsory)
- sensor_group (string) – Name of SensorGroup (compulsory)
Returns: - success (string) – Returns ‘True’ if a permission exists between the sensor and user group otherwise ‘False’
- permission (string) – Contains the permission level that are attached to this SensorGroup and UserGroup
Status Codes: - 200 OK – Success
- 401 Unauthorized – Unauthorized Credentials (See HTTP 401)
Example request:
GET /api/permission?user_group=Test User Group&sensor_group=Test Sensor Group
Accept: application/json; charset=utf-8
Example response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"success": "True"
"permission": "r"
}
Example response (for failure):
HTTP/1.1 200 OK
Content-Type: application/json
{
"success": "False",
"error": " Permission does not exist"
}
Delete Permission¶
This request deletes the permission link between the UserGroup and SensorGroup
-
DELETE
/api/permission?user_group=<user_group>&sensor_group=<sensor_group>
¶ Parameters: - user_group (string) – Name of UserGroup (compulsory)
- sensor_group (string) – Name of SensorGroup (compulsory)
Returns: - success (string) – Returns ‘True’ if a permission is deleted between the sensor and user group otherwise ‘False’
Status Codes: - 200 OK – Success
- 401 Unauthorized – Unauthorized Credentials (See HTTP 401)
Example request:
DELETE /api/permission?user_group=Test User Group&sensor_group=Test Sensor Group
Accept: application/json; charset=utf-8
Example response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"success": "True"
}
Example response (for failure):
HTTP/1.1 200 OK
Content-Type: application/json
{
"success": "False",
"error": " Permission does not exist"
}
{
"success": "False",
"error": " You are not authorized to delete this permission"
}
{
"success": "False",
"error": "Missing parameters"
}


Written Therapy EP
Available August 2019
Dear audience my naughtyness requires your attention.
You're about to need some earplugs for a proper prevention.

It's part of our recruitment of some fancy dancing groupies.

We are the good thing in your life you've been waiting for to happen.

'Cause that's the part you're playing in the fellowship of Static Try.


Package Guide
Detailed documentation is included in the 8 scripts that make up PyTrx. Each script contains classes and functions for handling each aspect needed for photogrammetric processing.
For beginners in programming, it is advised to look at the example applications provided in the GitHub repository and adapt them accordingly for your own use. For experienced programmers, get stuck in. Feel free to contact us if you run into major problems or have constructive comments that will help us further PyTrx and its capabilities. We will not respond to minor troubleshooting or unconstructive comments.
CamEnv
Handles the associated data with the camera environment. The GCPs class handles the Ground Control Points (GCPs) and their correspondence to the associated DEM and CamImage object. The CamCalib class handles information concerning the camera calibration, i.e. the intrinsic camera matrix and lens distortion coefficients. This class contains functionality for reading in calibration files from .txt and .mat formats.
The CamEnv compiles all the information about the camera environment from the GCPs and CamCalib classes, and also contains information about the camera object (pose and location). This is also where georectification functionality is held, with functions for projection and inverse projection. The class is initialised using a .txt file containing file path directories to all the associated data files.
DEM
Handles the DEM data. This currently supports .mat and .tif file types. The ExplicitRaster class represents a DEM as a numeric raster with explicit XY cell referencing in each grid cell. The class includes functions for densification, calculating viewsheds, and incorporates unbound functions that import a DEM file from .mat and .tif formats.
FileHandler
This module contains a set of functions for reading in data from files (such as image data and calibration information) and writing out data.
Images
Handles the image data, and the image sequence. The CamImage class holds information about a singular image and contains functionality for importing image data from file and passing specific image bands forward for subsequent processing. The ImageSequence class holds information about an image sequence, i.e. a collection of CamImage objects, from which specific images and image pairs can be called.
Velocity
Calculates velocities and homography. This can either be achieved through the Velocity class for processing velocities and homography through a series of images, or using the functions provided within the script for processing velocities and homography between an image pair.
Area
Automated and manual detection of surface areas from imagery (e.g. supraglacial lakes, meltwater plume surface extent). This can either be achieved through the Area class for defining areas of interest through a series of images, or using the functions provided within the script for defining areas of interest in a single image.
Line
Manual detection of line features from imagery (e.g. glacier terminus position). This can either be achieved through the Line class for defining line features through a series of images, or using the functions provided within the script for defining line features in a single image.
Utilities
This module contains a set of functions for plotting and interpolating data.


We collect information about events that concern the history of products and subsystems into a chronology which we implement as an RB-TREE oredered by TIME-STAMP.
The user can specify several parameters which govern the history reports:
Is there a difference between the ways subsystem branches and product branches are treated?
These are the events that must be captured in the history reports and the information to be collected for them:
NOTE: We record the product and branch information because in the case of a subsystem history report we want to track when the subsystem was used by which product branches.
See previous note.
All events have a timestamp marking the point in the timeline when they affected the product.
We will define a CLOS class to model each of these kinds of events.
We define the following fuinctions for collecting events into a chronology:
The cronology will collect several cosynchronous events of the same type concerning several subsystems of the product. Under certain circumstances, such a set of events should be coalesced into a single event for the product rather than being displayed as a separate event for each subsystem.
Each event type will implement a method for HISTORY-EVENT-DISPLAY which will output html describing the event to a specified stream.
HP wants a count of the number of lines added and removed for each transaction. This is potentially expensive to compute. Perhaps we can cache it in the master catalog someday.


I was born and raised in Japan, and arrived to Queens NYC in 2005. The following year we moved to Washington D.C. I love the expansive tree canopy of the city and diverse cultural scenes fitting soundly in one place.
My favorites: Starting projects from scratch, arranging family albums, gluten free baking on Sundays, indulging in artisanal ice cream on the rooftop, traveling and staying at Airbnb, sketching people’s profiles… to name a few.
A fun fact: I can sit down on a chair half way, with my back straight for a pretty long time thanks to the muscle memory cultivated when I played clarinet in the middle school band.


Loading...
Home
About
Pricing
Our team
Single job
Services
Single service
Careers
Pages
Elements
Typography
Buttons
Forms
Tabs and accordions
Progress bars
Grid
Tables
Blog
Classic blog
Grid blog
Masonry blog
Modern blog
Single post
Gallery
Grid gallery
Masonry gallery
Single product
Extras
404 Page
503 Page
Coming soon
Login/Registration
Privacy policy
Search results
Contacts
Search
Login
Registration
Login
E-mail
Password
Sign In
or use
Registration
Username
E-mail
Password
Confirm Password
Register
or use


RVS_BTDriver_iOS_Test_Harness_MainTableViewController
class RVS_BTDriver_iOS_Test_Harness_MainTableViewController : RVS_BTDriver_iOS_Test_Harness_Base_ViewController
extension RVS_BTDriver_iOS_Test_Harness_MainTableViewController: RVS_BTDriverDelegate
extension RVS_BTDriver_iOS_Test_Harness_MainTableViewController: RVS_BTDriver_DeviceSubscriberProtocol
extension RVS_BTDriver_iOS_Test_Harness_MainTableViewController: UITableViewDataSource
extension RVS_BTDriver_iOS_Test_Harness_MainTableViewController: UITableViewDelegate
-
The table cell prototype reuse ID
Declaration
Swift
let cellReuseIDentifier: String
-
The segue that will bring in a device details page.
Declaration
Swift
let displaySegueID: String
-
This is the index that indicates the segmented Switch is in “not scanning” mode.
Declaration
Swift
static let segmentedSwitchIsOffIndex: Int
-
This is the index that indicates the segmented Switch is in “scanning” mode.
Declaration
Swift
static let segmentedSwitchIsOnIndex: Int
-
The color to use for the segmented switch when not scanning.
Declaration
Swift
static let redSelectedColor: UIColor
-
The color to use for the segmented switch when scanning.
Declaration
Swift
static let greenSelectedColor: UIColor
-
This is set to true, if the app was scanning before it segued.
Declaration
Swift
internal var internal_wasScanning: Bool
-
The image that we display if there is no Bluetooth available.
Declaration
Swift
@IBOutlet weak var noBTImageView: UIImageView!
-
The container view for the controls and table, available if there is an active Bluetooth connection.
Declaration
Swift
@IBOutlet weak var activeBTItemContainerView: UIView!
-
The table that displays discovered devices.
Declaration
Swift
@IBOutlet weak var devicesTableView: UITableView!
-
The scanning/not scanning switch.
Declaration
Swift
@IBOutlet weak var scanModeSegmentedSwitch: UISegmentedControl!
-
This is required for the subscriber support.
Declaration
Swift
var _uuid: UUID!
-
The scanning/not scanning switch changed.
Declaration
Swift
@IBAction func scanModeSwitchChanged(_ inSwitch: UISegmentedControl)
Parameters
inSwitch
The switch instance.
-
Called when the driver encounters an error.
Declaration
Swift
public func btDriver(_ inDriver: RVS_BTDriver, encounteredThisError inError: RVS_BTDriver.Errors)
Parameters
inDriver
The driver instance making the callback.
encounteredThisError
The error that was encountered.
-
Called when the device encounters an error.
Declaration
Swift
func subscribedDevice(_ inDevice: RVS_BTDriver_DeviceProtocol, encounteredThisError inError: RVS_BTDriver.Errors)
Parameters
inDevice
The device instance making the callback.
encounteredThisError
The error that was encountered.
-
Called when a new service is added to the device instance.
Declaration
Swift
public func device(_ inDevice: RVS_BTDriver_DeviceProtocol, serviceAdded inService: RVS_BTDriver_ServiceProtocol)
Parameters
inDevice
The device instance making the callback.
serviceAdded
The new service that was added to the device.
-
Called when the device wants us to update our status.
Declaration
Swift
public func deviceStatusUpdate(_ inDevice: RVS_BTDriver_DeviceProtocol)
Parameters
inDevice
The device instance making the callback.
-
Called when the device encounters an error.
Declaration
Swift
public func device(_ inDevice: RVS_BTDriver_DeviceProtocol, encounteredThisError inError: RVS_BTDriver.Errors)
Parameters
inDevice
The device instance making the callback.
encounteredThisError
The error that was encountered.
-
Declaration
Swift
func tableView(_ inTableView: UITableView, numberOfRowsInSection inSection: Int) -> Int
Parameters
inTableView
The table view that called this.
numberOfRowsInSection
An integer, with the 0-based section (always 0).
Return Value
The number of rows (number of devices).
-
Called to create a cell instance to populate a table cell.
Declaration
Swift
func tableView(_ inTableView: UITableView, cellForRowAt inIndexPath: IndexPath) -> UITableViewCell
Parameters
inTableView
The table view that called this.
cellForRowAt
An IndexPath to the selected cell that needs populating.
Return Value
A newly-created cell instance.
-
This is called when someone taps on a row.
We bring in the inspector for that device, and deselect the row.
Declaration
Swift
func tableView(_ inTableView: UITableView, willSelectRowAt inIndexPath: IndexPath) -> IndexPath?
Parameters
inTableView
The table view that called this.
willSelectRowAt
An IndexPath to the selected row.
Return Value
An IndexPath, if the row is to remain selected and highlighted. It is always false, and we immediately deselect the row, anyway.
-
Indicate that a row can be edited (for left-swipe delete).
Declaration
Swift
func tableView(_ inTableView: UITableView, canEditRowAt inIndexPath: IndexPath) -> Bool
Parameters
inTableView
The table view being checked
canEditRowAt
The indexpath of the row to be checked.
Return Value
true, always.
-
Called to do a delete action.
Declaration
Swift
func tableView(_ inTableView: UITableView, commit inEditingStyle: UITableViewCell.EditingStyle, forRowAt inIndexPath: IndexPath)
Parameters
inTableView
The table view being checked
commit
The action to perform.
forRowAt
The indexpath of the row to be deleted.
-
Called after the view has completely loaded.
Declaration
Swift
override func viewDidLoad()
-
Called just before the view is to lay out its various subviews.
Declaration
Swift
override func viewWillLayoutSubviews()
-
This is called when the screen is about to appear.
Declaration
Swift
override func viewWillAppear(_ inAnimated: Bool)
-
This is called as we prepare to open the device inspector screen. We use it to associate the device instance with the screen.
Declaration
Swift
override func prepare(for inSegue: UIStoryboardSegue, sender inSender: Any?)
Parameters
for
The segue object.
sender
The context we attached to the segue (the device object).
-
Sets up the UI Items.
Declaration
Swift
func setup()


You are about to delete container {{containerId}}
You are about to delete:
This operation cannot be undone


TagRugby.ie Privacy Statement
Irish Tag Rugby Association Limited (hereafter “ITRA”, “we”, “us”), is committed to protecting your privacy. We will only use the information that we collect about you lawfully (in accordance with the Data Protection Act 1998).
In order to make your visits to our website as responsive as possible, we collect information when you visit us. To help ensure an enjoyable online experience for all of our visitors, we provide this summary of what information we collect online, and how we use that information. This privacy policy statement applies only to the information collected online by us.
We are committed to protecting the privacy of users of this website. We are aware that, as a
This privacy statement explains policies on data collection and use practices of the ITRA (www.tagrugby.ie) website (the “Site”) hosted by Jalmia Limited for ITRA. This does not apply to other online or offline ITRA sites, products, or services. Our website contains links to other sites not controlled or operated by us. We are not responsible for the privacy policies of websites that we do not control or operate. By accessing the Site, you are consenting to the information collection and use practices described in this privacy statement.
COLLECTION OF INFORMATION
1. NAVIGATIONAL INFORMATION
We gather navigational information about where visitors go on our website. This information allows us to see which areas are most visited and helps us improve the quality of your online experience by recognising and delivering more of the most desired features and services.
2. TECHNICAL INFORMATION
Technical details in connection with visits to this website are logged by our internet service provider for statistical purposes. No information is collected that could be used by us to identify website visitors unless required to do so by rule of law.
The technical details logged are confined to the following items:
- The User’s IP address
- The previous website address from which the user reached us, including any search criteria used.
- Click screen data which shows the traffic of users around this website - for example pages accessed and documents downloaded.
- The type of web browser used by the website user.
3. COOKIES
Cookies are very small text files stored on your hard drive. They uniquely identify your computer and allow us to store profile information, improve website security and help us to customise your website experience.
Cookies are used on this site for the venue pages. A unique user identity is created when you choose a specific venue as your home location, which ensures that you are brought directly to this venue page next time you visit the website. For more detailed information on cookies, visit www.allaboutcookies.org.
4. PERSONAL INFORMATION
If you register a team or sign up as an individual play for one of our events (or make other transactions on our website), we will gather personal information, such as name, email, telephone number and credit card details, as well as information about your purchases on our website. We will not make this database list available to other unaffiliated companies for their marketing purposes, unless specific consent for such transfer to third party affiliates has been received from you.
If you sign up as a player or referee on our website, you will be asked to provide your email address and mobile contact number. This enables you to receive information on ITRA events from us via email and SMS. We do not make the names in our mailing list available to other unaffiliated companies for their marketing purposes.
USE OF YOUR PERSONAL INFORMATION
ITRA only holds and uses personal information to provide additional service to our customers. These services include, but are not restricted to, making payments easier by holding default details for payment & delivery and informing you periodically by email and/or SMS of upcoming ITRA Events, special offers etc.
If you previously signed up to receive information from us, but no longer wish to receive it, simply email<EMAIL_ADDRESS>or call 01 2020100 and we will remove you from our database. Please be aware, even if you ask to be removed from our mailing list, you will still receive e-mail notifications regarding teams registered in current or upcoming ITRA Events.
ITRA will not disclose ‘Personal Information’ to any unaffiliated third party without prior consent being obtained from the customer concerned, unless if required to do so by law or in the good faith belief that such action is necessary to:
- Conform to the edicts of the law or comply with legal process served on ITRA or the Site.
- Protect and defend the rights or property of ITRA.
- Act in urgent circumstances to protect the personal safety of ITRA employees or agents, users of ITRA products or services, or members of the public.
Please be aware that we may use third party contractors to help provide services to you, such as processing payments, monitoring site activity, serving site content, organising information, conducting surveys and administering e-mails, drawings or contests. Outside contractors who have access to personal data are required to treat the personal information in a confidential manner.
DATA PROTECTION ACT
ITRA holds information on users and members in accordance with the provisions of the Data Protection Act 1998, and will adhere to any other relevant future legislation in this area. Under this legislation, account holders can obtain a copy of all information which ITRA has on its databases in relation to them. Account holders wishing to obtain such information should contact ITRA at<EMAIL_ADDRESS>ITRA reserves the right to charge a fee of €5 for providing copies of such information to you.
SECURITY OF YOUR PERSONAL INFORMATION
ITRA strictly protects the security of your personal information and honours your choices for its intended use. ITRA carefully protects your data from loss, misuse, unauthorised access or disclosure, alteration or destruction.
Customer also have a significant role in protecting their information. No unauthorised person can see or edit your personal information without knowing your log in details (username and password), so do not share these with others.
SITE SECURITY
ITRA has a committed security policy. ITRA will retain copies of the information provided when you register on the website, order any products / services from the site and enter into any competitions. ITRA implements a number of sophisticated security measures to ensure the safety of any personal information provided. The information is contained on a secure server, which is accessible only by a limited number of employees who have authorised access rights to such information.
All sensitive and credit / debit card information supplied by any customer in the process of payment is transmitted via Secure Socket Layer (SSL) technology. SSL is commonly-used for managing the security of message transmission on the Internet through public-and-private key encryption and a digital certificate that establishes your credentials when doing Internet business or other on-line transactions. This certificate is issued by a certification authority, in our case Thwate Security. To see the certificate for this site click here (NEED HYPERLINK TO SECURE CERT). When you are asked to enter any personal details or credit card information the web site will be secure. This is easily identifiable by an icon in the bottom of the browser window resembling an unbroken key or a closed lock. SSL ensures that the information being transmitted to ITRA is secure.
If your browser supports SSL, and if you entered our site via our secure server access, then transmission of any sensitive data will be protected. If your browser does not support SSL, we recommend that you upgrade to the latest version of any browser to enhance the security of further transactions, otherwise the transmission of your personal data may not be protected and ITRA disclaims any responsibility in this regard.
CHANGES TO THIS PRIVACY STATEMENT
As the Site expands, improves, and updates ITRA’s offerings and services, ITRA reserves the right to modify or amend the policy at any time and for any reason. When policy changes occur, ITRA will revise the "updated" date at the top of this privacy statement.
For material changes to this privacy statement, ITRA will notify you by placing a prominent news story on the website. ITRA encourages you to periodically review this privacy statement to stay informed about how the organization is helping to protect the personal information collected. Your continued use of the service constitutes your agreement to this privacy statement and updates to this statement.
Please be aware that this privacy statement, and any other choices you make on the Site, will not necessarily apply to personal information you may have provided to ITRA in the context of other, separately operated, ITRA products or services.
CONTACT INFORMATION
ITRA welcomes your comments regarding this privacy statement. If you believe that we have not adhered to this privacy statement, please contact us by e-mail at<EMAIL_ADDRESS>or by calling 01 2020100. ITRA will use commercially reasonable efforts to promptly determine and remedy the problem.


This intention appears in @CompileStatic annotated code and applies fixes for compilation errors introduced by that annotation. Fixes are applied for class or method containing selection and annotated with @CompileStatic.


Class: RuboCop::Cop::Performance::ChainArrayAllocation
| Relationships & Source Files | |
| Super Chains via Extension / Inclusion / Inheritance | |
|
Class Chain:
self,
Base
|
|
|
Instance Chain:
self,
RangeHelp,
Base
|
|
| Inherits: |
Base
|
| Defined in: | lib/rubocop/cop/performance/chain_array_allocation.rb |
Overview
Identifies usages of array.compact.flatten.map { |x| x.downcase }
.
Each of these methods (compact
, flatten
, map
) will generate a new intermediate array
that is promptly thrown away. Instead it is faster to mutate when we know it’s safe.
Constant Summary
-
ALWAYS_RETURNS_NEW_ARRAY =
# File 'lib/rubocop/cop/performance/chain_array_allocation.rb', line 37
These methods ALWAYS return a new array after they’re called it’s safe to mutate the resulting array
%i[* + - collect compact drop drop_while flatten map reject reverse rotate select shuffle sort take take_while transpose uniq values_at |].to_set.freeze
-
HAS_MUTATION_ALTERNATIVE =
# File 'lib/rubocop/cop/performance/chain_array_allocation.rb', line 45
These methods have a mutation alternative. For example :collect can be called as :collect!
%i[collect compact flatten map reject reverse rotate select shuffle sort uniq].to_set.freeze
-
MSG =
# File 'lib/rubocop/cop/performance/chain_array_allocation.rb', line 50'Use unchained `%<method>s` and `%<second_method>s!` ' \ '(followed by `return array` if required) instead of chaining ' \ '`%<method>s...%<second_method>s`.'
-
RETURNS_NEW_ARRAY =
# File 'lib/rubocop/cop/performance/chain_array_allocation.rb', line 48(ALWAYS_RETURNS_NEW_ARRAY + RETURNS_NEW_ARRAY_WHEN_NO_BLOCK).freeze
-
RETURNS_NEW_ARRAY_WHEN_NO_BLOCK =
# File 'lib/rubocop/cop/performance/chain_array_allocation.rb', line 33
These methods return a new array only when called without a block.
%i[zip product].to_set.freeze
-
RETURN_NEW_ARRAY_WHEN_ARGS =
# File 'lib/rubocop/cop/performance/chain_array_allocation.rb', line 30
These methods return a new array but only sometimes. They must be called with an argument. For example:
[1,2].first # => 1 [1,2].first(1) # => [1]
%i[first last pop sample shift].to_set.freeze
Instance Method Summary
Instance Method Details
#on_send(node)
[ GitHub ]# File 'lib/rubocop/cop/performance/chain_array_allocation.rb', line 62
def on_send(node) chain_array_allocation?(node) do |fm, sm| return if node.each_descendant(:send).any? { |descendant| descendant.method?(:lazy) } range = range_between(node.loc.dot.begin_pos, node.source_range.end_pos) add_offense(range, message: format(MSG, method: fm, second_method: sm)) end end


--- date: ' 2020-03-18T15:36:24 ' draft: false linktitle: Lab 2 menu: MES623Econ: parent: Lab Material weight: 2 title: Data Types, Functions, and Loops type: docs weight: 2 output: blogdown::html_page: toc: true ---
Vectors are one-dimensional and can be created in many ways. If you just want numbers from one to 10, create the object “vec” and use the colon “:” to indicate “to.” This will automatically create one-digit increments. If you want to control the increments, use the function seq(). The arguments are: from, to, and by.Which argument controls the increment?
vec = 1:10
vec
## [1] 1 2 3 4 5 6 7 8 9 10
vec_1 = seq(from=1,to=10,by=.5)
vec_1
## [1] 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0
## [16] 8.5 9.0 9.5 10.0
What if we wanted the same number multiple times? That’s easy–, we just use the rep() function. The basic arguments for this function are as follows: “x” (the object/number we are repeating),“times”“, and”each". What if we want to repeat the number 1, 10 times?
vec_2 = rep(x = 1,times = 10)
vec_2
## [1] 1 1 1 1 1 1 1 1 1 1
Say we want to combine multiple vectors together. We use the “c()” function.
vec_12 = c(vec_1,vec_2)
vec_12
## [1] 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0
## [16] 8.5 9.0 9.5 10.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0
# Alternatively
vec_12_alt = c(seq(from=1,to=10,by=.5),rep(1,10))
vec_12_alt
## [1] 1.0 1.5 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 6.0 6.5 7.0 7.5 8.0
## [16] 8.5 9.0 9.5 10.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0
Write the code to replicate the sequence 1:4 (by 1’s), 3 times.
## [1] 1 2 3 4 1 2 3 4 1 2 3 4
Want this to be ordered With three 1’s, three 2’s, etc.? Use the rep() function, the generic vector creation with a colon, and the argument “each = 3.” Note: We can also use these functions for character strings (ex: rep(“dog”, times = 4).
vec_4 = rep(1:4, each = 3)
vec_4
## [1] 1 1 1 2 2 2 3 3 3 4 4 4
You can also use basic mathematical operations on vectors but only if they are numeric and the same length. Uncomment the bad code to see the errors you may get.
vec
## [1] 1 2 3 4 5 6 7 8 9 10
vec_2
## [1] 1 1 1 1 1 1 1 1 1 1
vec_add = vec+vec_2
vec_add
## [1] 2 3 4 5 6 7 8 9 10 11
# This won't work ... why not?
# vec_bad = vec_2+vec_12
# vec_bad
# This won't work ... why not?
# vec_d = rep("dog", times = 4)
# vec_bad_1 = vec_d + vec_2
# vec_bad_1
ProTip: Since a vector has only one dimension to index it (determine what’s in a specific position), you only need square brackets. Ex: vec_add[6] will return the value 7.
Matrices are multi-dimensional. We can create a matrix and put anything we want into it by using the matrix() function and it’s basic arguments: data, nrow, and ncol. Let’s put 1’s in a 3 x 2 matrix.
mat_1 = matrix(data =1, nrow = 3, ncol = 2)
mat_1
## [,1] [,2]
## [1,] 1 1
## [2,] 1 1
## [3,] 1 1
Note: If you forget the “data =” in the function R will fill in your matrix with NAs. Try it for yourself.
We can add new info to our matrix, either by the columns using cbind() or by the row using rbind(). Here is an example of adding an additional row to our established matrix.
mat_new = rbind(mat_1,rep(2,2))
mat_new
## [,1] [,2]
## [1,] 1 1
## [2,] 1 1
## [3,] 1 1
## [4,] 2 2
We can find a specific entry in our matrix by indexing using square brackets, the row number, a comma, and then the column number. Let’s figure out what is in the 4rd row and the 2nd column.
You can apply mathematical operations accross whole matrices. Example: Let’s multiply each element by a scalar of 3.
three_mat = mat_new * 3
three_mat
## [,1] [,2]
## [1,] 3 3
## [2,] 3 3
## [3,] 3 3
## [4,] 6 6
Let’s kick it up a notch! What if we have two matrices that we want to multiply together? We can use the matrix operator " %*% ": Click the link to learn more about matrix alebra.
mat_2 = matrix(4,2,2)
mat_2
## [,1] [,2]
## [1,] 4 4
## [2,] 4 4
# remind us of what mat_1 was
mat_1
## [,1] [,2]
## [1,] 1 1
## [2,] 1 1
## [3,] 1 1
mat_12 = mat_1%*%mat_2
mat_12
## [,1] [,2]
## [1,] 8 8
## [2,] 8 8
## [3,] 8 8
# This won't work ... why not?
# three_mat%*%mat_1
Note: To multiply matrices make sure that the the number of columns in the 1st matrix equals the number of rows in the 2nd matrix. Use one of the functions we learned from last week to check the matrix dimension (hint, hint).
Other data types such as lists and arrays exist. list() can have more than one type of data (i.e., numerics and character strings). Arrays have a dimension of 3 but all layers have to have the same dimensions.
# Creating a List
pop_parms_list <- list("r" = 2.5, "dependent" = TRUE, "init.pop" = seq(0,1000,100))
pop_parms_list
## $r
## [1] 2.5
##
## $dependent
## [1] TRUE
##
## $init.pop
## [1] 0 100 200 300 400 500 600 700<PHONE_NUMBER>
# Creating an array
pop1 = matrix(1:6, nrow = 3 , ncol = 2) # matrix 1 to put in an array
pop2 = matrix(1:6, nrow = 3 , ncol = 2) # matrix 2 to put in an array
pops_array = array(c(pop1,pop2),dim = c(3,2,2)) # 3 rows, 2 columns, 2 entries
pops_array
## , , 1
##
## [,1] [,2]
## [1,] 1 4
## [2,] 2 5
## [3,] 3 6
##
## , , 2
##
## [,1] [,2]
## [1,] 1 4
## [2,] 2 5
## [3,] 3 6
Just like matrix(), header(), summary(), dim(), etc. are all functions, we can make our own functions. Why do we make functions?
1.There is no available function to do what you want to do.
2.Work smarter – not harder! You have a task that needs to be repeated, and you do not want to keep writing the same lines of code over and over again.
Functions must have a name and arguments, and they must return something. Arguments are the inputs you plan to use in your function. We often use the function return() to have our functions “print” out to the console or pass something on to another function. Example layout:
func.name = function(arg1,arg2)
{ # bracket to start function
# code to do something, here
return (something)
} # bracket to end function
Let’s do a simple matrix multiplication function.
math.func = function (matrix.name,scalar) # 2 arguments to do something with
{
new.matrix = matrix.name * scalar # code to do something with those arguments
return(new.matrix) # code to print something
}# end function
Let’s test it out! We need to create a matrix and then tell our function what the name of the matrix is and what value the scaler should be.
mat.use = matrix(3,4,5)
math.func(matrix.name = mat.use, scalar = 2)
## [,1] [,2] [,3] [,4] [,5]
## [1,] 6 6 6 6 6
## [2,] 6 6 6 6 6
## [3,] 6 6 6 6 6
## [4,] 6 6 6 6 6
Look! It returned our “new.matrix”
One day you may have a really complex function and you just want to make sure it works, without always putting in arguments to run it. Well you can set defaults for your arguments when you create your functions. Then to run it quickly all you need is func.name(), R will do the rest. Lets try it out with our previous function.
math.func = function (matrix.name = matrix(3,4,5) ,scalar = 1)
{ # 2 arguments to do something with ... notice I now have defaults in place
new.matrix = matrix.name * scalar # code to do something with those arguments
return(new.matrix) # code to print something
}
# Now we can just test to see if it works without putting in arguments,
# just by typing the function name and parentheses
math.func()
## [,1] [,2] [,3] [,4] [,5]
## [1,] 3 3 3 3 3
## [2,] 3 3 3 3 3
## [3,] 3 3 3 3 3
## [4,] 3 3 3 3 3
Let’s create our own function to determine the final grade for a student in this class. Make the default values so that the final grade is 100. Remember to test your function.
Things to think about:
What are the arguments/inputs?
What is the task we want to accomplish or calculation to be made using these arguments?
What do we expect our function to return?
There are various types of loops but “for” loops are most common. You use loops when you want to do something iteratively. For loops have the following structure:
for (i in 0:5) # a variable and range of values it will take ... "x" is not a good variable
{ # a bracket to start
#some cacluation or function to do something
} # a bracket to end the for loop
Here “i” sequentially becomes a number from 0 to 5 and is used in each iteration of the loop.
Let’s try a simple example where we want to add i to 5. Our output should consist of a list of values. We’ll use the print() function so we can see what the loop is doing.
for (i in 0:5)
{
x = i + 5 # Do something to i, iteratively
print(x) # see what happens if you take this out
# I like to print what I am doing inside of a loop ...
# uncomment the next line to see what it does
# cat(paste("i= ", i, "and i + 5 =", x,"\n"))
} # end for loop
## [1] 5
## [1] 6
## [1] 7
## [1] 8
## [1] 9
## [1] 10
Lets tell R to do something different in the loop if i = 3. We do this by using an “if” statement which can be interpreted as “if something is true, do this.” Because this is a logical statement, we must use logical operators in our if statment (i.e. “==”, “!=”). We can also use “else” to succinctly tell R how to continue but this is not always necessary.
for (i in 0:5)
{
x = i + 5
# but ...
if(i == 3) {x = "NULL"} # our new if statement
cat(paste("i= ", i, "and i + 5 =", x,"\n"))
} # end for loop
## i= 0 and i + 5 = 5
## i= 1 and i + 5 = 6
## i= 2 and i + 5 = 7
## i= 3 and i + 5 = NULL
## i= 4 and i + 5 = 9
## i= 5 and i + 5 = 10
# Alternatively
for (i in 0:5)
{
if(i == 3) {x = "NULL"} else {x = i + 5} # our new if else statement
cat(paste("i= ", i, "and i + 5 =", x,"\n"))
} # end for loop
## i= 0 and i + 5 = 5
## i= 1 and i + 5 = 6
## i= 2 and i + 5 = 7
## i= 3 and i + 5 = NULL
## i= 4 and i + 5 = 9
## i= 5 and i + 5 = 10
Sometimes we only want to go to a certain point in the loop and then tell R to break out of the loop. Let’s tell R to breakout of the loop when x = 7 using the command “break.”
for (i in 0:5)
{
x = i + 5 # Do something to i, iteratively
if(x > 7) {break} # Here is that "break" command
cat(paste("i= ", i, "and i + 5 =", x,"\n"))
} # end loop
## i= 0 and i + 5 = 5
## i= 1 and i + 5 = 6
## i= 2 and i + 5 = 7
Read in the csv file “StudentGrades”. Find the final grade for each student using our mygrades function and a loop. Hint: Some indexing will need to take place.Print out a statement detailing each student’s final class grade using a combination of the cat() and paste() functions. Here is an example output.
## Student 1 has a grade of 83
## Student 2 has a grade of 73
## Student 3 has a grade of 69.5
## Student 4 has a grade of 58
## Student 5 has a grade of 68
## Student 6 has a grade of 82.5
## Student 7 has a grade of 55
## Student 8 has a grade of 72


Manages the imageviewer and interactions on it.
More...
#include <CinImageView.h>
|
| void | onLoadImage (const QString &key, const QString &path) |
| | This slot gets called when a parameter is changed and a new image needs to be loaded. key is ignored for now, since we're only loading one artifact. More...
|
| |
|
|
| CinImageView (QWidget *parent) |
| |
|
void | setParameters (CinParamSet *paramset) |
| |
|
void | setHorizontalParameter (const QString &h) |
| |
|
void | setVerticalParameter (const QString &v) |
| |
|
const QString & | getHorizontalParameter () |
| |
|
const QString & | getVerticalParameter () |
| |
| bool | loadImage (const QString &path) |
| | Given a path to an image, this function loads the image. If the image was loaded previously, then it uses the image from cache. More...
|
| |
|
void | clear () |
| |
Manages the imageviewer and interactions on it.
This class contains everything it needs to show the right image given the current parameter values. It is also responsible for controlling the mouse drag event, which is another way of interacting and changing the images while exploring the database.
◆ loadImage()
| bool CinImageView::loadImage |
( |
const QString & |
path | ) |
|
Given a path to an image, this function loads the image. If the image was loaded previously, then it uses the image from cache.
◆ mouseMoveEvent()
| void CinImageView::mouseMoveEvent |
( |
QMouseEvent * |
e | ) |
|
|
protected |
Mouse move event handler. This controls the dragging event.
◆ mousePressEvent()
| void CinImageView::mousePressEvent |
( |
QMouseEvent * |
e | ) |
|
|
protected |
Mouse press event handler.
◆ mouseReleaseEvent()
| void CinImageView::mouseReleaseEvent |
( |
QMouseEvent * |
e | ) |
|
|
protected |
Mouse release event handler.
◆ onLoadImage
| void CinImageView::onLoadImage |
( |
const QString & |
key, |
|
|
const QString & |
path |
|
) |
| |
|
slot |
This slot gets called when a parameter is changed and a new image needs to be loaded. key is ignored for now, since we're only loading one artifact.
◆ wheelEvent()
| void CinImageView::wheelEvent |
( |
QWheelEvent * |
event | ) |
|
|
protected |
Mouse wheel event. Performs zooming in and out.
The documentation for this class was generated from the following files:


EBD - Easton Bible DIctionary
Zeruiah
ZERUIAH
"ZERUIAH "stricken of the Lord, David’s sister, and the mother of Abishai, Joab, and Asahel (
1 Chronicles 2:16
), who were the three leading heroes of David’s army, and being his nephews, they were admitted to the closest companionship with him.
"ZERUIAH "stricken of the Lord, David’s sister, and the mother of Abishai, Joab, and Asahel (1 Chronicles 2:16), who were the three leading heroes of David’s army, and being his nephews, they were admitted to the closest companionship with him.


cleandate is community of high quality people.Our users take care of their sexual health and are open to discuss about safe sex.
Join them and enjoy the most interesting clean people around you.
Veify your profile by uploading
your latest Test Result on Setting
Do You need a Test?
Order CleanDate Collection Kit


Mateusz Morawiecki insisted Netflix change maps featured in the programme which located death camps inside modern-day Poland’s borders.
He said they misrepresented Poland as being responsible for the camps when it was occupied by Germany during the Second World War.
Netflix has now said it will add text to the maps making clear it was the Nazis who built and operated the camps.
In a statement, Netflix said: “We are hugely proud of The Devil Next Door and stand by its filmmakers, their research and their work.
“In order to provide more information to our members about the important issues raised in this documentary and to avoid any misunderstanding, in the coming days we will be adding text to some of the maps featured in the series.
“This will make it clearer that the extermination and concentration camps in Poland were built and operated by the German Nazi regime who invaded the country and occupied it from 1939-1945.”

He died in Germany in 2012 while appealing against his conviction for war crimes.
Nazi Germany sparked the Second World War by invading Poland in 1939. Throughout the war it killed millions of people, many of them Jews, in concentration camps.
In his letter to Netflix CEO Reed Hastings, Mr Morawiecki said it was important to “honour the memory and preserve the truth about World War II and the Holocaust”.
He said “certain works” on Netflix were “hugely inaccurate” and “rewriting history”.


How To
Load Verbose with ASDF or Quicklisp.
(ql:quickload :verbose)
By default --if threading is available-- a new logging thread is already started and set up with a REPL-Faucet on the INFO level, that simply prints log messages from the INFO level and above to the standard output:
(v:info :test "Hello world!")
=> LOG: 2014-04-01 13:32:49 [INFO ] <TEST>: Hello world!
Each logging statement expects a category and a datum. The simplest case for a datum is a format string:
(v:info :test "2+2=~f" (+ 2 2))
=> LOG: 2014-04-01 13:33:20 [INFO ] <TEST>: 2+2=4.0
However, you can also pass in different objects, as well as extend the behaviour by adding methods to log
:
(v:info :test (make-condition 'error))
(v:info :test 'simple-error :format-control "Hey!")
(v:info :test #'bt:current-thread)
You can change the logging level of the REPL-Faucet easily. The available levels by default are :FATAL
:SEVERE
:ERROR
:WARN
:INFO
:DEBUG
:TRACE
.
(setf (v:repl-level) :DEBUG)
Using the category-tree-filter you can limit what kinds of categories are shown:
(v:add-repl-category :foo.bar.*)
(v:info :foo "Foo")
(v:info :foo.bar.stuff "Foo")
=> LOG: 2014-04-01 13:51:03 [INFO ] <FOO.BAR.STUFF>: Foo
Verbose also allows you to pass as many categories as you want. This permits to use the categories as a form of tag, rather than a hierarchy.
(v:info '(:system :server) "Starting up!")
=> LOG: 2014-04-01 13:51:52 [INFO ] <SYSTEM><SERVER>: Starting up!
Log message passing through the pipeline happens in a separate thread. If you create new pipe segments for your logging pipeline that need to access some form of shared variable, you can use share
, which is SETFable. One share
that is most likely of interest to everyone is saved under the symbol *standard-output*
. Setting this anew is useful if you start a new REPL session and need to redirect logging to it.
(setf (v:shared-instance '*standard-output*) *standard-output*)
Since this is a very frequent thing to do, especially when hooking into remote lisps, you can achieve the same as above by using output-here
.
On the other hand, you can also suppress output completely or of certain categories using with-muffled-logging
.
(v:with-muffled-logging (:test :something.or.other)
(v:info :test "A")
(v:info :something.else "B")
(v:info :something.or.other "C"))
=> LOG: 2015-03-03 17:36:41 [INFO ] <SOMETHING.ELSE>: B
The with-muffled-logging
macro rebinds the *muffled-categories*
by prepending the given categories. You can of course also set *muffled-categories*
directly to achieve a global muffling. If you don't pass anything to with-muffled-logging
or push T
onto *muffled-categories*
, all messages will be suppressed.
If you want to log to a file, you can either create your own custom file faucet, or use a preset one like the rotating-log-faucet:
(v:add-pipe (make-instance 'v:rotating-log-faucet :file #p"~/verbose.log" :interval (v:make-cron-interval "* * * * *")))
Which creates a faucet that logs to a file with "verbose.log" suffix in your home directory, rotating every minute as per the CRON interval. In case you want to filter the message to a certain level or category instead, you can precede it by a filter:
(v:add-pipe (make-instance 'piping:predicate-filter :predicate #'(lambda (message) (message-visible message :WARN)))
(make-instance 'v:rotating-log-faucet :file #p"~/verbose.log" :interval (v:make-cron-interval "* * * * *")))
Using the piping constructs you can create complex logging systems or even change the pipeline on the fly. When you do, be aware that since the message passing happens in a separate thread, you need to acquire access to the pipeline first before modifying it:
(v:with-controller-lock ()
(piping:pipeline v:*global-controller*))
See the documentation of for more information.