- From: pat hayes <phayes@ai.uwf.edu>
- Date: Sun, 15 Dec 2002 15:12:47 -0600
- To: Brian McBride <bwm@hplb.hpl.hp.com>, connolly@w3.org, jjc@hplb.hpl.hp.com, Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Cc: w3c-rdfcore-wg@w3.org
A revised (post_Dan_Connolly) version is now at http://www.coginst.uwf.edu/~phayes/RDF_Semantics_finalCall_2.html Note the final _2 It passes the W3C filters. This is *not* fully tarted up with internal links to definitions, but I'll be working on a version which is over the next few days, in preparation for later. Summary of changes since last freeze, arising from Dan's comments: (Jeremy & Graham, note @@) ------------- | that model theory might be better called 'interpretation theory' link to Glossary now reveals a short note there explaining this. ------------- Monotonic logic as a design decision. Couldnt find a suitable reference (!! bummer indeed) so modified this text. It is now broken out as a paragraph: "RDF is an assertional logic, in which each triple expresses a simple proposition. This imposes a fairly strict monotonic discipline on the language, so that it cannot express closed-world assumptions, local default preferences, and several other commonly used non-monotonic constructs. " @@I'd like to make it clear that this particular point isnt just something we didnt get around to, but a positive decision we made. @@I would like us to have this stated explicitly somewhere, and the concepts doc is the obvious place. Hint, hint?? This is actually quite timely, as there is mounting political pressure (mostly from the RuleML folk) to insert highly nonmonotonic extensions into the webont mix, and I'd like us to lock down the point that anything non-mon is not an RDF semantic extension. ------------ RFC2119 language tightened up somewhat, to read as follows. @@Comments or suggestions for modification welcomed:: <anchor #DefSemanticExtension> Particular uses of RDF, including as a basis for more expressive languages such as DAML [DAML] and OWL [OWL], may impose further semantic conditions in addition to those described here, and such extra semantic conditions can also be imposed on the meanings of terms in particular RDF vocabularies. Extensions or dialects of RDF which are obtained by imposing such extra semantic conditions may be referred to as semantic extensions of RDF. Semantic extensions of RDF are constrained in this recommendation using the language of [RFC 2119]. Semantic extensions of RDF MUST conform to the semantic conditions in this document. Any name for entailment in a semantic extension SHOULD be indicated by the use of a vocabulary entailment term. The semantic conditions imposed on an RDF semantic extension MUST define a notion of vocabulary entailment which is valid according to the model-theoretic semantics described in the normative parts of this document; except that if the semantic extension is defined on some syntactically restricted subset of RDF graphs, then the semantic conditions need only apply to this subset. Specifications of such syntactically restricted semantic extensions MUST include a specification of their syntactic conditions which are sufficient to enable software to distinguish unambiguously those RDF graphs to which the extended semantic conditions apply. Applications based on such syntactically restricted semantic extensions MAY treat RDF graphs which do not conform to the required syntactic restrictions as errors. An example of a semantic extension of RDF is RDF Schema, the semantics of which are defined in later parts of this document. RDF Schema imposes no extra syntactic restrictions. ------------ All bad uses of 'namespace' are now removed, And by the way the relevant anchor has been renamed also, from #namespace_entail to #vocabulary_entail, in case anyone was pointing to 'vocabulary entailment'. ------------- Ive reworded the limitations section so it doesnt have the misconception Dan noted and now reads: The semantics does not assume any particular relationship between the denotation of a uriref and a document or network resource which can be obtained by using that uriref in an HTTP transfer protocol, or any entity which is considered to be the source of such documents. Such a requirement could be added as a semantic extension, but the formal semantics described here makes no assumptions about any connection between the denotations of urirefs and the uses of those urirefs in other protocols. ----- The text on datatype interpretations has been cleaned up. Section 3.4 now makes no reference at all to error conditions or information: it is pure model theory: A datatype is an entity characterized by a set of character strings called lexical forms and a mapping from that set to a set of values. ...... D is a set of datatypes, which we will call recognized datatypes. Urirefs which denote recognized datatypes are required to have the same denotation in all D-interpretations, so recognizing a datatype amounts to fixing the meaning of a uriref. The set of recognized datatypes always includes rdf:XMLLiteral and may include the XML Schema...... Later it now reads: Datatype clashes are the only inconsistencies recognized by this model theory. The definition of entailment means that a D-inconsistent graph D-entails any RDF graph; however, it will usually not be appropriate to consider such 'trivial' entailments as useful consequences, since they are not valid rdf- or rdfs- entailments. ----- I have simply deleted the comment about XSD:string not applying to untyped literals. NOw the document just doesn't even mention any connection between untyped literals and any datatypes, which is safer. I think we should come to a decision about this, however, and say what it is as clearly as possible. Also fixed the bad comment about range datatypes. ----- I have put a tiny comment right at the end of section 4: Datatype clashes and violations may be considered to be error conditions. However, we note that such graphs are not strictly ill-formed, and can be used to support valid RDFS entailments which might be meaningful in certain contexts. ------- OK, s'all for now. Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes s.pam@ai.uwf.edu for spam
Received on Sunday, 15 December 2002 16:12:56 UTC