RDF语义 推荐标准-5
TransWiki - an Open Translation Project(OTP)
摘要_文档状态_目录 第0节 第1节 第2节 第3节 第4节 第5节 第6节 第7节 附录_参考文献
5. Interpreting Datatypes
5.1 Datatyped Interpretations
RDF provides for the use of externally defined datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype)s identified by a particular URI reference. In the interests of generality, RDF imposes minimal conditions on a datatype. It also includes a single built-in datatype rdf:XMLLiteral.
This semantics for datatypes is minimal. It makes no provision for associating a datatype with a property so that it applies to all values of the property, and does not provide any way of explicitly asserting that a blank node denotes a particular datatype value. Semantic extensions and future versions of RDF may impose more elaborate datatyping conditions. Semantic extensions may also refer to other kinds of information about a datatype, such as orderings of the value space.
A datatype (http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Datatypes) is an entity characterized by a set of character strings called lexical forms and a mapping from that set to a set of values. Exactly how these sets and mappings are defined is a matter external to RDF.
Formally, a datatype d is defined by three items:
1. a non-empty set of character strings called the lexical space of d;
2. a non-empty set called the value space of d;
3. a mapping from the lexical space of d to the value space of d, called the lexical-to-value mapping of d.
The lexical-to-value mapping of a datatype d is written as L2V(d).
In stating the semantics we assume that interpretations are relativized to a particular set of datatypes each of which is identified by a URI reference.
Formally, let D be a set of pairs consisting of a URI reference and a datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype) such that no URI reference appears twice in the set, so that D can be regarded as a function from a set of URI references to a set of datatypes: call this a datatype map. (The particular URI references must be mentioned explicitly in order to ensure that interpretations conform to any naming conventions imposed by the external authority responsible for defining the datatypes.) Every datatype map (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatypeMap) is understood to contain <rdf:XMLLiteral, x> where x is the built-in XML Literal datatype whose lexical and value spaces and lexical-to-value mapping are defined (http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-rdf-XMLLiteral) in the RDF Concepts and Abstract Syntax (http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/) document [RDF-CONCEPTS (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#ref-rdf-concepts)].
The datatype map (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatypeMap) which also contains the set of all pairs of the form <http://www.w3.org/2001/XMLSchema#sss, sss>, where sss is a built-in datatype named sss in XML Schema Part 2: Datatypes (http://www.w3.org/TR/xmlschema-2/) [XML-SCHEMA2 (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#ref-xmls)] and listed in the following table, is referred to here as XSD.
XSD datatypes |
xsd:string, xsd:boolean, xsd:decimal, xsd:float, xsd:double, xsd:dateTime, xsd:time, xsd:date, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, xsd:gDay, xsd:gMonth, xsd:hexBinary, xsd:base64Binary, xsd:anyURI, xsd:normalizedString, xsd:token, xsd:language, xsd:NMTOKEN, xsd:Name, xsd:NCName, xsd:integer, xsd:nonPositiveInteger, xsd:negativeInteger, xsd:long, xsd:int, xsd:short, xsd:byte, xsd:nonNegativeInteger, xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort, xsd:unsignedByte, xsd:positiveInteger |
The other built-in XML Schema datatypes are unsuitable for various reasons, and SHOULD NOT be used: xsd:duration does not have a well-defined value space (this may be corrected in later revisions of XML Schema datatypes, in which case the revised datatype would be suitable for use in RDF datatyping); xsd:QName and xsd:ENTITY require an enclosing XML document context; xsd:ID and xsd:IDREF are for cross references within an XML document; xsd:NOTATION is not intended for direct use; xsd:IDREFS, xsd:ENTITIES and xsd:NMTOKENS are sequence-valued datatypes which do not fit the RDF datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype) model.
If D is a datatype map (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatypeMap), a D-interpretation of a vocabulary V is any rdfs-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfsinterpdef) I of V union {aaa: < aaa, x > in D for some x } which satisfies the following extra conditions for every pair < aaa, x > in D:
General semantic conditions for datatypes.
if <aaa,x> is in D then I(aaa) = x |
if <aaa,x> is in D then ICEXT(x) is the value space of x and is a subset of LV |
if <aaa,x> is in D then for any typed literal "sss"^^ddd in V with I(ddd) = x , |
if <aaa,x> is in D then I(aaa) is in ICEXT(I(rdfs:Datatype)) |
Link title
The first condition ensures that I interprets the URI reference according to the datatype map (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatypeMap) provided. Note that this does not prevent other URI references from also denoting the datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype).
The second condition ensures that the datatype URI reference, when used as a class name, refers to the value space of the datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype), and that all elements of a value space must be literal values.
The third condition ensures that typed literals in the vocabulary respect the datatype lexical-to-value mapping. For example, if I is an XSD-interpretation then I("15"^^xsd:decimal) must be the number fifteen. The condition also requires that an ill-typed literal, where the literal string is not in the lexical space of the datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype), not denote any literal value. Intuitively, such a name does not denote any value, but in order to avoid the semantic complexities which arise from empty names, the semantics requires such a typed literal to denote an 'arbitrary' non-literal value. Thus for example, if I is an XSD-interpretation, then all that can be concluded about I("arthur"^^xsd:decimal) is that it is not in LV, i.e. not in ICEXT(I(rdfs:Literal)). An ill-typed literal does not in itself constitute an inconsistency, but a graph which entails that an ill-typed literal has rdf:type rdfs:Literal, or that an ill-typed XML literal has rdf:type rdf:XMLLiteral, would be inconsistent.
Note that this third condition applies only to datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype)s in the range of D. Typed literals whose type is not in the datatype map (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatypeMap) of the interpretation are treated as before, i.e. as denoting some unknown thing. The condition does not require that the URI reference in the typed literal be the same as the associated URI reference of the datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype); this allows semantic extensions which can express identity conditions on URI references to draw appropriate conclusions.
The fourth condition ensures that the class rdfs:Datatype contains the datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype)s used in any satisfying D-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDinterp). Notice that this is a necessary, but not a sufficient, condition; it allows the class I(rdfs:Datatype) to contain other datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype)s.
The semantic conditions for rdf-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfinterpdef)s impose the correct interpretation on literals typed by 'rdf:XMLLiteral'. However, a D-interpretation recognizes the datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype) to exist as an entity, rather than simply being a semantic condition imposed on the RDF typed literal syntax. Semantic extensions which can express identity conditions on resources could therefore draw stronger conclusions from D-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDinterp)s than from rdfs-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfsinterpdef)s.
If the datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype)s in the datatype map D impose disjointness conditions on their value spaces, it is possible for an RDF graph to have no D-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDinterp) which satisfies it. For example, XML Schema defines the value spaces of xsd:string and xsd:decimal to be disjoint, so it is impossible to construct a XSD-interpretation satisfying (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossSatisfy) the graph
<ex:a> <ex:b> "25"^^xsd:decimal .
<ex:b> rdfs:range xsd:string .
This situation could be characterized by saying that the graph is XSD-inconsistent, or more generally as a datatype clash. Note that it is possible to construct a satisfying (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossSatisfy) rdfs-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfsinterpdef) for this graph, but it would violate the XSD conditions, since the class extensions of I(xsd:decimal) and I(xsd:string) would have a nonempty intersection.
Datatype clashes can arise in several other ways. For example, any assertion that something is in both of two disjoint dataype classes:
_:x rdf:type xsd:string .
_:x rdf:type xsd:decimal .
or that a property with an 'impossible' range has a value:
<ex:p> rdfs:range xsd:string .
<ex:p> rdfs:range xsd:decimal .
_:x <ex:p> _:y .
would constitute a datatype clash. A datatype clash may also arise from the use of a particular lexical form, for example:
<ex:a> <ex:p> "2.5"^^xsd:decimal .
<ex:p> rdfs:range xsd:integer .
or by the use of an ill-typed lexical form:
<ex:a> <ex:p> "abc"^^xsd:integer .
<ex:p> rdfs:range xsd:integer .
Datatype clashes are the only inconsistencies (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossInconsistent) recognized by this model theory (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossModeltheory); note however that datatype clashes involving XML literals can arise in RDFS.
If D is a subset of D', then restricting interpretations of a graph to D'-interpretations amounts to a semantic extension compared to the same restriction with respect to D. In effect, the extension of the datatype map (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatypeMap) makes implicit assertions about typed literals, by requiring them to denote entities in the value space of a datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype). The extra semantic constraints associated with the larger datatype map (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatypeMap) will force interpretations to make more triples true, but they may also reveal datatype clashes and violations, so that a D-consistent graph could be D'-inconsistent.
Say that an RDF graph recognizes a datatype URI reference aaa when the graph rdfs-entails a datatyping triple of the form
aaa rdf:type rdfs:Datatype .
The semantic conditions for rdfs-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfsinterpdef)s require the built-in datatype URI reference 'rdf:XMLLiteral' to be recognized.
If every recognized URI reference in a graph is the name of a known datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype), then there is a natural datatype map (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatypeMap) DG which pairs each recognized URI reference to that known datatype (and 'rdf:XMLLiteral' to rdf:XMLLiteral). Any rdfs-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfsinterpdef) I of that graph then has a corresponding 'natural' DG-interpretation which is like I except that I(aaa) is the appropriate datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype) and the class extension of rdfs:Datatype is modified appropriately. Applications MAY require that RDF graphs be interpreted by D-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDinterp)s where D contains a natural datatype map of the graph. This amounts to treating datatyping triples as 'declarations' of datatype (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDatatype)s by the graph, and making the fourth semantic condition into an 'iff' condition. Note however that a datatyping triple does not in itself provide the information necessary to check that a graph satisfies the other datatype semantic conditions, and it does not formally rule out other interpretations, so that adopting this requirement as a formal entailment principle would violate the general monotonicity lemma (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#GeneralMonotonicityLemma) described in section 6 (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#MonSemExt), below.
5.2 D-entailment
S D-entails E when every D-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDinterp) which satisfies every member of S also satisfies E. This follows the wording of the definition of simple entailment (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defentail) in Section 2 (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#entail), but refers only to D-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDinterp)s instead of all simple interpretations. D-entailment is an example of vocabulary entailment (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#vocabulary_entail).
As noted above, it is possible that a graph which is consistent in one vocabulary becomes inconsistent in a semantic extension defined on a larger vocabulary, and D-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defDinterp)s allow for inconsistencies in an RDF graph. The definition of vocabulary entailment (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#vocabulary_entail) means that an inconsistent graph will entail any graph in the stronger vocabulary entailment. For example, a D-inconsistent graph D-entail (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#D_entailment)s any RDF graph. However, it will usually not be appropriate to consider such 'trivial' entailments as useful consequences, since they may not be valid (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossValid) entailments in a smaller vocabulary.
