The claim that xsd:integer is a subClassOF xsd:decimal is not incompatible with using the intensional semantics for datatypes.
The claim that xsd:integer is a subClassOF xsd:string is incompatible with using the intensional semantics for datatypes.
A simple datatype production; a language+datatype production. Simply duplicate the constructs under http://www.w3.org/2000/10/rdf-tests/rdfcore/ntriples/test.nt
A parser is not required to know about well-formed datatyped literals.
Without datatype knowledge, a 'badly-formed' datatyped literal cannot be detected.
With appropriate datatype knowledge, a 'badly-formed' datatyped literal can be detected.
Demonstrating the semantic equivalence of two lexical forms of the same datatyped value.
As semantic-equivalence-within-type-1; the entailment works both ways.
This test used to claim: Language attributes on a datatyped literal make them distinct for the purposes of non-datatype-aware entailments. There are no longer language tags on datatyped literals.
Obsoleted: datatyped literals have no language tag.
Members of different datatypes may be semantically equivalent.
Where sufficient DT knowledge is available, a range clash may be detected; the document then contains a contradiction.
Language does not affect the denotation of rdf:XMLLiteral. NOTE that this is a change from previous versions of the spec. Langauge tags do not live on XMLLiterals.
From decisions listed in http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Oct/0098.html
A plain literal denotes the same thing as its corresponding xsd:string, where one exists.
rdfs:subClassOf has intensional semantics, not extensional.
rdfs:subPropertyOf has intensional semantics, not extensional.
Test that ICEXT(I(rdfs:Literal)) is a subset of LV.
Does the treatment of literals conform to charmod ? Test for success of legal Normal Form C literal
Does the treatment of literals conform to charmod ? Test for failure for literal not in Normal Form C This test case has been WITHDRAWN in light of changes to NFC handling in concepts
A uriref is allowed to match non-US ASCII forms conforming to Unicode Normal Form C. No escaping algorithm is applied.
A uriref which already has % escaping is permitted. No unescaping algorithm is applied.
Test for failure for uriref not in Normal Form C.
An international URI ref and its %-escaped form label different nodes in the graph. No model theoretic relationship holds between them.
A surrounding rdf:RDF element is no longer mandatory.
This test shows the treatment of non-ASCII characters in the value of rdf:ID attribute.
This test shows the treatment of non-ASCII characters in the value of rdf:about attribute.
The question posed to the RDF WG was: should an RDF document containing multiple rdf:_n properties (with the same n) on an element be rejected as illegal? The WG decided that a parser should accept that case as legal RDF.
Like rdfms-empty-property-elements/test001.rdf but with a processing instruction as the only content of the otherwise empty element.
Like rdfms-empty-property-elements/test001.rdf but with a comment as the only content of the otherwise empty element.
rdf:bagID is forbidden on property element prop with an rdf:resource or rdf:parseType attribute: the following is in error.
Two property attributes and a property element on an rdf:Description. Since the property attributes are not ordered under document order, two different n-triples files corresponding to both possible orderings are permitted. One of test010a and test010b SHOULD pass, at least.
Two property attributes and a property element on an rdf:Description. Since the property attributes are not ordered under document order, two different n-triples files corresponding to both possible orderings are permitted.
Two property attributes and a property element on an rdf:Description. Since the property attributes are not ordered under document order, two different n-triples files corresponding to both possible orderings are permitted. One of test011a and test011b SHOULD pass, at least.
Two property attributes and a property element on an rdf:Description. Since the property attributes are not ordered under document order, two different n-triples files corresponding to both possible orderings are permitted. One of test012a and test012b SHOULD pass, at least.
The value of rdf:ID must match the XML Name production, (as modified by XML Namespaces).
The value of rdf:bagID must match the XML Name production, (as modified by XML Namespaces).
rdf:nodeID can be used to label a blank node.
rdf:nodeID can be used to label a blank node. These have file scope and are distinct from any unlabelled blank nodes.
On an rdf:Description or typed node rdf:nodeID behaves similarly to an rdf:about.
On a property element rdf:nodeID behaves similarly to rdf:resource.
The value of rdf:nodeID must match the XML Name production, (as modified by XML Namespaces).
Cannot have rdf:nodeID and rdf:resource.
An RDF/XML serlializer is recommended to produce an exception if asked to serialize the following graph since there is no way to represent it in the RDF/XML syntax.
Plain literals are distinguishable on the basis of language tags.
While it is a superproperty, _:a <rdfs:contains (@@member?)> _:b . does NOT entail _:a <rdf:_n> _:b . for any _n.
Should a property be allowed more than one rdfs:range property? What should the semantics of multiple domain and range properties be? -> Multiple domain and range constraints are permissable and will have conjunctive semantics. test001 describes a property with rdfs:domain the intersection of 2 domains test002 describes a property with rdfs:range the intersection of 2 ranges test003 sample statement test004 entailed description using test001, test002, test003 and the rules for RDF and RDFS entailment (see http://www.w3.org/2000/10/rdf-tests/rdfcore/entailment/ )
RDF Semantics defines rdfs:range to have an intensional reading. However, semantic extensions may give an extensional reading to range. The premise/conclusion pair is a non-entailment for RDFS reasoning, but may hold in semantic extensions.
RDF Semantics defines rdfs:range to have an intensional reading of domain. However, semantic extensions may give an extensional reading to domain. The premise/conclusion pair is a non-entailment for RDFS reasoning, but may hold in semantic extensions.
Indicating a simple inconsistency drawn from RDFS. RDFS can only produce inconsistencies through badly-formed XMLLiteral datatypes.
From an inconsistent graph, any entailment can be drawn. This is an example.
Cycles are permitted in subClassOf; therefore, no error occurs and the following entailment holds trivially.
Cycles are permitted in subPropertyOf; therefore, no error occurs and the following entailment holds trivially.
an instance of the Property class may have an rdfs:subClassOf property. the meaning of such a property is defined by the model theory. The wording of the formal resolution is a bit bare, so let me add a few words of explanation. What this means is that a resource can be both a class and a property. This test is encoded as follows: a Property may have a subclass (that is, such an RDF graph is satisfiable)
The inheritance semantics of the subPropertyOf relationship needs to be clarified. => subProperties inherit conjunctively the domain and range of their superproperties
RDFCore WG RESOLVED that a reified statement was a stating, not a statement. The following entailment does not, therefore, hold.
RDFCore WG RESOLVED that a statement does NOT entail its reification. The following entailment does not, therefore, hold.
RDFCore WG RESOLVED that a reified statement was a stating, not a statement. The following entailment does not, therefore, hold. This is the same as test001, but using RDFS-entailment.
RDFCore WG RESOLVED that a statement does NOT entail its reification. The following entailment does not, therefore, hold. This is the same as test002, but using RDFS-entailment.
The case of the language tag is not significant.
Demonstrating the canonicalisation of XMLLiterals.
This test case concerns URIs relative to a non-relative URI scheme base. It's beyond the scope of the WG to deal with this; it has therefore not been approved.
This is not valid rdf/xml. The embedding of RDF/XML in other XML formats is beyond the scope of these test cases. Test case withdrawn.
Test output corrected to use correct base URL.
This test case is deprecated. The use of mailto: URIs with xml:base is not within the scope of RDFCore's charter to sort out.
A well-formed typed literal is not related to an ill-formed literal. Even if they only differ by whitespace.
A simple test for well-formedness of a typed literal.
An integer with whitespace is ill-formed.