New Version Available: OWL 2 (Document Status Update, 12 November 2009)
The OWL Working Group has produced a W3C Recommendation for a new version of OWL which adds features to this 2004 version, while remaining compatible. Please see OWL 2 Document Overview for an introduction to OWL 2 and a guide to the OWL 2 document set.
Please refer to the errata for this document, which may include some normative corrections.
This normative version is a compound document. Non-normative versions consisting of a single HTML file are available in three sizes: medium, large, and extra large. The tests of this document are also available in these non-normative formats: Zip archive of approved tests, the test Web site.
See also translations.
Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document contains and presents test cases for the Web Ontology Language (OWL) approved by the Web Ontology Working Group. Many of the test cases illustrate the correct usage of the Web Ontology Language (OWL), and the formal meaning of its constructs. Other test cases illustrate the resolution of issues considered by the Working Group. Conformance for OWL documents and OWL document checkers is specified.
This document has been reviewed by W3C Members and other interested parties, and it has been endorsed by the Director as a W3C Recommendation. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
This is one of six parts of the W3C Recommendation for OWL, the Web Ontology Language. It has been developed by the Web Ontology Working Group as part of the W3C Semantic Web Activity (Activity Statement, Group Charter) for publication on 10 February 2004.
The design of OWL expressed in earlier versions of these documents has been widely reviewed and satisfies the Working Group's technical requirements. The Working Group has addressed all comments received, making changes as necessary. Changes to this document since the Proposed Recommendation version are detailed in the change log.
Comments are welcome at<EMAIL_ADDRESS>(archive) and general discussion of related technology is welcome at<EMAIL_ADDRESS>(archive).
A list of implementations is available.
The W3C maintains a list of any patent disclosures related to this work.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
owl:AllDifferent
owl:AnnotationProperty
owl:Class
owl:DatatypeProperty
owl:FunctionalProperty
owl:InverseFunctionalProperty
owl:Nothing
owl:Ontology
owl:Restriction
owl:SymmetricProperty
owl:Thing
owl:TransitiveProperty
owl:allValuesFrom
owl:backwardCompatibleWith
owl:cardinality
owl:complementOf
owl:differentFrom
owl:disjointWith
owl:distinctMembers
owl:equivalentClass
owl:equivalentProperty
owl:imports
owl:intersectionOf
owl:inverseOf
owl:maxCardinality
owl:oneOf
owl:sameAs
owl:someValuesFrom
owl:unionOf
As part of the definition of the Web Ontology Language (OWL) the Web Ontology Working Group provides a set of test cases. This document presents those test cases. They are intended to provide examples for, and clarification of, the normative definition of OWL found in [OWL Semantics and Abstract Syntax] to which this document is subsidiary.
This document is one component of the description of OWL, the Web Ontology Language, being produced by the W3C Web Ontology Working Group. The Document Roadmap section of the [OWL Overview] describes each of the different parts and how they fit together.
This document describes the various types of test used
and the format in which the tests
are presented.
Alternative formats of the test collection are provided.
These are intended to be suitable
for use by OWL developers in test harnesses,
possibly as part of a test driven development process,
such as Extreme Programming [XP].
The format of the Manifest
files
used as part of these alternative formats is described.
In the non-normative appendices, this document also describes the process for creation and approval of these tests.
Various conformance levels are defined in this document in terms of [OWL Semantics and Abstract Syntax].
However, the test cases do not constitute a conformance test suite for OWL, since they are silent on several important issues. This document cannot be considered a complete specification of OWL.
The tests illustrate issue resolutions, and illustrate the use and meaning of the terms in the OWL namespace.
There are other miscellaneous tests: some arising in the literature, and in preexisting systems; others intending to show the difficulty of complete implementations of OWL Full.
The deliverables included as part of the test cases are:
Note: Other files can be found under the top URL of the Web site which are not part of the deliverable.
Of the deliverables the only normative tests are those included in this document. All other deliverables are informative. Moreover, the recommendation document is informative except for the conformance statements, the test data (specified in RDF/XML [RDF Syntax]), and the supporting documentation.
The Web Ontology Working Group has seen adequate implementation experience of most of the tests in this document. Some, however, are particularly difficult to implement efficiently. These are labelled as extra credit tests. Such tests indicate the semantics of OWL, but may use features that are not sufficiently widely implemented to provide good interoperability.
A general case of extra credit tests is that all OWL Full nonentailments and consistency tests are extra credit tests. This is because typical OWL Full implementations prove entailments but cannot prove nonentailments.
Extra credit tests are labelled with "EC" within this document and with status EXTRACREDIT in the manifest files.
The name indicates that there is no expectation that any implementation will successfully run such tests and any that do gain extra credit.
Each test consists of one or more RDF/XML documents and a Manifest
file.
Tests of one document indicate some property of that document
when viewed as an OWL knowledge base.
Tests of two or more documents indicate a relationship between the two documents
when viewed as OWL knowledge bases.
The Manifest
file is named ManifestNNN.rdf
(The NNN
is replaced by the test number).
It contains metadata (in RDF) indicating the test type,
and describing the test.
The metadata also indicates the language levels appropriate for each test and each document in each test. For each RDF/XML document, one language level is indicated, being OWL Lite, OWL DL or OWL Full, as given by the syntactic rules in [OWL Semantics and Abstract Syntax]. For semantic tests, one or two language levels are indicated. If the language level OWL Full is indicated for a semantic test, then the test holds according to the RDF-Compatible Model-Theoretic Semantics in [OWL Semantics and Abstract Syntax]. If the language level OWL Lite or OWL DL is indicated for a semantic test, then the test holds according to the Direct Model-Theoretic Semantics in [OWL Semantics and Abstract Syntax]. If the language level OWL Lite is indicated for a semantic test, then the test only uses features within the OWL Lite sublanguage.
Some of the tests require that certain
datatypes are, or are not, supported in the
datatype map
[OWL Semantics and Abstract Syntax].
These are indicated with the test.
Other datatypes which are used in the test
are also indicated: the test applies whether or not these are supported in the
datatype map .
The datatypes
xsd:integer
, xsd:string
from [XML Schema Datatypes]
are not indicated, even when used or required, since they
must be supported.
These tests use one document.
It is named badNNN.rdf
.
This document includes a use of the OWL namespace with a local name
that is not defined by the OWL recommendation.
Note: These tests are intended to help migration from DAML+OIL [DAML+OIL], since the local names chosen are defined in the DAML+OIL namespace.
These tests use two documents.
One is named premisesNNN.rdf
,
the other is named conclusionsNNN.rdf
.
The conclusions
are
entailed by the premises
.
Such entailment is defined by the OWL semantics [OWL Semantics and Abstract Syntax],
(see also
OWL Full entailment).
These tests use two documents.
One is named premisesNNN.rdf
,
the other is named nonconclusionsNNN.rdf
.
The nonconclusions
are not
entailed
by the premises
.
Such entailment is defined by the OWL semantics [OWL Semantics and Abstract Syntax],
(see also
OWL Full entailment).
Exceptionally, test imports-002 includes a third document.
These tests use one document.
It is named conclusionsNNN.rdf
.
The conclusions
follow from the OWL semantics
[OWL Semantics and Abstract Syntax].
These tests are a special case of the entailment tests
in which the premises are empty.
These tests use one document.
It is named conclusionsNNN.rdf
.
These are a special case of true tests.
The conclusions
follow from the
OWL Full semantics
[OWL Semantics and Abstract Syntax].
The tests are intended to illustrate how
OWL Full can be used to describe its own properties and
classes.
These tests use one document.
It is named consistentNNN.rdf
.
The document is
consistent
as defined
by the OWL Semantics [OWL Semantics and Abstract Syntax],
(see also
OWL Full consistency).
These tests use one document.
It is named inconsistentNNN.rdf
.
The document is not
consistent
as defined
by the OWL semantics [OWL Semantics and Abstract Syntax],
(see also
OWL Full consistency).
These tests use more than two documents.
One is named premisesNNN.rdf
,
another is named conclusionsNNN.rdf
, the rest have names
like supportNNN-A.rdf
.
The support
documents are in the
imports closure of the
premises
document.
The conclusions
are
entailed
by the
imports closure
of the premises
.
Such entailment is defined by the OWL semantics [OWL Semantics and Abstract Syntax],
(see also
OWL Full entailment).
These tests use two documents.
One is named importsNNN.rdf
,
the other is named mainNNN.rdf
.
These
tests indicate the
interaction between owl:imports
and the sublanguage levels of the main
document.
An OWL Full document is any RDF/XML document [RDF Syntax].
An OWL DL document is an OWL Full document such that the imports closure [OWL Semantics and Abstract Syntax] of the corresponding RDF graph [RDF Concepts] is an OWL DL ontology in RDF graph form.
An OWL Lite document is an OWL Full document such that the imports closure [OWL Semantics and Abstract Syntax] of the corresponding RDF graph [RDF Concepts] is an OWL Lite ontology in RDF graph form.
An OWL Lite or OWL DL document D is OWL DL consistent with respect to a datatype map T if and only if there is some abstract OWL interpretation I with respect to T such that I satisfies an abstract ontology O corresponding to D, in which O has a separated vocabulary; (see [OWL Semantics and Abstract Syntax]).
An OWL Full document D is OWL Full consistent with respect to a datatype map T, if and only if there is some OWL Full interpretation I with respect to T such that I satisfies all the RDF graphs in some imports closed collection containing an RDF graph corresponding to D.
This section uses the words MUST, MUST NOT, SHOULD and MAY as in [RFC 2119].
An OWL
syntax checker
takes a document as input, and returns one word being one of Lite
,
DL
, Full
, Other
.
The return value MUST conform with the following:
In addition, an OWL Syntax Checker SHOULD report a warning if
the
RDF graph
[RDF Concepts]
corresponding to the document
uses any URI references
starting with the prefix http://www.w3.org/2002/07/owl#
except those found in the
[RDF Schema for OWL].
An OWL syntax checker SHOULD report network errors occurring during the computation of the imports closure.
An OWL consistency checker
takes a document as input, and returns one word being Consistent
,
Inconsistent
, or Unknown
.
An OWL consistency checker SHOULD report network errors occurring during the computation of the imports closure.
An OWL consistency checker MUST provide a means to determine the datatypes supported by its datatype map, [OWL Semantics and Abstract Syntax]; for example, by listing them in its supporting documentation.
An OWL consistency checker MUST provide a means to determine the model theory [OWL Semantics and Abstract Syntax], it uses (either the Direct Model-Theoretic Semantics or the RDF-Compatible Model-Theoretic Semantics); for example, in its supporting documentation.
An OWL
consistency checker MUST be sound:
it MUST
return Consistent
only when the
input document is consistent and Inconsistent
only when the input
document is not consistent, with respect to the datatype map of the checker.
If an input document uses datatypes that are not supported by the datatype map of an OWL consistency checker then it MAY report a warning.
An OWL consistency checker is
complete and terminating,
if, given sufficient (but
finite) resources (CPU cycles and memory)
and the absence of
network errors, it will always return
either Consistent
or Inconsistent
. It has
been shown that for OWL Lite and DL it is possible to construct a
complete and terminating consistency checker
(the languages are decidable),
and that
for OWL full it is not possible to construct a complete and terminating
consistency
checker (the language is undecidable,
[Practical Reasoning]).
The
datatype map of
an OWL consistency checker MUST minimally support at least
xsd:integer
, xsd:string
from [XML Schema Datatypes].
An OWL consistency checker SHOULD NOT return
Unknown
.
Unknown
, while sometimes needed, is not
a desired response.
Four different conformance classes of OWL consistency checker are defined.
An OWL Lite consistency checker is an OWL consistency checker that takes an OWL Lite document as input, and uses the Direct Model-Theoretic Semantics.
An OWL DL consistency checker is an OWL consistency checker that takes an OWL DL document as input and uses the Direct Model-Theoretic Semantics.
An OWL Full consistency checker is an OWL consistency checker that takes an OWL Full document as input and uses the RDF-Compatible Model-Theoretic Semantics.
The
datatype map of an
OWL Full consistency checker
MUST also support
rdf:XMLLiteral
from [RDF Concepts],
see [RDF Semantics].

