From: Peter F. Patel-Schneider <pfpschneider@gmail.com>

Date: Sun, 13 Oct 2013 06:21:15 -0700

Message-ID: <525A9E4B.4030903@gmail.com>

To: Pat Hayes <phayes@ihmc.us>

CC: RDF Working Group <public-rdf-wg@w3.org>

Date: Sun, 13 Oct 2013 06:21:15 -0700

Message-ID: <525A9E4B.4030903@gmail.com>

To: Pat Hayes <phayes@ihmc.us>

CC: RDF Working Group <public-rdf-wg@w3.org>

That probably works (with the change below), but I think that there needs to be some fixup in any case. If you add the paragraph, I'll make the later fixes. (One extra change would be in the next paragraph to change "what it refers to" to "its mapping".) peter On 10/12/2013 10:22 PM, Pat Hayes wrote: > This all works, but how about the following alternative strategy, which more directly fits with David's request. Insert a new second paragraph of section 4 as follows: > > An <em>interpretation</em> is a mapping from IRIs *and literals* into a set, together with some constraints upon the set and the mapping. This document defines various notions of interpretation, each corresponding in a standard way to an entailment regime. These are identified by prefixes such as <em>simple interpretation</em>, <em>D-interpretation</em>, RDF interpretation, etc. and are defined in later sections. The unqualified term <em> interpretation</em> may be used to refer to all or some of these, depending upon the context. > > Would that be enough, do you think? > > > On Oct 12, 2013, at 8:05 AM, Peter F. Patel-Schneider wrote: > >> Here are the unqualified and incorrectly qualified uses of the word >> "interpretation" that I found in RDF Semantics, with proposed *additions* and >> *segnahc/changes*. [My comments are in brackets.] >> >> I think that these are all editorial, so I *only* need Pat's approval. :-) >> >> peter >> >> >> >> >> >> >> 4. Notation and Terminology >> >> The words denotes and refers to are used interchangeably as synonyms for the >> relationship between an IRI or literal and what it refers to in a given >> interpretation *as defined in this document*, itself called the referent or >> denotation. IRI meanings may >> also be determined by other constraints external to the RDF semantics; when >> we wish to refer to such an externally defined naming relationship, we will >> use the word identify and its cognates. For example, the fact that the IRI >> http://www.w3.org/2001/XMLSchema#decimal is widely used as the name of a >> datatype described in the XML Schema document [XMLSCHEMA11-2] might be >> described by saying that the IRI identifies that datatype. If an IRI >> identifies something it may or may not refer to it in a given >> interpretation, depending on how the semantics is specified. For example, an >> IRI used as a graph name identifying a named graph in an RDF dataset may >> refer to something different from the graph it identifies. >> >> >> 5. Simple Interpretations >> >> This section defines the basic notions of *simple* interpretation and truth for RDF >> graphs. All semantic extensions of any vocabulary or higher-level notation >> encoded in RDF MUST conform to these minimal truth conditions. Other >> semantic extensions may extend and add to these, but they MUST NOT modify or >> negate them. For example, because *simple* interpretations are mappings which apply >> to IRIs, a semantic extension cannot interpret different occurrences of a >> single IRI differently. >> >> The 2004 RDF 1.0 semantics defined *simple* interpretations relative to a vocabulary. >> >> *Simple* Interpretations are required to interpret all names, and are therefore >> infinite. >> >> The denotation of a ground RDF graph in an *simple* interpretation I is then given by >> the following rules, where the interpretation is also treated as a function >> from expressions (names, triples and graphs) to elements of the universe and >> truth values: >> >> Semantic extensions may impose further constraints upon interpretation >> mappings by requiring some IRIs to refer in particular ways. For example, >> D-interpretations, described below, require some IRIs, understood as >> identifying and referring to datatypes, to have a fixed *interpretation/denotation*. >> >> 5.1 Blank Nodes >> >> Suppose I is an *simple* interpretation and A is a mapping from a set of blank nodes >> to the universe IR of I. >> >> Mappings from blank nodes to referents are not part of the definition of an >> *simple* interpretation, since the truth condition refers only to some such mapping. >> Blank nodes themselves differ from other nodes in not being assigned a >> denotation by an *simple* interpretation, reflecting the intuition that they have no >> 'global' meaning. >> >> For example, consider >> the overlapping graphs and an *simple* interpretation I over the universe {Alice, >> Bob, Monica, Ruth} with: I(ex:Alice)=Alice, I(ex:Bob)=Bob, >> IEXT(I(ex:hasChild))={<Alice,Monica>,<Bob,Ruth> } >> >> 5.3 Simple Entailment >> >> Following standard terminology, we say that I satisfies E when I(E)=true, >> that E is *simply* satisfiable when an *simple* interpretation exists which satisfies it, >> (otherwise unsatisfiable), and that a graph G simply entails a graph E when >> every *simple* interpretation which satisfies G also satisfies E. >> >> In later sections these notions will be adapted to other classes of >> interpretations, but throughout this section 'entailment' should be >> interpreted as meaning simple entailment. >> >> 5.4 Properties of simple entailment (Informative) >> >> This does not hold for extended notions of interpretation. For example, a >> graph containing an ill-typed literal is D-unsatisfiable. >> >> >> 7. Literals and datatypes >> >> Datatypes are identified by IRIs. Interpretations will vary according to >> which IRIs they recognize as denoting datatypes. We describe this using a >> parameter D on *simple* interpretations. where D is the set of recognized datatype >> IRIs. >> >> In the 2004 RDF 1.0 specification, the semantics of datatypes referred to >> datatype maps. The current treatment subsumes datatype maps into the >> interpretation mapping on recognized IRIs. >> >> 7.1 D-interpretations >> >> [Before RDF interpretations are defined.] >> The *built-in RDF/special* datatype rdf:langString has no ill-typed literals. Any >> syntactically legal literal with this type will denote a value in every *RDF >> interpretation/D-interpretation where D includes rdf:langString*. >> >> 9. RDFS Interpretations >> >> Classes are defined to be things of type rdfs:Class, and the set >> of all classes in an *RDFS* interpretation will be called IC. >> >> Other triples which must be true in all *rdfs-interpretations/RDFS >> interpretations* include the following. >> >> >> A. Entailment rules (Informative) >> >> The semantics >> described in this document applies to the generalization without change, so >> that the notions of interpretation, satisfiability and entailment can be >> used freely. >> >> B. Finite interpretations (Informative) >> >> To keep the exposition simple, the RDF semantics has been phrased in a way >> which requires interpretations to be larger than absolutely necessary. For >> example, all interpretations are required to interpret the whole IRI >> vocabulary, and the universes of all D-interpretations *where D contains >> xsd:string* must contain all possible strings and therefore be infinite. >> >> Basically, it is only necessary for an interpretation structure to interpret >> the names actually used in the graphs whose entailment is being considered, >> and to consider interpretations whose universes are at most as big as the >> number of names and blank nodes in the graphs. More formally, we can define >> a pre-interpretation over a vocabulary V to be a structure I similar to a >> simple interpretation but with a mapping only from V to its universe >> IR. Then when determining whether G entails E, consider only >> pre-interpretations over the finite vocabulary of names actually used in G >> union E. The universe of such a pre-interpretation can be restricted to the >> cardinality N+B+1, where N is the size of the vocabulary and B is the number >> of blank nodes in the graphs. Any such pre-interpretation may be extended to >> simple interpretations, all of which which will give the same truth values >> for any triples in G or E. Satisfiability, entailment and so on can then be >> defined with respect to these finite pre-interpretations, and shown to be >> identical to the ideas defined in the body of the specification. >> >> C. Proofs of some results (Informative) >> >> The empty graph is true in all *simple* interpretations, so is entailed by any >> graph. If G contains a triple <a b c>, then any *simple* interpretation I with >> IEXT(I(b))={ } makes G false; so the empty graph does not entail G. QED. >> >> If a subgraph E' of G is an instance of E then G entails E' which entails E, >> so G entails E. *NOw/Now* suppose G entails E, and consider the Herbrand >> interpretation I of G defined as follows. >> >> D.1 Reification >> >> 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. >> >> D.2 RDF containers >> >> However, these informal *interpretations/conditions* are not reflected in any formal RDF >> entailments. >> >> 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. >> >> > ------------------------------------------------------------ > IHMC (850)434 8903 home > 40 South Alcaniz St. (850)202 4416 office > Pensacola (850)202 4440 fax > FL 32502 (850)291 0667 mobile (preferred) > phayes@ihmc.us http://www.ihmc.us/users/phayes > > > > > >Received on Sunday, 13 October 2013 13:21:50 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 17:04:33 UTC
*