Test case manifest vocabulary
comment: Manifest vocabulary for test cases
creator: Andy Seaborne
publisher: W3C RDF Data Access Working Group
description: Test case manifest vocabulary
date: 2004-07
format: RDF

Manifest
type: Class
comment: The class of manifests

ManifestEntry
type: Class
comment: One entry in rdf:type list of entries

include
type: Property
comment: Connects the manifest resource to rdf:type list of manifests
domain: Manifest
range: List

entries
type: Property
comment: Connects the manifest resource to rdf:type list of entries
domain: Manifest
range: List

name
type: Property
comment: Optional name of this entry
domain: ManifestEntry
range: Literal

action
type: Property
comment: Action to perform
domain: ManifestEntry

result
type: Property
comment: The expected outcome
domain: ManifestEntry
comment: The test status
range: TestStatus

requires
type: Property
comment: Required functionality for execution of this test
domain: ManifestEntry
range: Requirement

notable
type: Property
comment: Notable feature of this test (advisory)
domain: ManifestEntry

resultCardinality
type: Property
comment: Specifies whether passing the test requires strict or lax cardinality adherence
domain: ManifestEntry
range: ResultCardinality

Positive Syntax Test
type: Class
comment: A type of test specifically for syntax testing. Syntax tests are not required to have an associated result, only an action.

Positive Syntax Test for SPARQL1.1 Query
type: Class
comment: A type of test specifically for syntax testing of new features in the SPARQL1.1 Query Language. Syntax tests are not required to have an associated result, only an action.

Positive Syntax Test for SPARQL1.1 Update
type: Class
comment: A type of test specifically for syntax testing of SPARQL1.1 Update. Syntax tests are not required to have an associated result, only an action.

Negative Syntax Test
type: Class
comment: A type of test specifically for syntax testing. Syntax tests are not required to have an associated result, only an action. Negative syntax tests are tests of which the result should be a parser error.

Negative Syntax Test for SPARQL1.1 Query
type: Class
comment: A type of test specifically for syntax testing of new features in the SPARQL1.1 Query Language. Syntax tests are not required to have an associated result, only an action. Negative syntax tests are tests of which the result should be a parser error.

Negative Syntax Test for SPARQL1.1 Update
type: Class
comment: A type of test specifically for syntax testing of SPARQL1.1 Update. Syntax tests are not required to have an associated result, only an action. Negative syntax tests are tests of which the result should be a parser error.

Query Evaluation Test
type: Class
comment: A type of test specifically for query evaluation testing. Query evaluation tests are required to have an associated input dataset, a query, and an expected output dataset.

Update Evaluation Test
type: Class
comment: The class of all SPARQL 1.1 Update evaluation tests

TestStatus
type: Class
comment: Statuses a test can have

proposed
type: TestStatus

accepted
type: TestStatus

rejected
type: TestStatus

Requirement
type: Class
comment: Requirements for a particular test

Notable
type: Class
comment: Requirements for a particular test

XsdDateOperations
type: Requirement
comment: Tests that require xsd:date operations

StringSimpleLiteralCmp
type: Requirement
comment: Tests that require simple literal is the same value as an xsd:string of the same lexicial form

KnownTypesDefault2Neq
type: Requirement
comment: Values in disjoint value spaces are not equal

LangTagAwareness
type: Requirement
comment: Tests that require langauge tag handling in FILTERs

IllFormedLiterals
type: Notable
comment: Tests that involve lexical forms which are illegal for the datatype

ResultCardinality
type: Class
comment: Potential modes of evaluating a test's results with respect to solution cardinality

LaxCardinality
type: ResultCardinality
comment: The given mf:result for a test with an mf:resultCardinality of mf:ReducedCardinalityTest is the results as if the REDUCED keyword were omitted. To pass such a test, an implementation must produce a result set with each solution in the expected results appearing at least once and no more than the number of times it appears in the expected results. Of course, there must also be no results produced that are not in the expected results.