Note: An OWL Full consistency checker may indicate that an OWL DL document is inconsistent, while an OWL DL consistency checker indicates that the same document is consistent, (for example: compare test Thing-005 with Thing-004 or compare AnnotationProperty-001 with AnnotationProperty-002). Every OWL DL consistency checker is also an OWL Lite consistency checker.
Note:
A
complete OWL Lite consistency checker
MAY return Unknown
for an OWL Lite document in the case where
a resource limit has been exceeded.
Note: The usage of the word 'complete' in this section follows the conventions of the description logic community. In some other communities the word 'complete' is used in a weaker sense, refering to the detection of inconsistency by logical inference systems.
An OWL syntax checker when presented with any of the test files must return the indicated result. This includes the extra credit tests.
An OWL consistency checker can be tested using appropriate consistency and inconsistency tests. Appropriate tests are those of an appropriate level and for which the checker has appropriate datatype support. The level of the test indicates the semantic theory being used, which may differ from the level of the file. For example, test Thing-004 contains an OWL DL file which is consistent as an OWL DL consistency test, but inconsistent as an OWL Full consistency test.
An OWL consistency checker has appropriate datatype support for a test if both:
An OWL Lite consistency checker
with
appropriate datatype support,
when presented with a file from
an OWL Lite consistency test,
must return Consistent
or Unknown
.
An OWL DL consistency checker
with
appropriate datatype support,
when presented with a file from
an OWL DL or OWL Lite consistency test,
must return Consistent
or Unknown
.
An OWL Full consistency checker
with
appropriate datatype support,
when presented with a file from
an OWL Full consistency test,
must return Consistent
or Unknown
.
The corresponding inconsistency tests must return
Inconsistent
or Unknown
.
A complete OWL Lite consistency checker
should not return Unknown
on the OWL Lite
consistency
or inconsistency tests, regardless of the use of
unsupported datatypes.
The above constraints also apply to
extra credit tests.
Consistency checkers that return the correct answer (i.e. not Unknown
)
gain the extra credit.
The Manifest
file follows the RDF schema developed
for the RDF Test Cases [RDF Tests].
This is augmented by a few new properties and types which are declared in the OWL Test Ontology, found at http://www.w3.org/2002/03owlt/testOntology.
Specifically each test has its own Manifest
file, and is identified from
the URI reference formed from the Manifest
file's URL with a fragment test
.
The test has one rdf:type
explicit, and this is one of:
otest:NotOwlFeatureTest
otest:PositiveEntailmentTest
otest:NegativeEntailmentTest
otest:TrueTest
otest:OWLforOWLTest
otest:ConsistencyTest
otest:InconsistencyTest
otest:ImportEntailmentTest
otest:ImportLevelTest
Where otest
is bound to
http://www.w3.org/2002/03owlt/testOntology#
and rtest
is bound to
http://www.w3.org/2000/10/rdf-tests/rdfcore/testSchema#
.
The name of the original author of the test is shown using a
dc:creator
property, see [Dublin Core].
A description of the test is given (using XHTML markup [XHTML])
as the value of the rtest:description
property.
An issue, if any, from the OWL Issues list [OWL Issues], is
the value of a rtest:issue
property.
An appropriate language feature, from the OWL namespace, if any, is
the value of the otest:feature
property.
The input documents with the test data are found as the value of
the rtest:inputDocument
property or
as the value of both the
rtest:premiseDocument
and
the
rtest:conclusionDocument
.
The support files for import entailment tests, import level tests
and test imports-002 are found
as the values of otest:importedPremiseDocument
.
The conformance levels associated with both files and tests
are given with the otest:level
property.
The value for each document is one of
otest:Full
, otest:DL
,
otest:Lite
or otest:Other
.
Each test is explicitly associated with one or two levels.
If it is associated with otest:Lite
then it
is implicitly suitable for otest:DL
.
The datatypes used in the test are given with the
otest:usedDatatype
property or with one of its subproperties:
otest:supportedDatatype
or otest:notSupportedDatatype
.
These
indicate that
the test is only valid when the datatype is supported or not supported respectively
by the
datatype map being used.
The rtest:status
of the test
reflects the process of
appendix A.
It
is given as one of the following levels:
Contents
owl:AllDifferent
owl:AnnotationProperty
owl:Class
owl:DatatypeProperty
owl:FunctionalProperty
owl:InverseFunctionalProperty
owl:Nothing
owl:Ontology
owl:Restriction
owl:SymmetricProperty
owl:Thing
owl:TransitiveProperty
owl:allValuesFrom
owl:backwardCompatibleWith
owl:cardinality
owl:complementOf
owl:differentFrom
owl:disjointWith
owl:distinctMembers
owl:equivalentClass
owl:equivalentProperty
owl:imports
owl:intersectionOf
owl:inverseOf
owl:maxCardinality
owl:oneOf
owl:sameAs
owl:someValuesFrom
owl:unionOf
Contents
These tests are ones that are either known from the literature (for instance, from [Heinsohn et al.]), or from test suites contributed by Network Inference, or developed by the Working Group.
The following additional namespace prefix is used in this section:
oiled
http://oiled.man.example.net/test#
In the N3 syntax [N3] used for namespace declarations, this as as follows:
| Namespaces: |
@prefix oiled: <http://oiled.man.example.net/test#> . |
Contents
Contents
Contents
Contents
These tests are ones that do not fit any other category. Some are taken from the [OWL Guide]; others reflect various aspects of OWL, that were not formal issues addressed by the Working Group.
Contents
Contents
There is no expectation that any implementation will successfully run the tests in this section; any that do gain extra credit.
The intent is to illustrate the semantics of OWL, particularly OWL Full, as specified by [OWL Semantics and Abstract Syntax], with the specific goal of showing that it is possible to say things that it is not reasonable to expect an implementation to completely understand.
Contents
This appendix describes the process that was used during the development of this test suite.
Tests are created by members of the Working Group. An (optional) test editor is provided to facilitate this. Tests are then placed in the appropriate directory in the test Web site. This is done using CVS access to the W3C CVS server [W3C CVS].
When created, tests are given a status of "PROPOSED"
.
The author of the test creates a Manifest file in the directory
of the new test, identifying:
"PROPOSED"
.At the chair's discretion, individual tests or groups of tests are put to the Working Group in the weekly telecon or at a face-to-face meeting.
Tests are approved by Working Group decision, with status 'APPROVED' or 'EXTRACREDIT'.
The Working Group may take account of favorable review of the tests and/or implementation reports, as well as other factors.
If the Working Group approves a test, then it is included in the test case document.
The Working Group may reject a test, in which case its status is
changed to "REJECTED"
. This does not indicate that the
converse of the test has been accepted. There may be stylistic
or other grounds for rejecting technically correct tests.
The Working Group has complete discretion to approve or reject tests independent of their conformance with this process or their conformance with the OWL Working Drafts.
In the light of new information, and at the chairs' discretion, the Working Group
may review any previous decision regarding any test cases. The status of
"OBSOLETED"
may be used where a test has ceased to be appropriate.
The editors may make editorial changes to approved and proposed tests. This includes:
There is a preference for the following stylistic rules. None of these rules is obligatory, but test authors should be minded that it will be easier to gain Working Group consensus if they follow these rules.
Tests should normally be expressed in RDF/XML.
The following RDF/XML grammar rules [RDF Syntax] are not used:
xml:base
Test and manifest files should have an xml:base
attribute
[XMLBASE]
on
the document element. This should show the preferred URL
of the document, from which it is actually retrievable.
Files that contain no relative URIs may omit the xml:base
attribute.
Test and manifest files should use the ".rdf"
suffix. URIs should not. The URL used for xml:base
declarations
does not have a suffix.
example
Domains
All URLs in the test and manifest files should be retrievable Web resources
except for those that use domain names with "example"
as the penultimate
component (e.g. "http://www.example.org/ontology#prop"
).
The following copyright statement should be included as an XML comment in every test file:
<!-- Copyright World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University). All Rights Reserved. Please see the full Copyright clause at <http://www.w3.org/Consortium/Legal/copyright-software.html> $Id: Overview.html,v 1.10 2009/11/13 14:31:49 bertails Exp $ -->
The description should:
The description should be included as an XML comment in each test file, and be included as RDF content in the Manifest file.
Tests that relate principally to some owl property or class, should be put in a directory named using the local name of that property of class.
Otherwise, tests that relate to an issue should be put in a directory
named like I3.4
where the issue number is taken from the OWL issue list
[OWL Issues].
Each directory should contain tests numbered consecutively from 001
.
No two tests in a single directory should have the same number.
Each file in a test should have the number of the test at the end of its name, before the suffix.
The rest of the file name should follow the conventions for the test type.
Note: the approved tests in a directory will not necessarily be contiguously numbered.
Note: this differs from the RDF Core test case numbering conventions.
Both the approved and proposed tests are shown both in RDF/XML, which is their normative form, and in a triples format. This lists the triples as subject, predicate and object, similar to the N-triples format described in [RDF Tests]. The following additional conventions are used:
http://www.w3.org/2002/03owlt/
.The following namespace prefixes are used throughout:
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs
http://www.w3.org/2000/01/rdf-schema#
owl
http://www.w3.org/2002/07/owl#
xsd
http://www.w3.org/2001/XMLSchema#
first
#
. The first file
is that named premisesNNN.rdf
, badNNN.rdf
, consistentNNN.rdf
, inconsistentNNN.rdf
or importsNNN.rdf
depending
on the
test type. (Not used for true tests or
OWL for OWL tests
).second
#
.
The second file is named conclusionsNNN.rdf
, nonconclusionsNNN.rdf
or mainNNN.rdf
depending
on the
test type. In the N3 syntax [N3] used for namespace declarations, the first four appear as follows:
| Namespaces: |
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . |
Other namespaces are explicitly listed with the test data.
Contents
Jeremy Carroll thanks Oreste Signore, his host at the W3C Office in Italy and Istituto di Scienza e Tecnologie dell'Informazione "Alessandro Faedo", part of the Consiglio Nazionale delle Ricerche, where Jeremy is a visiting researcher.
The following people have contributed tests to this document: Sean Bechhofer, Ian Horrocks, Peter F. Patel-Schneider, Jeff Heflin, Dan Connolly, the Guide editors, Jonathan Borden, Charles White, Martin Dürst, Masayasu Ishikawa, Jim Hendler, Herman ter Horst, Dave Reynolds, and the editors.
Ian Horrocks contributed to the conformance section of this document.
Sandro Hawke created the tests results page, that has been a great help during the Candidate Recommendation phase.
We thank those who gave test reports and other feedback during the Candidate Recommendation: Ken Baclawski, Sean Bechhofer, Ian Dickinson, Michael Grove, Sandro Hawke, Ian Horrocks, Minsu Jang, Gary Ng, Mehrdad Omidvari, Bijan Parsia, Peter F. Patel-Schneider, Dave Reynolds, Rob Shearer, Evren Sirin, Charles White and Youyong Zou. We also thank the many others who helped develop the systems which produced these reports.
This document is the result of extensive discussions within the Web Ontology Working Group as a whole. The partipants in this Working Group included: Yasser alSafadi, Jean-François Baget, James Barnette, Sean Bechhofer, Jonathan Borden, Stephen Buswell, Jeremy Carroll, Dan Connolly, Peter Crowther, Jonathan Dale, Jos De Roo, David De Roure, Mike Dean, Larry Eshelman, Jérôme Euzenat, Tim Finin, Nicholas Gibbins, Sandro Hawke, Patrick Hayes, Jeff Heflin, Ziv Hellman, James Hendler, Bernard Horan, Masahiro Hori, Ian Horrocks, Jane Hunter, Rüdiger Klein, Natasha Kravtsova, Ora Lassila, Deborah McGuinness, Enrico Motta, Leo Obrst, Mehrdad Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Noboru Shimizu, Michael K. Smith, John Stanton, Lynn Andrea Stein, Herman ter Horst, David Trastour, Frank van Harmelen, Bernard Vatant, Raphael Volz, Evan Wallace, Christopher Welty, Charles White, Frederik Brysse, Francesco Iannuzzelli, Massimo Marchiori, Michael Sintek and John Yanosy.
This section gives the changes between this document and the OWL Test Cases Proposed Recommendation.
The term datatype map is used instead of the term datatype theory, for consistency with the OWL and RDF Semantics. This occurred a number of times, including in the descriptions of tests miscellaneous-204, miscellaneous-205 and I5.8-012. The last of these consequentially required other minor rephrasing.
Updated references to RDF and OWL documents.
Added a paragraph near end of section 4.2.2, clarifying that a datatype map of an OWL Full consistency checker, (being a datatype map from RDF Semantics) "MUST" contain an entry for rdf:XMLLiteral. This makes explicit a requirement that was already implicit in the PR document. Also clarified that the datatype map in the definition of an OWL Full consistent document is as defined in RDF Semantics, by changing the link.
Consequentially, made explicit reference to RDF Semantics (this reference was implicit in the OWL Test Proposed Recommendation).
Corrected an error in the metadata of test miscellaneous-205 which is not applicable for OWL Full, since rdf:XMLLiteral is a required datatype for OWL Full. This change is visible as the deletion of the word "Full" from the header of the test.
This error in the OWL Test Candidate and Proposed Recommendation appears to have been relatively benign:
<EMAIL_ADDRESS>Found at
ftp://dimacs.rutgers.edu/pub/challenge/satisfiability/doc/satformat.tex
May 8, 1993.


