RDF語義 推薦標準-3
TransWiki - W3CHINA.ORG开放翻译计划（OTP）
摘要_文檔狀態_目錄 第0節 第1節 第2節 第3節 第4節 第5節 第6節 第7節 附錄_參考文獻
| 目录 |
3. Interpreting the RDF Vocabulary
3.1 RDF Interpretations
The RDF vocabulary, rdfV, is a set of URI references in the rdf: namespace:
RDF vocabulary |
rdf:type rdf:Property rdf:XMLLiteral rdf:nil rdf:List rdf:Statement rdf:subject rdf:predicate rdf:object rdf:first rdf:rest rdf:Seq rdf:Bag rdf:Alt rdf:_1 rdf:_2 ... rdf:value |
rdf-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfinterpdef)s impose extra semantic conditions on rdfV (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defRDFV) and on typed literals with the type rdf:XMLLiteral, which is referred to as the RDF built-in datatype. This datatype is fully described (http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-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)]. Any character string sss which satisfies the conditions for being in the lexical space of rdf:XMLLiteral will be called a well-typed XML literal string. The corresponding value will be called the XML value of the literal. Note that the XML values of well-typed XML literals are in precise 1:1 correspondence with the XML literal strings of such literals, but are not themselves character strings. An XML literal whose literal string is well-typed will be called a well-typed XML literal; other XML literals will be called ill-typed.
An rdf-interpretation of a vocabulary V is a simple interpretation I of (V union rdfV (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defRDFV)) which satisfies the extra conditions described in the following table and all the triples in the subsequent table. These triples are called the rdf axiomatic triples.
RDF semantic conditions.
x is in IP if and only if <x, I(rdf:Property)> is in IEXT(I(rdf:type)) |
If "xxx"^^rdf:XMLLiteral is in V and xxx is a well-typed XML literal string, then |
If "xxx"^^rdf:XMLLiteral is in V and xxx is an ill-typed XML literal string, then |
The first condition (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfsemcond1) could be regarded as defining IP to be the set of resources in the universe of the interpretation which have the value I(rdf:Property) of the property I(rdf:type). Such subsets of the universe will be central in interpretations of RDFS. Note that this condition requires IP to be a subset of IR. The third condition (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfsemcond3) requires that ill-typed XML literals denote something other than a literal value: this will be the standard way of handling ill-formed typed literals.
RDF axiomatic triples.
rdf:type rdf:type rdf:Property . |
The rdfs-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfsinterpdef)s described in section 4 (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfs_interp) below assign further semantic conditions (range and domain conditions) to the properties used in the RDF vocabulary, and other semantic extensions MAY impose further conditions so as to further restrict their meanings, provided that such conditions MUST be compatible with the conditions described in this section.
For example, the following rdf-interpretation extends the simple interpretation in figure 1 to the case where V contains rdfV (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#defRDFV). For simplicity, we ignore XML literals in this example.
IR = LV union {1, 2, T , P}
IP = {1, T}
IEXT: 1=>{<1,2>,<2,1>}, T=>{<1,P>,<T,P>}
IS: ex:a=>1, ex:b=>1, ex:c=> 2, rdf:type=>T, rdf:Property=>P, rdf:nil=>1, rdf:List=>P, rdf:Statement=>P, rdf:subject=>1, rdf:predicate=>1, rdf:object=>1, rdf:first=>1, rdf:rest=>1, rdf:Seq=>P, rdf:Bag=>P, rdf:Alt=>P, rdf:_1, rdf:_2, ... =>1
Figure 2: An rdf-interpretation.
This is not the smallest rdf-interpretation which extends the earlier example, since one could have made IEXT(T) be {<1,2>,<T,2>}, and managed without having P in the universe. In general, a given entity in an interpretation may play several 'roles' at the same time, as long as this can be done without violating any of the required semantic conditions. The above interpretation identifies properties with lists, for example; of course, other interpretations might not make such an identification.
Every rdf-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfinterpdef) is also a simple interpretation. The 'extra' structure does not prevent it acting in the simpler role.
3.2. RDF entailment
S rdf-entails E when every rdf-interpretation 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 rdf-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfinterpdef)s instead of all simple interpretations. Rdf-entailment is an example of vocabulary entailment (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#vocabulary_entail).
It is easy to see that the lemmas in Section 2 (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#entail) do not all apply to rdf-entailment: for example, the triple
rdf:type rdf:type rdf:Property .
is true in every rdf-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfinterpdef), so is rdf-entailed by the empty graph, contradicting the interpolation lemma for rdf-entailment. Section 7.2 (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#RDFRules) describes exact conditions for detecting RDF entailment.
3.3. Reification, Containers, Collections and rdf:value
The RDF semantic conditions impose significant formal constraints on the meaning only of the central RDF vocabulary, so the notions of rdf-entailment and rdf-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfinterpdef) apply to the remainder of the vocabulary without further change. This includes vocabulary which is intended for use in describing containers and bounded collections, and a reification vocabulary to enable an RDF graph to describe, as well as exhibit, triples. In this section we review the intended meanings of this vocabulary, and note some intuitive consequences which are not supported by the formal model theory (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossModeltheory). Semantic extensions MAY limit the formal interpretations of these vocabularies to conform to these intended meanings.
The omission of these conditions from the formal semantics is a design decision to accomodate variations in existing RDF usage and to make it easier to implement processes to check formal RDF entailment. For example, implementations may decide to use special procedural techniques to implement the RDF collection vocabulary.
3.3.1 Reification
RDF reification vocabulary |
rdf:Statement rdf:subject rdf:predicate rdf:object |
Semantic extensions MAY limit the interpretation of these so that a triple of the form
aaa rdf:type rdf:Statement .
is true in I just when I(aaa) is a token (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossToken) of an RDF triple in some RDF document, and the three properties, when applied to such a denoted triple, have the same values as the respective components of that triple.
This may be illustrated by considering the following two RDF graphs, the first of which consists of a single triple.
<ex:a> <ex:b> <ex:c> .
and
_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject <ex:a> .
_:xxx rdf:predicate <ex:b> .
_:xxx rdf:object <ex:c> .
The second graph is called a reification (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossReify) of the triple in the first graph, and the node which is intended to refer to the first triple - the blank node in the second graph - is called, rather confusingly, a reified triple. (This can be a blank node or a URI reference.) In the intended interpretation of the reification vocabulary, the second graph would be made true in an interpretation I by interpreting the reified triple to refer to a token of the triple in the first graph in some concrete RDF document, considering that token to be valid RDF syntax, and then using I to interpret the syntactic triple which the token instantiates, so that the subject, predicate and object of that triple are interpreted in the same way in the reification as in the triple described by the reification. This could be stated formally as follows: <x,y> is in IEXT(I(rdf:subject)) just when x is a token of an RDF triple of the form
aaa bbb ccc .
and y is I(aaa); similarly for predicate and object. Notice that the value of the rdf:subject property is not the subject URI reference itself but its interpretation, and so this condition involves a two-stage interpretation process: one has to interpret the reified node - the subject of the triples in the reification - to refer to another triple, then treat that triple as RDF syntax and apply the interpretation mapping again to get to the referent of its subject. This requires triple tokens to exist as first-class entities in the universe IR of an interpretation. In sum: the meaning of the reification is that a document exists containing a triple token which means whatever the first graph means.Note that this way of understanding the reification vocabulary does not interpret reification as a form of quotation. Rather, the reification describes the relationship between a token of a triple and the resources that triple refers to. The reification can be read intuitively as saying "'this piece of RDF talks about these things" rather than "this piece of RDF has this form".
The semantic extension described here requires the reified triple that the reification describes - I(_:xxx) in the above example - to be a particular token or instance of a triple in a (real or notional) RDF document, rather than an 'abstract' triple considered as a grammatical form. There could be several such entities which have the same subject, predicate and object properties. Although a graph is defined as a set of triples, several such tokens with the same triple structure might occur in different documents. Thus, it would be meaningful to claim that the blank node in the second graph above does not refer to the triple in the first graph, but to some other triple with the same structure. This particular interpretation of reification was chosen on the basis of use cases where properties such as dates of composition or provenance information have been applied to the reified triple, which are meaningful only when thought of as referring to a particular instance or token of a triple.
Although RDF applications may use reification to refer to triple tokens in RDF documents, the connection between the document and its reification must be maintained by some means external to the RDF graph syntax. (In the RDF/XML syntax described in RDF/XML Syntax Specification (Revised) (http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/) [RDF-SYNTAX (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#ref-rdf-syntax)], the rdf:ID attribute can be used in the description of a triple to create a reification of that triple in which the reified triple is a URI constructed from the baseURI of the XML document and the value of rdf:ID as a fragment.) Since an assertion of a reification of a triple does not implicitly assert the triple itself, this means that there are no entailment relationships which hold between a triple and a reification of it. Thus the reification vocabulary has no effective semantic constraints on it, other than those that apply to an rdf-interpretation (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#rdfinterpdef).
A reification of a triple does not entail the triple, and is not entailed by it. (The reification only says that the triple token exists and what it is about, not that it is true. The second non-entailment is a consequence of the fact that asserting a triple does not automatically assert that any triple tokens exist in the universe being described by the triple. For example, the triple might be part of an ontology describing animals, which could be satisfied by an interpretation in which the universe contained only animals, and in which a reification of it was therefore false.)
Since the relation between triples and reifications of triples in any RDF graph or graphs need not be one-to-one, asserting a property about some entity described by a reification need not entail that the same property holds of another such entity, even if it has the same components. For example,
_:xxx rdf:type rdf:Statement .
_:xxx rdf:subject <ex:subject> .
_:xxx rdf:predicate <ex:predicate> .
_:xxx rdf:object <ex:object> .
_:yyy rdf:type rdf:Statement .
_:yyy rdf:subject <ex:subject> .
_:yyy rdf:predicate <ex:predicate> .
_:yyy rdf:object <ex:object> .
_:xxx <ex:property> <ex:foo> .
does not entail
_:yyy <ex:property> <ex:foo> .
3.3.2 RDF containers
RDF Container Vocabulary |
rdf:Seq rdf:Bag rdf:Alt rdf:_1 rdf:_2 ... |
RDF provides vocabularies for describing three classes of containers. Containers have a type, and their members can be enumerated by using a fixed set of container membership properties. These properties are indexed by integers to provide a way to distinguish the members from each other, but these indices should not necessarily be thought of as defining an ordering of the container itself; some containers are considered to be unordered.
The RDFS vocabulary, described below, adds a generic membership property which holds regardless of position, and classes containing all the containers and all the membership properties.
One should understand this RDF vocabulary as describing containers, rather than as a vocabulary for constructing them, as would typically be supplied by a programming language. On this view, the actual containers are entities in the semantic universe, and RDF graphs which use the vocabulary simply provide very basic information about these entities, enabling an RDF graph to characterize the container type and give partial information about the members of a container. Since the RDF container vocabulary is so limited, many 'natural' assumptions concerning RDF containers are not formally sanctioned by the RDF model theory (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossModeltheory). This should not be taken as meaning that these assumptions are false, but only that RDF does not formally entail that they must be true.
There are no special semantic conditions on the container vocabulary: the only 'structure' which RDF presumes its containers to have is what can be inferred from the use of this vocabulary and the general RDF semantic conditions. In general, this amounts to knowing the type of a container, and having a partial enumeration of the items in the container. The intended mode of use is that things of type rdf:Bag are considered to be unordered but to allow duplicates; things of type rdf:Seq are considered to be ordered, and things of type rdf:Alt are considered to represent a collection of alternatives, possibly with a preference ordering. The ordering of items in an ordered container is intended to be indicated by the numerical ordering of the container membership properties, which are assumed to be single-valued. However, these informal interpretations are not reflected in any formal RDF entailments.
RDF does not support any entailments which could arise from enumerating the elements of an rdf:Bag in a different order. For example,
_:xxx rdf:type rdf:Bag .
_:xxx rdf:_1 <ex:a> .
_:xxx rdf:_2 <ex:b> .
does not entail
_:xxx rdf:_1 <ex:b> .
_:xxx rdf:_2 <ex:a> .
Notice that if this conclusion were valid (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossValid), then the result of conjoining it to the original graph would also be a valid (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossValid) entailment, which would assert that both elements were in both positions. This is a consequence of the fact that RDF is a purely assertional language.
There is no assumption that a property of a container applies to any of the elements of the container, or vice versa.
There is no formal requirement that the three container classes are disjoint, so that for example something can be asserted to be both an rdf:Bag and an rdf:Seq. There is no assumption that containers are gap-free, so that for example
_:xxx rdf:type rdf:Seq.
_:xxx rdf:_1 <ex:a> .
_:xxx rdf:_3 <ex:c> .
does not entail
_:xxx rdf:_2 _:yyy .
There is no way in RDF to 'close' a container, i.e. to assert that it contains only a fixed number of members. This is a reflection of the fact that it is always consistent to add a triple to a graph asserting a membership property of any container. And finally, there is no built-in assumption that an RDF container has only finitely many members.
3.3.3 RDF collections
RDF Collection Vocabulary |
rdf:List rdf:first rdf:rest rdf:nil |
RDF provides a vocabulary for describing collections, i.e.'list structures', in terms of head-tail links. Collections differ from containers in allowing branching structure and in having an explicit terminator, allowing applications to determine the exact set of items in the collection.
As with containers, no special semantic conditions are imposed on this vocabulary other than the type of rdf:nil being rdf:List. It is intended for use typically in a context where a container is described using blank nodes to connect a 'well-formed' sequence of items, each described by two triples of the form
_:c1 rdf:first aaa .
_:c1 rdf:rest _:c2
where the final item is indicated by the use of rdf:nil as the value of the property rdf:rest. In a familiar convention, rdf:nil can be thought of as the empty collection. Any such graph amounts to an assertion that the collection exists, and since the members of the collection can be determined by inspection, this is often sufficient to enable applications to determine what is meant. Note however that the semantics does not require any collections to exist other than those mentioned explicitly in a graph (and the empty collection). For example, the existence of a collection containing two items does not automatically guarantee that the similar collection with the items permuted also exists:
_:c1 rdf:first <ex:aaa> .
_:c1 rdf:rest _:c2 .
_:c2 rdf:first <ex:bbb> .
_:c2 rdf:rest rdf:nil .
does not entail
_:c3 rdf:first <ex:bbb> .
_:c3 rdf:rest _:c4 .
_:c4 rdf:first <ex:aaa> .
_:c4 rdf:rest rdf:nil .
Also, RDF imposes no 'well-formedness (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#glossWellformed)' conditions on the use of this vocabulary, so that it is possible to write RDF graphs which assert the existence of highly peculiar objects such as lists with forked or non-list tails, or multiple heads:
_:666 rdf:first <ex:aaa> .
_:666 rdf:first <ex:bbb> .
_:666 rdf:rest <ex:ccc> .
_:666 rdf:rest rdf:nil .
It is also possible to write a set of triples which underspecify a collection by failing to specify its rdf:rest property value.
Semantic extensions MAY place extra syntactic well-formedness restrictions on the use of this vocabulary in order to rule out such graphs. They MAY exclude interpretations of the collection vocabulary which violate the convention that the subject of a 'linked' collection of two-triple items of the form described above, ending with an item ending with rdf:nil, denotes a totally ordered sequence whose members are the denotations of the rdf:first values of the items, in the order got by tracing the rdf:rest properties from the subject to rdf:nil. This permits sequences which contain other sequences.
Note that the RDFS semantic conditions, described below, require that any subject of the rdf:first property, and any subject or object of the rdf:rest property, be of rdf:type rdf:List.
3.3.4 rdf:value
The intended use for rdf:value is explained intuitively (http://www.w3.org/TR/rdf-primer/#rdfvalue) in the RDF Primer document [RDF-PRIMER (http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#ref-rdf-primer)]. It is typically used to identify a 'primary' or 'main' value of a property which has several values, or has as its value a complex entity with several facets or properties of its own.
Since the range of possible uses for rdf:value is so wide, it is difficult to give a precise statement which covers all the intended meanings or use cases. Users are cautioned, therefore, that the meaning of rdf:value may vary from application to application. In practice, the intended meaning is often clear from the context, but may be lost when graphs are merged or when conclusions are inferred.
