W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > December 2002

Re: Semantics doc now in shadow TR space

From: pat hayes <phayes@ai.uwf.edu>
Date: Sun, 15 Dec 2002 15:12:47 -0600
Message-Id: <p05111b26ba228cb0a451@[]>
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


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 


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- 

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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:19 UTC