text_here
----------------------------- A sample link using POST POST link text ----------------------------- A sample link using PUT PUT link text ----------------------------- A sample link using PATCH PATCH link text ----------------------------- A sample link using DELETE DELETE link text ----------------------------- A sample button using POST ----------------------------- A sample button using PUT ----------------------------- A sample button using PATCH ----------------------------- A sample button using DELETE ----------------------------- A proper one this time, with fields to be filled out. ----------------------------- A multipart form with an upload field. ----------------------------- A form with get method.


Results-oriented professional with a strong foundation in community building and operations expertise in digital marketing, community workshops, and team building. Prior professional experience includes web development, social media management, and programming principles. Creative, flexible, and can provide leadership, in addition to, working as a part of a team. Energized to perform at a high level and great interpersonal skills with the ability to form lasting relationships.
Activities: Alpha Sigma Phi: Fundraising Coordinator (06-07), Interfraternity Council Representative (06-07); OWU Firedogs Ultimate Frisbee Team: Treasurer (06-08); OWU Transcript Newspaper: Advertisement Sales Representative (07-08)
Originally from Ohio, I moved to Charlotte, NC in 2008 after graduation because I wanted to live in a place with sunshine more than 3 months in a year. In my free time, I spend almost all of it with my wife and 1yr old son where I take many home videos of us together.
I have a small Youtube channel where I create and edit “glorified versions” of those home movies. Having those memories recorded and stored in a place like Youtube makes it easy for my wife and me and our families to watch these special moments in our lives with our child.
Want to connect and learn more about me? Reach out! Feel free to contact via email, phone, or socials!


You will all be discussing The Worm In The Bud in your Hooting Yard Reading Groups, so here are some useful notes and guidelines for discussion.
Terms Used
Bud—In plants, a flower or leaf at any stage of growth until fully opened.
Sprig—A shoot, twig, or spray of a plant, shrub, or tree.
Worm—Any animal that creeps or crawls.
Babinsky—Lumbering, walrus-moustached, psychopathic serial killer.
Dog—A domesticated carnivorous mammal, Canis familiaris (or C. lupus familiaris), which typically has a long snout, an acute sense of smell, non-retractile claws, and a barking, howling, or whining voice, widely kept as a pet or for hunting, herding livestock, guarding, or other utilitarian purposes.
Copper—Slang term for plod.
Terms Not Used
Detective Captain Cargpan—Babinsky's Nemesis
Nemesis—An agent of retribution
Agent—When used in the term Special Agent denotes a rank similar to Detective Captain in certain police, copper, or plod hierarchies.
Questions And Guidelines For Discussion
Why do you think the narrator enters a copse rather than, say, a spinney?
Make a list of the kinds of plants likely to be found in a copse far from the nearest town.
The narrator tells us his hands are hairy. Are yours?
Give a detailed character sketch and potted biography of Zoltan.
Embroider a counterpane similar to the one across which the worm crawls.
Do you think Babinsky is (a) evil, or (b) sick? If and when he is eventually caught, do you think he should be (i) confined to a prison, (ii) confined to a lunatic asylum, (iii) hacked to pieces by an angry mob, or (iv) allowed to escape scot free to resume his catalogue of enormities?
Why do you think the narrator drinks Squelcho! rather than a nice piping hot cup of tea?
When he titled one of his angry Scottish novels How Late It Was, How Late, do you think angry Scotsman James Kelman was thinking about your own Hooting Yard Reading Group and its tendency to continue wittering on and on until the cows come home?


Block Party 2D — Version 1.1 — February 24, 2016
This is a JavaScript/SVG implementation of Three Pixel Heart's Block Party.
Drag and rotate the blocks to make a party.
Use the left and right arrow keys to rotate the most recently clicked block.


| Case No.
| User Inputs and Commands
| Expected Output
| Remarks
| Results
|
|
3
|
Click on 'New Course' button on the main navigation bar located at the top of the UI.
|
'New Course' Dialog opens, 'Course Abbreviation' and 'Course Number' field contains
placeholder 'i.e. CPE' and 'i.e. 101', respectively. 'Section,' 'Term,' and 'Year'
items also display. There are 'Save' and 'Cancel' buttons at the bottom right corner of the dialog.
|
Testing the dialog load and composition.
|
Pass
|
|
4
|
Click 'Save' with all fields empty.
|
Error message 'Course Abbreviation can not be empty' displays at the bottom.
|
Testing empty Course Abbreviation validation.
|
Pass
|
|
5
|
Click 'Save' with only the 'Course Abbreviation' validly filled out but all other fields empty.
|
Error message 'Course Number can not be empty' displays at the bottom.
|
Testing empty Course Number validation.
|
Pass
|
|
6
|
Click 'Save' with only the 'Course Abbreviation' and 'Course Abbreviation' validly filled out but all other fields empty.
|
Error message 'Year can not be empty' displays at the bottom.
|
Testing empty Year validation.
|
Pass
|
|
7
|
Click 'Save' with all fields validly filled out and selected except for the 'Year' (enter "!@#$" instead).
|
Error message 'Year must be a number' displays at the bottom.
|
Testing Year entry validation.
|
Pass
|
|
8
|
Click 'Save' with all fields validly filled out and selected except for the 'Course Number' (enter "!@#$" instead).
|
Error message 'Course Number must be a number' displays at the bottom.
|
Testing Course Number entry validation.
|
Pass
|
|
9
|
Click 'Save' with all fields validly filled out and selected.
|
No error message is displayed, and the dialog closes upon clicking on 'Save' button.
|
Testing adding a valid Course to the list of courses.
|
Pass
|
|
10
|
Refresh the browser (⌘R on Mac OS, F5 on Windows).
|
Course that has been added is now showing on the list of courses.
|
Testing update of list of courses.
|
Pass
|
|
11
|
Repeat step 3, and close the dialog using the 'x' button at the top right or the 'Cancel' button at the bottom right.
|
The dialog closes and no changes are made to the list of courses.
|
Testing closing and disposing the dialog.
|
Pass
|
| Case No.
| User Inputs and Commands
| Expected Output
| Remarks
| Results
|
|
3
|
Click on any one of the courses in the list.
|
Selected course opens, showing the main navigation bar with 'Course,' 'Student,' and 'Assignments' menus.
Course gradebook (spreadsheet) is displayed in the body of the page.
|
Testing a single course load and composition.
|
Pass
|
|
4
|
Click on 'Modify Course' menu item listed under 'Course' menu on the main navigation bar located at the top of the UI ('Course' -> 'Modify Course').
|
'Modify Course' Dialog opens, all fields and selectors display the information that correspond to the currently open course.
There are 'Save' and 'Cancel' buttons at the bottom right corner of the dialog.
|
Testing the dialog load and composition.
|
Pass
|
|
5
|
Clear all text fields by deleting the data loaded, and click 'Save'.
|
Error message 'Course Abbreviation can not be empty' displays at the bottom.
|
Testing empty Course Abbreviation validation.
|
Pass
|
|
6
|
Click 'Save' with only the 'Course Abbreviation' validly filled out but all other fields empty.
|
Error message 'Course Number can not be empty' displays at the bottom.
|
Testing empty Course Number validation.
|
Pass
|
|
7
|
Click 'Save' with only the 'Course Abbreviation' and 'Course Abbreviation' validly filled out but all other fields empty.
|
Error message 'Year can not be empty' displays at the bottom.
|
Testing empty Year validation.
|
Pass
|
|
8
|
Click 'Save' with all fields validly filled out and selected except for the 'Year' (enter "!@#$" instead).
|
Error message 'Year must be a number' displays at the bottom.
|
Testing Year entry validation.
|
Pass
|
|
9
|
Click 'Save' with all fields validly filled out and selected except for the 'Course Number' (enter "!@#$" instead).
|
Error message 'Course Number must be a number' displays at the bottom.
|
Testing Course Number entry validation.
|
Pass
|
|
10
|
Click 'Save' with all fields validly filled out and selected.
|
No error message is displayed, and the dialog closes upon clicking on 'Save' button.
|
Testing adding a valid Course to the list of courses.
|
Pass
|
|
11
|
Navigate to the main page either by using the browser's 'back' functionality, or
by clicking the Home icon on the main navigation bar. Then, refresh the browser (⌘R on Mac OS, F5 on Windows).
|
Course that has been modified is now showing on the list of courses with the new information as entered.
|
Testing update of list of courses.
|
Pass
|
|
12
|
Repeat step 3 and 4, and close the dialog using the 'x' button at the top right or the 'Cancel' button at the bottom right.
|
The dialog closes and no changes are made to the list of courses.
|
Testing closing and disposing the dialog.
|
Pass
|


{% include 'includes/head.html' %}
{% include 'includes/header.html' %}
{% block contents %} {% endblock %}
{% include 'includes/footer.html' %}


Introduction
Source: introduction.mdHafslunds digital design system (HDD) is a common framework to keep the design consistent with the brand across project. The classes and naming follows the BECM convention. You can find more information about this in the BECM.
For every used front-end framework a separate 'components' library should be created. Listed below are the already existing libraries. If you want to add your library to this list, please create a pull request.
| Framework | Version | Repo |
|---|---|---|
| Angular 5.x | Github | |
| Design document (Figma) |
There are multiple ways of using HDD:
- Cloning the git repository:
git clone git@github.com:hafslundnett/hdd-style.git
- Add it as an npm dependency:
yarn add @hafslundnett/hdd-style
- Import main.sass in your stylesheet:
@import '~@hafslundnett/hdd-style/main';
- Use the bundled and minified file:
dist/bundle.min.css
- Import main.sass in your stylesheet:
Do you wish to change, remove or add something? Please read our contribution guide and code of conduct. Check for related open issues, and if none exist please open a new one: Github Issues.
In order to get started you will need to have node
and npm
installed. You can get it at https://nodejs.org. When those are installed run:
yarn
yarn start
This will open the styleguide in your browser and refresh on changes.
Please read the changelog here to keep up to date with breaking changes released with new updates.
Layout Grid
Source: grid.mdWe provide two grids you can use. The first (.hdd-grid
) is meant for sites that support mobile + desktop, and the second (.hdd-grid-desktop
) is for websites that only support desktop. The grid uses a 12 or less point/column system that changes based on windows size. Rows have no inherit min or max height, as can be seen in the example.
Columns for .hdd-grid
(mobile and desktop)
- 4 for small-size (< Earth)
- 8 for mid-size (> Earth < Jupiter)
- 12 for big-size (> Jupiter)
Columns for .hdd-grid-desktop
(desktop)
- 8 for mid-size (< Jupiter)
- 12 for big-size (> Jupiter)
You should use grid-column and grid-row to position your elements on the grid. Remember to add new positions for the breakpoints. Elements will have a width based on the grid, but no height as rows have no default height.
Naming guidelines
Source: naming-guidelines.mdWe make use of the BECM naming guidelines. These guidelines define how class names are constructed and used.
🚧 The prefix of this project is:
hdd
Badge
Source: badge.mdBadges contain numeric values and indicate a number.
All the colors in the design system can be used on hdd-badge
. signal-red
is the default color. The colors are used with the class is-$color
. For example for primary:
.
Badges contain numeric values and indicate a number. Multiple colors can be used on hdd-badge
and hdd-badge-icon
. signal-red
is used as the default color.
✅ When to use:
Use badges to mark new, updated or removed content. Use badges with the item they represent, so it's clear which item is indicated.
⛔ When not to use:
Badges should not be used alone. Do not display information status in a badge and to visually mark UI objects.
hdd-badge
Cards
Source: cards.mdA card is composed of several elements (eg title, description, icon, illustration). Combined, these elements are related to a single theme or to a destination. A card does not have an active / selected state. Cards contain interactive content, like function or other action points. Since cards are the starting point for more detailed info, they should contain a limited number of actions.
✅ When to use:
Cards are used when you want to view content related to a theme. The text of the card is recommended to be kept at a maximum of 70 characters per line to improve the readability for the user. The content should be short and kept to a minimum. A header-icon in the top left corner can be used to improve the recognition of content. A card can also have an icon prompting the user to go to settings for this specific content.
⛔ When not to use:
A card should only encapsulate one type of content.
🖋 For designer:
Padding inside the card is recommended to have spacing-3. If there are multiple cards in a row, the cards should have the same height. The icon in the label should be inside a circle, aligned to the H1 element. The icon should clearly be connected to the title, and be relevant to content. If a card is clickable, this should be displayed with a light border, view more and an arrow.
hdd-card
hdd-card
hdd-card
hdd-card
hdd-card
:
| class | description |
|---|---|
is-full-height |
Sets the height of the given card to 100% |
hdd-card_title
:
| class | description |
|---|---|
is-center |
Sets the given content of card title centered |
hdd-card_subtitle
:
| class | description |
|---|---|
is-center |
Sets the given content of card subtitle centered |
hdd-card_actions
:
| class | description |
|---|---|
no-hover |
Disable the :hover state |
Divider
Source: divider.mdDivider to seperate content from each other. Apply the hdd-divider
class to a horizontal row

tag.
hdd-divider
hdd-divider
:
| class | description |
|---|---|
is-light |
Sets the divider in a light colored theme, light color is --hdd-color-grey-light |
Feedback message
Source: feedback-message.mdA feedback message convey information that is important or urgent.
✅ When to use:
Feedback message should be used to guide or inform the user of critical information. For an error the message should inform the user of what went wrong and why.
⛔ When not to use:
A feedback message should not be used unnecessarily
feedback-container
, is-info
, is-success
, is-warn
, is-error
Usage of icons in feedback messages should be kept to an absolute minimum, since they usually don't serve any purpose and may be considered as visual "noise".
feedback-container
:
| class | description |
|---|---|
is-info |
Sets the given feedback to the info state |
is-success |
Sets the given feedback to the success state |
is-warn |
Sets the given feedback to the warn state |
is-error |
Sets the given feedback to the error state |
Header
Source: header.mdThe header hdd-header
should be used on each page, at the top before any content. It should cover the entire with of the screen. The header may contain the logo, page/site title and the active user if any. There are two header user alternatives, one with, and one without a user image. Remove the user part if the site has no login. Clicking on the user image should open the hdd-user-menu
if possible.
✅ When to use:
When not using a component library.
⛔ When not to use:
The sign out button should only be used if the user menu can't be used.
Links
Source: links.mdLinks are for prompting a user action that will affect another part.
hdd-link
hdd-link
:
| class | description |
|---|---|
no-active |
Disable the :active state |
no-focus |
Disable the :focus state |
no-hover |
Disable the :hover state |
is-active |
Set the given link to it's active state |
is-focus |
Set the given link to it's focus state |
is-hovering |
Set the given link to it's hovering state |
Notification dot
Source: notification-dot.mdThe hdd-notification-dot
class adds a small red dot with a white border to the top right side of an icon to signalize notifications.
hdd-notification-dot
Table
Source: table.mdA table can consist out of data, buttons and icons. A table row can also have a small color bar at the beginning of the row, all color subclasses can be used.
hdd-table
hdd-table
hdd-table
:
| class | description |
|---|---|
has-shadow |
Add a light shadow to the table |
is-sticky-header |
Table header sticks when scrolling table |
is-striped |
Adds zebra-stripes to the table, needs to have
 and
 defined in table |
is-aligned-top |
Sets the vertical-align of all cells to top |
is-aligned-bottom |
Sets the vertical-align of all cells to bottom |
no-wrap |
Sets the white-space property of all th/td elements to nowrap |
no-row-padding |
Removes the extra left-padding on the first column in a table |
hdd-table tr
| hdd-table_row
:
| class | description |
|---|---|
is-stripe |
Mark the given row as a stripe |
is-selected |
Mark the given row as selected |
Tooltip
Source: tooltip.mdA tooltip can give context to a given icon/piece of text. Tooltips are usually hidden and become visible on hovering, focus or on touch.
Attach the hdd-tooltip
class to the element which the tooltip content should be relative to. Then within the attached element, add a
tag with the hdd-tooltip_content
class. Fill inn the content of the tooltip within the
tag. Examples and mutation classes are described below:
✅ When to use:
Tooltips can be used to provide the user with brief and useful information related to a feature as a hover over/mini popup
⛔ When not to use:
Tooltips should not contain necessary and critical information needed by the user to complete a task. Tooltips does not work on mobile devices as they use the hover class, which only works with a mouse.
hdd-tooltip
hdd-tooltip
:
| class | description |
|---|---|
is-light |
Tooltip with hdd-color-white background and standard font color |
hdd-tooltip_content
:
| class | description |
|---|---|
is-right |
Set to tooltip to appear on the right side of the element |
is-left |
Set to tooltip to appear on the left side of the element |
is-top |
Set to tooltip to appear on top of the element |
is-bottom |
Set to tooltip to appear on the bottom of the element. This is the default position for a tooltip with no direction class set to it |
Checkbox
Source: checkbox.mdA checkbox component lets a user select one or more options of a limited number of choices. Checkbox classes are assigned to the corresponding checkbox label.
hdd-form_checkbox
A toggle checkbox component lets a user toggle between true or false state.
The toggle checkbox slider class are assigned to the corresponding span beneath the checkbox input tag.
hdd-form_toggle
& hdd-form_toggle slider
hdd-form_checkbox
:
| class | description |
|---|---|
is-invalid |
Set the checkbox to it's invalid state |
is-checked |
Set the checkbox style to it's checked class |
Dropdown
Source: dropdown.md⚠ This is a low level building block, and should be automated in a component library, but can be used directly if you want full control.
The dropdown lets the user search for and choose between a set of options. The dropdown aligns to the bottom by default. Dropdown should be used if the user wants a recommended selection out of all the options (then this choice should be the default), or if the list of choices is longer than 5 (then placeholder text should be used). In a long dropdown list, it must be possible for the user to start typing to filter.
hdd-form_input
.hdd-dropdown
hdd-form_input
.hdd-dropdown
Only use is-aligned-top
when there are enough room from the top and not enough from the bottom.
hdd-dropdown_content
:
| class | description |
|---|---|
is-active |
Sets the given dropdown-content to it's active state |
is-aligned-bottom |
Sets the given dropdown-content to be aligned at the bottom of the input field |
is-aligned-top |
Sets the given dropdown-content to be aligned at the top of the input field |
hdd-dropdown_content_item
:
| class | description |
|---|---|
no-hover |
Disable the :hover state |
is-active |
Sets the given dropdown-item to it's active state |
Form fields
Source: form-fields.mdForm fields is a component used to wrap several HDD components, such as input fields, checkboxes, radio and select. Form elements should be wrapped within a hdd-form_field
, along with a descriptive hdd-form_field_label
, or hdd-form_field_title
for checkboxes and radio buttons.
hdd-form_field
hdd-form_field
:
| class | description | |
|---|---|---|
hdd-form_field_label |
Set style for a form field label | |
hdd-form_field_title |
Set style for title above the form field | |
hdd-form_field_error |
Set style for an error message below the input field | |
hdd-form_field_info |
Set style for an info message below the input field | |
is-line |
Sets the form field to display: block , default display for all form-fields |
|
is-inline |
Sets the form field to display: inline-block |
|
is-active |
Activates the form fields error and info blocks |
Input fields
Source: input-fields.mdAn input should encourage action by the user. If the text / content cannot be changed, it should not appear in an input field of any kind (displayed as static text). For text-areas min-height is set to standard input-field height. The height is adjustable for the user, while the width is not.
Input fields should always be placed within a hdd-form_field
, along with a descriptive hdd-form_field_label
.
✅ When to use:
An input should have a descriptive prompt and contain: container, label, placeholder/input text, error text/helper. An textarea should be used if a longer text is needed.
⛔ When not to use:
An input should not stand alone without a label or information about what is requested. An textarea should not be used if there no need for a longer text.
hdd-form_input
hdd-form_input
:
| class | description |
|---|---|
is-focus |
Set the input field to its active state |
is-disabled |
Set the input field to its disabled state |
is-invalid |
Set the input field to its invalid state |
Search fields
Source: searchfields.mdSearch box allows the user to locate content quickly and efficiently and can be seen as a conversation between the user and the web page.
✅ When to use:
It is important to set the user context for the search with the correct placeholder text.
hdd-form_input
Select
Source: select.mdA select component lets a user choose between a set of options.
hdd-form_select
hdd-form-select
:
| class | description |
|---|---|
is-disabled |
Set the select to it's invalid state |
is-invalid |
Set the select to it's invalid state |
Colors
Source: using-colors.mdHafslund Nett has its own distinct groups of colors. All colors that are being used in this project are defined in the colors map. Every color can be used directly by using the css-variable for a color: var(--hdd-color-$name)
. For example for primary: color: var(--hdd-color-primary)
.
The css-variables can be accessed anywhere when importing hdd into your application. All colors, as well as their contrast color is available for use. A color can be selected by it's color name or label.
var(--hdd-color-$name)
var(--hdd-color-contrast-$name)
.hdd-element {
background: var(--hdd-color-primary); // using the primary color, blue
color: var(--hdd-color-contrast-primary); // using the contrast color of primary
}
Colors preview
Source: colors.mdHafslund Nett has two different palettes of colors, primary colors and support colors, and they should be used in all communication to create identity. In this section all the available colors with their corresponding contrast-color is visualized.
The primary color is blue and work as an important element for building the identity of Hafslund Nett. Blue symbolize credibility and stability. The associated shades of blue provide contrast, flexibility and airiness. This limited color scheme provides visual continuity throughout the user interface. When using estimates, pay particular attention to creating contrasts that are approved in WCAG.
--hdd-color-blue
--hdd-color-contrast-blue
--hdd-color-blue-dark
--hdd-color-contrast-blue-dark
--hdd-color-blue-light1
--hdd-color-contrast-blue-light1
--hdd-color-blue-light2
--hdd-color-contrast-blue-light2
--hdd-color-blue-light3
--hdd-color-contrast-blue-light3
--hdd-color-blue-light4
--hdd-color-contrast-blue-light4
Support colors are all colors which are not considered primary colors. These colors include greys, signaling colors, data visualization colors, and shadows.
Grayscale
The grayscale should be used in addition to the primary colors of non-printable items. The darkest gray is text color and should be used on all titles, paragraphs, and content. If text appears on a dark surface, contrast requirements must be maintained and white text must be used (#FFFFFF).
--hdd-color-black
--hdd-color-contrast-black
--hdd-color-font-color
--hdd-color-contrast-font-color
--hdd-color-grey-dark
--hdd-color-contrast-grey-dark
--hdd-color-grey-medium
--hdd-color-contrast-grey-medium
--hdd-color-grey
--hdd-color-contrast-grey
--hdd-color-grey-border
--hdd-color-contrast-grey-border
--hdd-color-grey-light
--hdd-color-contrast-grey-light
--hdd-color-grey-background
--hdd-color-contrast-grey-background
--hdd-color-white
--hdd-color-contrast-white
Signal colors
Signal colors should only be used in meaningful (never being identity-bearing or the only color appearing on a screen) situations and should only mean one thing per platform.
--hdd-color-signal-green
--hdd-color-contrast-signal-green
--hdd-color-signal-yellow
--hdd-color-contrast-signal-yellow
--hdd-color-signal-red
--hdd-color-contrast-signal-red
Data visualization
These colors are chosen to be used for infographics. If necessary, these colors can also be used in varying degrees of opacity (eg heat maps).
--hdd-color-data-navy
--hdd-color-contrast-data-navy
--hdd-color-data-marine
--hdd-color-contrast-data-marine
--hdd-color-data-blue
--hdd-color-contrast-data-blue
--hdd-color-data-turquoise
--hdd-color-contrast-data-turquoise
--hdd-color-data-seagreen
--hdd-color-contrast-data-seagreen
--hdd-color-data-green
--hdd-color-contrast-data-green
--hdd-color-data-orange
--hdd-color-contrast-data-orange
--hdd-color-data-yellow
--hdd-color-contrast-data-yellow
Shadows
Source: using-shadow.mdHDD contain 3 different types of shadows, that goes from light to strong. Every shadow can be used directly by using the css-variable for that shadow: var(--hdd-shadow-$name)
. For example for the light shadow: box-shadow: var(--hdd-shadow-light)
.
The css-variables can be accessed anywhere when importing hdd into your application. All shadows are available for use. A shadow can be selected by it's name.
var(--hdd-shadow-light)
var(--hdd-shadow-medium)
var(--hdd-shadow-strong)
.hdd-element {
box-shadow: var(--hdd-shadow-light); // using the light shadow
box-shadow: var(--hdd-shadow-medium); // using the medium shadow
box-shadow: var(--hdd-shadow-strong); // using the strong shadow
}
Setting the shadow attribute directly on elements are also possible with the following classes. All shadows can be used.
hdd-shadow-light
hdd-shadow-medium
hdd-shadow-strong
Accessibility
Source: a11y.mdSometimes there is a need to hide content on a page for various reasons. It is important that it still conveys the correct meaning to people who use screen readers. We should follow these principles regarding the situation to keep everything accessible, whether you are visually impaired or not:
Hide from everyone
Use the hidden
attribute to hide content from everyone.
Hide from screen readers
Use the attribute aria-hidden="true"
to hide content from screen readers. It will still appear visually on the page.
Hide visually only
Use the class .is-visually-hidden
to hide content visually only. This will still be read by screen readers.
Breakpoints
Source: breakpoints.mdThe breakpoints uses the names of the planets in the solar system. This is done on purpose as opposed to names like "phone" and "desktop". This is due to the changing nature of screen sizes and we don't want to have a strong link between our sizes and real devices.
@import "~@hafslundnett/hdd-style/utilities/breakpoints";
We are using a mobile first philosophy which means you first create the styling for the smallest supported screen size. Then you add breakpoints for larger screens (a given size and up) where further changes are specified.
.element {
// less than 576px (Venus)
background: blue;
// 576px and up
@include breakpoint-up(Venus) {
background: red; // will overwrite default color
}
// 768px and up
@include breakpoint-up(Earth) {
background: green; // will overwrite Venus color
}
}
- Venus 576px
- Earth 768px
- Mars 1024px
- Jupiter 1200px
- Saturn 1440px
- Uranus 1920px
The first and last planet is not used and reserved for future use.
Icons
Source: icons.mdHDD-style uses Font Awesome icon library, and is implemented with the
tags, along with the corresponding class for an icon, see the examples for some of the icons that are available. A full list of all of Font Awesome icons can be found here: https://fontawesome.com/icons?d=gallery
Icons are visual symbols used to represent ideas, objects or actions. They convey messages at a glance, provide interactivity and draw attention to important information. The icons are recommended to be designed for between 20 and 24 dp to make the pixel perfect. See Google's Material Icon for details. Icons are usually placed to the left of the text, but can also be placed above and to the right if the special use case fits it.
✅ When to use:
Icons can be used in several contexts. In input fields they are used both to visually show what the user fills in and to show status (pass / fail). They should follow set spacing values.
⛔ When not to use:
Icons should not be larger than 48px. It should also be avoided to have icons less than 8px. Also, icons should not be used alone in menus without text, as it may be difficult for the user to know what the icon should represent.
Spacing
Source: spacing.mdSpatial system that follows multiplication of 0.5rem (1rem = 16px). This provides predictability and is visually more comfortable to look at. Every spacing can be used directly on margins and paddings by using the css-variable for a spacing: var(--hdd-spacing-$name)
. For example for primary: padding: var(--hdd-spacing-primary)
- 0.5rem (8px):
--hdd-spacing-1
/--hdd-spacing-primary
- 1.0rem (16px):
--hdd-spacing-2
- 1.5rem (24px):
--hdd-spacing-3
- 2.0rem (32px):
--hdd-spacing-4
- 2.5rem (40px):
--hdd-spacing-5
- 3.0rem (48px):
--hdd-spacing-6
- 3.5rem (56px):
--hdd-spacing-7
- 4.0rem (64px):
--hdd-spacing-8
Standard spacing should be used when possible to standardized the separation between elements, as seen in the example below. Exceptions from this should be pre-approved by designer.
Typeface
Source: typography.mdThe typeface should be kept consistent in all mediums, physical and digital. The typography of Hdd is based on the rem unit. The body is set to the browsers default font size. All typography blocks are defined in the $typography variable found in the typography variables file.
Roboto is default font for all text. These tags are automatically styled: h1, h2, h3 and p.


Do you like Sinatra, but find it a little heavy? Bloated with things like simple error handling and CSRF protection; sick of the impedence mismatch of using one language on the server and another on the client; it’s not even asynchronous?!
Berliner is the framework for you! In just 16 lines of delicious CoffeeScript, it gives you all this, using the infinitely scalable horse power of Node.js:
GET
, POST
, PUT
,
DELETE
, PATCH
, HEAD
, and
OPTIONS
:named
and
*
matchers$ npm install berliner
app = require 'berliner' app.get '/', -> 'Hello, world!' app.run 4567
app.public = __dirname + '/public' # where to find static files app.views = __dirname + '/views' # where to find view templates app.session_secret = 'abcde12345' # key for encrypting sessions
app.get '/confs/:name', -> JSON.stringify @params app.put '/confs/:name', (name) -> name app.get '/download/*.*', -> @params.splat.join ', ' app.post '/confs', -> @status 201 @headers 'Content-Type': 'application/json' JSON.stringify @params app.get '/legacy', -> @redirect '/hello' app.options '/', -> @headers 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Methods': 'GET, PUT, DELETE' @render ''
This app responds like so:
$ curl 'localhost:4567/confs/eurucamp?bears=awesome' {"name":"eurucamp","bears":"awesome"} $ curl -X PUT localhost:4567/confs/jsconf jsconf $ curl localhost:4567/download/foo.js foo, js $ curl -iX POST localhost:4567/confs -d 'horses=fake' HTTP/1.1 201 Created Content-Type: application/json Content-Length: 17 Set-Cookie: session=XABfKjq2xvCavSitaxu0BC9XSl...; Path=/; HttpOnly Connection: keep-alive {"horses":"fake"} $ curl -i localhost:4567/legacy HTTP/1.1 303 See Other Location: /hello Connection: keep-alive Transfer-Encoding: chunked $ curl -iX OPTIONS localhost:4567/ HTTP/1.1 200 OK Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, PUT, DELETE Connection: keep-alive
app.websocket '/ws/:name', -> @socket.onmessage = (e)=> @socket.send @params.name + ': ' + e.data app.eventsource '/ws/:name', -> setInterval (=> @socket.send @params.name + ': PUSH!'), 5000
app.get '/counter', -> @session.counter ||= 0 @session.counter += 1 @render @session.counter.toString()
app.get '/', -> @cookie my_cookie: 'hello' @cookie another_cookie: {value: 'something', path: '/welcome', expires: new Date(2012,11,25), http: true} app.get '/welcome', -> @render @cookies.my_cookie
app.views = __dirname + '/views' app.helpers site_name: -> 'Awesome.net' app.get '/hello', -> @ejs 'hello', locals: {name: @params.name}
# views/hello.ejs Hello <%= name %>, welcome to <%= site_name() %>!
You can use @ejs
or @haml
to render a template.
@render
just takes a string and writes it to the response
body. If your route handler returns a string, that string will be the
body. Otherwise, you must call a rendering function.
$ curl 'localhost:4567/hello?name=_why' Hello _why, welcome to Awesome.net!
You can also register templates in the app code itself:
app.template 'hello.ejs', """ Hello <%= name %>, welcome to <%= site_name() %>! """
You can set up a set of routes with a common prefix and add before-filters that only apply to that context.
app.get '/', -> 'Hello!' app.context '/auth', (auth) -> auth.before (next) -> if @request.headers.authorization next() else @status 401 @render 'Authorization required' auth.get '/', -> 'Secret'
$ curl localhost:4567/ Hello! $ curl localhost:4567/auth Authorization required $ curl localhost:4567/auth -H 'Authorization: foo' Secret
Created by James Coglan at Eurucamp 2012, inspired by Konstantin Haase. Released under the MIT license.
If you find bugs, you’re probably holding it wrong.


About Me
I'm Amelia! I'm a Content Specialist at Pluralsight and I love web development, canoeing, and hiking.
Skills
Here's what I already know:
- HTML & CSS
- JavaScript
- jQuery
- Java
Contact
You can reach me on Twitter @amelianaire27, on GitHub @amelianaire27 or shoot me an email.


Magister Gaius:
So that is how the research document of the Giants fell into Beleth's clutches!
All our efforts were in vain...
Kaiena must have been distracted indeed by other matters not to have sent word of this to me.
Gauen must pay for this betrayal!


{% extends "mails/base_mail.html" %} {% block content %}
Congrats {{user.first_name}},
You’ve just participated in: {{document.title}} It is stored in your learning porfolio


Provides functions to access NASA's Earth Imagery and Assets API and the Earth Observatory Natural Event Tracker (EONET) webservice.
| Version: | 0.9.0 |
| Imports: | plyr, dplyr, png, jsonlite |
| Published: | 2016-05-07 |
| Author: | Eduardo Flores |
| Maintainer: | Eduardo Flores <eduardo at enelmargen.org> |
| License: | CC0 |
| NeedsCompilation: | no |
| CRAN checks: | nasadata results |
| Reference manual: | nasadata.pdf |
| Package source: | nasadata_0.9.0.tar.gz |
| Windows binaries: | r-devel: nasadata_0.9.0.zip, r-release: nasadata_0.9.0.zip, r-oldrel: nasadata_0.9.0.zip |
| OS X binaries: | r-release: nasadata_0.9.0.tgz, r-oldrel: nasadata_0.9.0.tgz |
Please use the canonical form https://CRAN.R-project.org/package=nasadata to link to this page.


CROOKLYN A Film Review by James Berardinelli Copyright 1994 James Berardinelli
Rating (0 to 10): 7.0
Date Released: 5/13/94 Running Length: 1:55 Rated: PG-13 (Language, mature themes)
Starring: Alfre Woodard, Delroy Lindo, Zelda Harris, Carlton Williams, David Patrick Kelly Director: Spike Lee Producer: Spike Lee Screenplay: Joie Susannah Lee, Cinque Lee, and Spike Lee Music: Terence Blanchard Released by Universal Pictures
From MALCOLM X to CROOKLYN, Spike Lee has moved from heavy, epic drama to something significantly more lighthearted. As with his previous film, this one places us into a time capsule, although the destination is much closer to the present. Instead of drifting back to the first half of this century, we're only going to 1973, a year when afros and bellbottoms were in fashion; when the Knicks won the basketball championship; and when there were enough pop tunes to fill a soundtrack.
Told from the point-of-view of 10-year old Troy Carmichael (Zelda Harris), CROOKLYN is the story of how one family struggles to survive and stay together. With Troy's musician dad Woody (Delroy Lindo) busy in the basement composing, the full burden of running the family - and bringing home the money - falls on Troy's mom, Carolyn (Alfre Woodard). This inevitably leads to tension between the two adults, and when one particularly nasty fight explodes, Woody is out the door.
Producer/director Spike Lee has woven a wonderfully rich drama that has one major stumbling block. Two-thirds of the way through the movie, Troy goes south to visit a hyper-religious aunt. To emphasize how distorted the little girl's perception of this vacation is, Lee shoots this portion of the movie with an anamorphic lens, causing everything to seem elongated. While that's fine for short sequences, in this case it goes on for too long, becoming an annoying trick that nearly undermines the entire film.
Aside from this twenty-minute detour, there aren't many flaws in CROOKLYN. All but the most comic of urban violence has been removed, and we're left with a somewhat-idealized view of an early-70s Brooklyn. Lee is as talented as any director is capturing a time, and some of the early scenes perfectly recall the mood of the era. The pop soundtrack may be a little too obvious, but it gets the job done.
As usual, Lee has assembled an excellent cast. Alfre Woodard and Delroy Lindo do tremendous jobs. David Patrick Kelly (who is also currently featured in THE CROW) provides a little comic relief as the white next-door neighbor who annoys just about everyone. Then there's Zelda Harris, whose fine, unaffected performance is the glue that holds the picture together.
CROOKLYN comes to the screen with an upbeat tone and a lot of heart. The world of a child - especially one pushed all-too-soon into adulthood - is never easy, and this film captures the facets of Troy's odyssey. If Lee errs with his "Southern vacation" scenes, he recovers to create an ending that is both touching and hopeful. Beneath the surface of this deceptively simple motion picture lurks a singularly keen insight.
- James Berardinelli<EMAIL_ADDRESS>.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Lawsuit: Mental care isn’t great for Louisiana Medicaid kids
BATON ROUGE, La. (AP) - The Southern Poverty Law Center is suing the Louisiana Department of Health, accusing the state of failing to provide children on Medicaid with adequate mental health services.
News outlets report SPLC filed the lawsuit Thursday on behalf of five children, representing 47,500 children in the state who need mental health services.
The lawsuit says children on Medicaid in Louisiana have few options when they experience a mental health crisis. Instead of ready access to nearby mental health professionals and clinics, families often have to turn to law enforcement as their only option, particularly in rural areas. That could put children through the juvenile justice system or into psychiatric institutions far from home.
The department declined to comment.
SPLC sued Mississippi in 2010 on similar grounds. That case is still processing.
Sign up for Daily Newsletters
Copyright © 2019 The Washington Times, LLC.
Please read our comment policy before commenting.


- Name Of The Event
- Browising Bad
- Instructions
-
- You will be given 3 hours to complete the event. This Event consists of 25 levels.
- There will be questions as well as games in which two teams will go against each other.
- There will be some levels where the two teams need to co-operate with each other to increase their scores.
- Each Level will have its own marks and deductions as well as set of instructions which will be given to you on the specific level.
- Your team might not be able to complete all levels by the end of the time, but your score when the time runs out will be considered as your final score.
- Some levels might require special information. So a long pdf file will be present on your computer, if you wish to refer it during the game.
Click Here To Sign Up!
Click Here To Login!


| Vendor Name | The AIM Group Inc. |
|---|---|
| Reference Number | 7091846 |
| Contract Date | 2015-07-30 |
| Description of Work | 0813 - Temporary help services |
| Contract Period | 2015-07-30 to 2016-07-15 |
| Contract Value | $152,287.28 |
| Comments | PSPC procurement tool./Competitively sourced. |
| Additional Comments | Temporary help services to support data validation |


Derek Eder
@derekeder
RT @chihacknight: Next, week: Computer Science For All, A Love Story With Data - a presentation by 4 CPS students https://chihacknight.org/events/2016/12/06/computer-science-for-all.html
12/2/2016, 9:34:12 AM
Favs: 0
Retweets: 0
link


First, use the tone generator to identify the frequency of your tinnitus. Try to find a tone that matches as close as possible and then switch to treatment mode. You will hear sets of 12 tones followed by short silences; both the tones and the silences are important parts of the treatment. The tones should be evenly distributed above and below your tinnitus' frequency.
This page automatically stores your settings on your computer.
Selected frequency: 440Hz


Canopy Growth shares get lift after Constellation executive named new CEO
by The Canadian PressSMITH FALLS, ONT. --
Shares of Canopy Growth Corp. got a lift after the cannabis producer named a veteran Constellation Brands executive as its new chief executive.
Canopy shares gained $3.33 or 13.5 per cent at $28.05 in late morning trading on the Toronto Stock Exchange.
David Klein, the chief financial officer at Canopy's largest shareholder, will replace Mark Zekulin, effective Jan. 14, 2020.
Klein has been serving as chairman of the board at Canopy, which intends to appoint a new chairman once he takes over as CEO.
Zekulin is a founding employee at Canopy and has served in a variety of roles including president, co-CEO and finally as CEO after co-founder Bruce Linton was ousted earlier this year.
Linton's departure came after Constellation said in June that it was "not pleased" with the company's financial results.
Zekulin is expected to step down as CEO and resign his seat on the board of directors of Canopy effective Dec. 20.
This report by The Canadian Press was first published Dec. 9, 2019


Sportsnet apologizes for Don Cherry’s anti-immigrant comments
Outrage was building online on Sunday with many on Twitter calling for Cherry to be fired
by The Canadian PressSportsnet has apologized for hockey commentator Don Cherry’s remarks about what he believes are new immigrants not wearing poppies ahead of Remembrance Day.
“Don’s discriminatory comments are offensive and they do not represent our values and what we stand for as a network,” Sportsnet President Bart Yabsley said in a statement Sunday.
“We have spoken with Don about the severity of this issue and we sincerely apologize for these divisive remarks.”
Cherry seemingly singled out new immigrants in Toronto and Mississauga, Ont., where he lives, for not honouring Canada’s veterans and dead soldiers.
“You people … you love our way of life, you love our milk and honey, at least you can pay a couple bucks for a poppy or something like that,” Cherry said.

Cherry did not immediately respond to a request for comment.
Mississauga, Ont., Mayor Bonnie Crombie was quick to respond and called his comments “despicable.”
“We’re proud of diverse cultural heritage and we’ll always stand up for it,” she said on Twitter. ”New immigrants enrich our country for the better. We’re all Canadians and wear our poppies proudly.”
Former Liberal MP and previous Ontario Premier Bob Rae also weighed in.
“Cherry’s remarks were ignorant and prejudiced, and at this point in our history can’t go without comment.”
Outrage was building online on Sunday with many on Twitter calling for Cherry to be fired.
Rumours circulated about the possibility of Cherry being cut from Coach’s Corner earlier this year after a Toronto Sun columnist wrote that his return to the show had not been confirmed by the summer.
Cherry said at the time that he was not retiring from the decades-old show yet.
Hockey Night in Canada used to be a long-time CBC Saturday night staple. The show and its games moved to Sportsnet when Rogers landed a 12-year, $5.2 billion national broadcast rights deal with the NHL that began in 2014.
The show is still broadcast on CBC in a sub-licensing deal with Rogers Media, which owns Sportsnet. But the show is run by Sportsnet and filmed in its studio in the CBC building in Toronto.
“As Rogers Media is the national rights holder for NHL Hockey in Canada, CBC has no purview over any editorial (choice of commentators or what they say) with respect to Hockey Night in Canada,” CBC spokesman Chuck Thompson said in an email.
READ MORE: Online backlash against Don Cherry for comments on immigrants and Remembrance Day
Salmaan Farooqui, The Canadian Press


Furniture Design + Construction
Designing and Building a Modular Shelving + Desk System for Myself
Three summers ago, I built with my grandpa and dad a modular box shelf system I designed after being inspired by several similar ideas online. I discovered I could repurpose a few of our old (beautiful) closet shelves to make this monstrous, but ergonomic, spaceship of a desk.
#furniture #design #construction
Modular Shelving + Desk System
Melamine • Aluminum • PaintOriginally edited on Medium on April 2nd, 2018.


The security configuration of the application is made throw the security.js file and/or this administration
application. If you have forgot you password update the file to remove the authentication and update your password
in the application. For more detail visit
our website


In this UbiComp 2021 workshop, we are hoping to bring researchers together to discuss requirements, opportunities, challenges and next steps in developing novel approaches for sensing and intervention in the context of mental health.
Find Out MoreMental health issues affect a significant portion of the world's population and can result in debilitating and life-threatening outcomes. To address this increasingly pressing healthcare challenge, there is a need to research novel approaches for early detection and prevention. Toward this, ubiquitous systems can play a central role in revealing and tracking clinically relevant behaviors, contexts, and symptoms. Further, such systems can passively detect relapse onset and enable the opportune delivery of effective intervention strategies.
However, despite their clear potential, the uptake of ubiquitous technologies into clinical mental healthcare is rare, and a number of challenges still face the overall efficacy of such technology-based solutions. The goal of this workshop is to bring together researchers interested in identifying, articulating, and addressing such issues and opportunities. Following the success of past workshops, we aim to continue facilitating the UbiComp community in developing novel approaches for sensing and intervention in the context of mental health.
We invite submissions in the areas and intersections of mental health, well-being, ubiquitous computing, and human-centered design, including but not limited to:
Design and implementation of computational platforms (e.g., mobile phones, instrumented homes, skin-patch sensors) to collect health and well-being data.
Investigation of new methodologies for intervention (e.g., conversational agents, AR/VR applications).
Design of automated inference systems from sensor data of high-level contexts (environmental, social) indicative of mental health status.
Design and implementation of feedback (e.g., reports, visualizations, proactive behavioral interventions, subtle or subconscious interventions etc.) for both patients and caregivers.
Development of robust behavioral models that can handle data sparsity and mislabeling issues.
Integration of multimodal data from various sensor streams for personalized predictive modeling.
Development of methods for sustaining user adherence and engagement over long periods of time.
Design of privacy-preserving strategies for data collection, analysis, and management.
Deployment in low-income communities/countries.
Identification of opportunities for UbiComp approaches (e.g., digital phenotyping, predictive modeling, micro-randomized intervention trials, adaptive interventions) to better understand factors related to addiction, drug use, and treatment efficacy and devise a research agenda in this space.
Integration of ubiquitous technologies into existing healthcare infrastructures and government policy.
Ethical aspects and frameworks for ubiquitous technologies for mental health.
Experience reports from clinical studies in any phase, from early pilot studies to large-scale clinical trials.
Experience report on regulatory issues of Ubicomp technologies for mental health, including FDA approval or CE marking.
Submission deadline: June 25, 2021 (11:59 PM EDT)
Decisions to authors: July 24, 2021
Camera-ready deadline: August 6, 2021
Virtual Workshop: September 26, 2021
We are soliciting 3 types of contributions: regular papers, challenge papers, and demonstrations (see below). Please use the SIGCHI format. Papers should be in PDF format and not anonymized.
https://new.precisionconference.com/user/login Please select SIGCHI→UBICOMP2021→Ubicomp 2021 Workshop Mental Health S&I
We are soliciting three types of contributions for the workshop:
Regular scientific papers both in a short (up to 3 pages) and long (up to 6 pages) format.
Challenge papers (describing a specific challenge to be pitched and discussed at the workshop) in a short (up to 3 pages) format.
Demonstrations (describing developed technologies or early systems to be demonstrated at the workshop) in a short (up to 3 pages) format.
All submitted papers will be reviewed and judged on originality, technical correctness, relevance, and quality of presentation. We explicitly invite submissions of papers that describe preliminary results or work-in-progress, including early clinical experience. The accepted papers will appear in the UbiComp supplemental proceedings and in the ACM Digital Library. The regular papers will be later invited to submit an extended version to a Special Issue ("Passive Sensing for Health") in Sensors.


The Team!
Manager
Bob
Id Number: 1
Office number: 1
<EMAIL_ADDRESS>Engineer
Rob
Id Number: 2
<EMAIL_ADDRESS>https://github.com/aidanrich
Intern
Bobby bob
Id Number: 3
School: Harvard
testbob@test.com


Tag: it
- 15. Scrimba: Learn React 2023-06-06
- 14. AI and the Illusion of Intelligence 2023-04-27
- 13. learnprompting.org 2023-04-27
- 12. Review whole codebase easily 2023-01-26
- 11. CS50 React Native 2022-11-09
- 10. CS50's Introduction to Artificial Intelligence with Python 2022-10-17
- 9. Remote 2022-04-24
- 8. It doesn't have to be crazy at work 2022-03-29
- 7.  Clean Code 2021-04-02
- 5. Prusa Link Architecture 2021-03-01
- 4. Kubernetes 2021-02-22
- 3. Rework 2020-07-05
- 2. The Pragmatic Programmer 2020-03-16
- 1. Testing Python 2019-12-13
All tags


Developer API¶
Including the BlockBall Bukkit-Api¶
BlockBall is using maven as build system but you can include the api via different ways:
Maven:
<dependency>
<groupId>com.github.shynixn.ball</groupId>
<artifactId>ball-api</artifactId>
<version>1.3</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.github.shynixn.blockball</groupId>
<artifactId>blockball-api</artifactId>
<version>5.3.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.github.shynixn.blockball</groupId>
<artifactId>blockball-bukkit-api</artifactId>
<version>5.3.0</version>
<scope>provided</scope>
</dependency>
Gradle:
dependencies {
compileOnly 'com.github.shynixn.ball:ball-api:1.3'
compileOnly 'com.github.shynixn.blockball:blockball-api:5.3.0'
compileOnly 'com.github.shynixn.blockball:blockball-bukkit-api:5.3.0'
}
Reference the jar file:
If you are not capable of using one of these above you can also manually download the api from the repository and reference it in your project.
Updating your plugin.yml¶
Your plugin optionally uses BlockBall.
softdepend: [BlockBall]
Your plugin requires BlockBall to work.
depend: [BlockBall]
Modifying BlockBall games¶
Teleport the ball of a game to a target location
String arenaId = "1";
Location location; // Target location
BukkitGameController gameController = BlockBallApi.INSTANCE.getDefaultGameController();
BukkitGame game = gameController.getGameFromArenaName(arenaId);
if (game == null) { // Check if the gme is not null!
return;
}
BukkitBall ball = game.getBall();
if (ball == null) { // Check if the ball is not null!
return;
}
ball.teleport(location);
Listen to Events¶
There are many BlockBall events in order to listen to actions. Please take a look into the JavaDocs for all events:
@EventHandler
public void onGameJoinEvent(GameJoinEvent event){
Player player = event.getPlayer();
Game game = event.getGame();
//Do something
}
Setup your personal BlockBall Workspace¶
Important! BlockBall is written in Kotlin instead of pure Java. If you are not familiar with Kotlin, BlockBall might be a difficult task.
It is sometimes necessary to customize BlockBall itself instead of using the Developer API. The following steps help you to get started with developing for BlockBall.
Before you continue you should be familiar with git, github, maven and any preferred Java IDE.
- Open BlockBall on github
- Log in or create a github account and press the Fork button in the top right corner.
- Github will create a new repository with BlockBall on your account
- Click on the green Clone or download button and copy the text inside of the textbox
- Open a terminal on your pc, go into a target folder and enter the command
Terminal:
git clone <your copied text>
- After BlockBall folder is created you can open the Project with any Java IDE supporting Maven
- Create a new lib folder in your BlockBall folder
- Download all spigot libraries from 1.8.0 until the latest version and put it into the lib folder
- Try to compile the root project with mvn compile
- If successful you can start editing the source code and create jar files via mvn package
Optional
- To share your changes with the world push your committed changes into your github repository.
- Click on the New pull request button and start a pull request against BlockBall
(base:fork Shynixn/BlockBall, base: development <- head fork: <your repository> …)


Welcome!
Spending a few minutes every day to count the things your grateful for has been proven to significantly improve
your long term well-being in just a few weeks
( Emmons & McCullough, 2003 ).
So I started writing down three things I was grateful for every day and it really worked wonders for me.
But I soon lost these notes, lost track of whether I had done it and sometimes I didn’t have a pen and paper at hand
when it came to mind.
So I made this web app to more conveniently record three things I’m grateful for and
why every day.
If you would like to use it, you need to sign up or login below just so that you can keep a
record for yourself. Its free. Enjoy.
Email:
Password:


NumPy Array IterationNumPy provides an iterator object, i.e., nditer which can be used to iterate over the given array using python standard Iterator interface. Consider the following example. ExampleOutput: Printing array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Iterating over the array: 1 2 3 4 2 4 5 6 10 20 39 3 Order of the iteration doesn't follow any special ordering like row-major or column-order. However, it is intended to match the memory layout of the array. Let's iterate over the transpose of the array given in the above example. ExampleOutput: Printing the array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Printing the transpose of the array: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] 1 2 3 4 2 4 5 6 10 20 39 3 Order of IterationAs we know, there are two ways of storing values into the numpy arrays:
Let's see an example of how the numpy Iterator treats the specific orders (F or C). ExampleOutput: Printing the array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Printing the transpose of the array: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the transposed array 1 2 3 4 2 4 5 6 10 20 39 3 Sorting the transposed array in C-style: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the C-style array: 1 2 10 2 4 20 3 5 39 4 6 3 [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the F-style array: 1 2 3 4 2 4 5 6 10 20 39 3 We can mention the order 'C' or 'F' while defining the Iterator object itself. Consider the following example. ExampleOutput: Iterating over the transposed array 1 2 3 4 2 4 5 6 10 20 39 3 Sorting the transposed array in C-style: Iterating over the C-style array: 1 2 10 2 4 20 3 5 39 4 6 3 Array Values ModificationWe can not modify the array elements during the iteration since the op-flag associated with the Iterator object is set to readonly. However, we can set this flag to readwrite or write only to modify the array values. Consider the following example. ExampleOutput: Printing the original array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Iterating over the modified array 3 6 9 12 6 12 15 18 30 60 117 9
Next TopicNumPy Bitwise Operators
|
NumPy Array IterationNumPy provides an iterator object, i.e., nditer which can be used to iterate over the given array using python standard Iterator interface. Consider the following example. ExampleOutput: Printing array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Iterating over the array: 1 2 3 4 2 4 5 6 10 20 39 3 Order of the iteration doesn't follow any special ordering like row-major or column-order. However, it is intended to match the memory layout of the array. Let's iterate over the transpose of the array given in the above example. ExampleOutput: Printing the array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Printing the transpose of the array: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] 1 2 3 4 2 4 5 6 10 20 39 3 Order of IterationAs we know, there are two ways of storing values into the numpy arrays:
Let's see an example of how the numpy Iterator treats the specific orders (F or C). ExampleOutput: Printing the array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Printing the transpose of the array: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the transposed array 1 2 3 4 2 4 5 6 10 20 39 3 Sorting the transposed array in C-style: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the C-style array: 1 2 10 2 4 20 3 5 39 4 6 3 [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the F-style array: 1 2 3 4 2 4 5 6 10 20 39 3 We can mention the order 'C' or 'F' while defining the Iterator object itself. Consider the following example. ExampleOutput: Iterating over the transposed array 1 2 3 4 2 4 5 6 10 20 39 3 Sorting the transposed array in C-style: Iterating over the C-style array: 1 2 10 2 4 20 3 5 39 4 6 3 Array Values ModificationWe can not modify the array elements during the iteration since the op-flag associated with the Iterator object is set to readonly. However, we can set this flag to readwrite or write only to modify the array values. Consider the following example. ExampleOutput: Printing the original array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Iterating over the modified array 3 6 9 12 6 12 15 18 30 60 117 9
Next TopicNumPy Bitwise Operators
|
NumPy Array IterationNumPy provides an iterator object, i.e., nditer which can be used to iterate over the given array using python standard Iterator interface. Consider the following example. ExampleOutput: Printing array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Iterating over the array: 1 2 3 4 2 4 5 6 10 20 39 3 Order of the iteration doesn't follow any special ordering like row-major or column-order. However, it is intended to match the memory layout of the array. Let's iterate over the transpose of the array given in the above example. ExampleOutput: Printing the array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Printing the transpose of the array: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] 1 2 3 4 2 4 5 6 10 20 39 3 Order of IterationAs we know, there are two ways of storing values into the numpy arrays:
Let's see an example of how the numpy Iterator treats the specific orders (F or C). ExampleOutput: Printing the array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Printing the transpose of the array: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the transposed array 1 2 3 4 2 4 5 6 10 20 39 3 Sorting the transposed array in C-style: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the C-style array: 1 2 10 2 4 20 3 5 39 4 6 3 [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the F-style array: 1 2 3 4 2 4 5 6 10 20 39 3 We can mention the order 'C' or 'F' while defining the Iterator object itself. Consider the following example. ExampleOutput: Iterating over the transposed array 1 2 3 4 2 4 5 6 10 20 39 3 Sorting the transposed array in C-style: Iterating over the C-style array: 1 2 10 2 4 20 3 5 39 4 6 3 Array Values ModificationWe can not modify the array elements during the iteration since the op-flag associated with the Iterator object is set to readonly. However, we can set this flag to readwrite or write only to modify the array values. Consider the following example. ExampleOutput: Printing the original array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Iterating over the modified array 3 6 9 12 6 12 15 18 30 60 117 9
Next TopicNumPy Bitwise Operators
|
NumPy Array IterationNumPy provides an iterator object, i.e., nditer which can be used to iterate over the given array using python standard Iterator interface. Consider the following example. ExampleOutput: Printing array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Iterating over the array: 1 2 3 4 2 4 5 6 10 20 39 3 Order of the iteration doesn't follow any special ordering like row-major or column-order. However, it is intended to match the memory layout of the array. Let's iterate over the transpose of the array given in the above example. ExampleOutput: Printing the array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Printing the transpose of the array: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] 1 2 3 4 2 4 5 6 10 20 39 3 Order of IterationAs we know, there are two ways of storing values into the numpy arrays:
Let's see an example of how the numpy Iterator treats the specific orders (F or C). ExampleOutput: Printing the array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Printing the transpose of the array: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the transposed array 1 2 3 4 2 4 5 6 10 20 39 3 Sorting the transposed array in C-style: [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the C-style array: 1 2 10 2 4 20 3 5 39 4 6 3 [[ 1 2 10] [ 2 4 20] [ 3 5 39] [ 4 6 3]] Iterating over the F-style array: 1 2 3 4 2 4 5 6 10 20 39 3 We can mention the order 'C' or 'F' while defining the Iterator object itself. Consider the following example. ExampleOutput: Iterating over the transposed array 1 2 3 4 2 4 5 6 10 20 39 3 Sorting the transposed array in C-style: Iterating over the C-style array: 1 2 10 2 4 20 3 5 39 4 6 3 Array Values ModificationWe can not modify the array elements during the iteration since the op-flag associated with the Iterator object is set to readonly. However, we can set this flag to readwrite or write only to modify the array values. Consider the following example. ExampleOutput: Printing the original array: [[ 1 2 3 4] [ 2 4 5 6] [10 20 39 3]] Iterating over the modified array 3 6 9 12 6 12 15 18 30 60 117 9
Next TopicNumPy Bitwise Operators
|


|
chinet
|
Functions | |
| void | sgsr_pN (double *SgSr, double *pN, unsigned int Nmax, double Bg, double Br, double pg_theor) |
| void | sgsr_pF (double *SgSr, double *pF, unsigned int Nmax, double Bg, double Br, double pg_theor) |
| void | sgsr_pN_manypg (double *SgSr, double *pN, unsigned int Nmax, double Bg, double Br, unsigned int N_pg, double *pg_theor, double *a) |
| void | sgsr_pF_manypg (double *SgSr, double *pF, unsigned int Nmax, double Bg, double Br, unsigned int N_pg, double *pg_theor, double *a) |
| void | sgsr_manypF (double *, double *, unsigned int, double, double, unsigned int, double *, double *) |
| void | conv_pF (double *SgSr, double *FgFr, unsigned int Nmax, double Bg, double Br) |
| void | conv_pN (double *SgSr, double *FgFr, unsigned int Nmax, double Bg, double Br, double *pN) |
| void | poisson_0toN (double *return_p, double lambda, unsigned int return_dim) |
| void | poisson_0toN_multi (double *, double *, unsigned int, unsigned int) |
| void | polynom2_conv (double *, double *, unsigned int, double) |
| void PdaFunctions::conv_pF | ( | double * | SgSr, |
| double * | FgFr, | ||
| unsigned int | Nmax, | ||
| double | Bg, | ||
| double | Br | ||
| ) |
| SgSr | |
| FgFr | |
| Nmax | |
| Bg | |
| Br |
| void PdaFunctions::conv_pN | ( | double * | SgSr, |
| double * | FgFr, | ||
| unsigned int | Nmax, | ||
| double | Bg, | ||
| double | Br, | ||
| double * | pN | ||
| ) |
| SgSr | |
| FgFr | |
| Nmax | |
| Bg | |
| Br | |
| pN |
| void PdaFunctions::poisson_0toN | ( | double * | return_p, |
| double | lambda, | ||
| unsigned int | return_dim | ||
| ) |
generates Poisson distribution witn average= lambda, for 0..N
| return_p | |
| lambda | |
| return_dim |
| void PdaFunctions::poisson_0toN_multi | ( | double * | , |
| double * | , | ||
| unsigned | int, | ||
| unsigned | int | ||
| ) |
generates Poisson distribution for a set of lambdas
| void PdaFunctions::polynom2_conv | ( | double * | , |
| double * | , | ||
| unsigned | int, | ||
| double | |||
| ) |
convolves vectors p and [p2 1-p2]
| void PdaFunctions::sgsr_manypF | ( | double * | , |
| double * | , | ||
| unsigned | int, | ||
| double | , | ||
| double | , | ||
| unsigned | int, | ||
| double * | , | ||
| double * | |||
| ) |
| void PdaFunctions::sgsr_pF | ( | double * | SgSr, |
| double * | pF, | ||
| unsigned int | Nmax, | ||
| double | Bg, | ||
| double | Br, | ||
| double | pg_theor | ||
| ) |
calculating p(G,R), one ratio, one P(F)
| SgSr | sgsr_pN |
| pF | input p(F) |
| Nmax | |
| Bg | |
| Br | |
| pg_theor |
| void PdaFunctions::sgsr_pF_manypg | ( | double * | SgSr, |
| double * | pF, | ||
| unsigned int | Nmax, | ||
| double | Bg, | ||
| double | Br, | ||
| unsigned int | N_pg, | ||
| double * | pg_theor, | ||
| double * | a | ||
| ) |
calculating p(G,R), several ratios, same P(F)
| SgSr | see sgsr_pN |
| pF | input: p(F) |
| Nmax | |
| Bg | |
| Br | |
| N_pg | size of pg_theor |
| pg_theor | |
| a | corresponding amplitudes |
| void PdaFunctions::sgsr_pN | ( | double * | SgSr, |
| double * | pN, | ||
| unsigned int | Nmax, | ||
| double | Bg, | ||
| double | Br, | ||
| double | pg_theor | ||
| ) |
calculating p(G,R) according to Matthew
| SgSr | SgSr(i,j) = p(Sg=i, Sr=j) |
| pN | p(N) |
| Nmax | max number of photons (max N) |
| Bg | <background green>="">, per time window (!) |
| Br | <background red>="">, -"- |
| pg_theor |
| void PdaFunctions::sgsr_pN_manypg | ( | double * | SgSr, |
| double * | pN, | ||
| unsigned int | Nmax, | ||
| double | Bg, | ||
| double | Br, | ||
| unsigned int | N_pg, | ||
| double * | pg_theor, | ||
| double * | a | ||
| ) |
calculating p(G,R), several ratios, same P(N)
| SgSr | see sgsr_pN |
| pN | input: p(N) |
| Nmax | |
| Bg | |
| Br | |
| N_pg | size of pg_theor |
| pg_theor | |
| a | corresponding amplitudes |


Pain
Call Nurse
Pain
I Need
I Feel
Social
Room Control
Yes
No
I don't know
Maybe
Thank you
Chest
Back
Head
Neck
Stomach
Arm
Leg
Shoulder
Hip
Select Pain Scale
1
2
3
4
5
6
7
8
9
10
Cancel
1
2
3
4
5
6
7
8
9
10
Calling Nurse