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

"recommended" semantics - attn pat, reviewers + connolly

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Sat, 9 Nov 2002 15:28:41 +0100
To: <w3c-rdfcore-wg@w3.org>
Message-ID: <MABBLGKMPIJFCKFGDBEPAEFDCBAA.jjc@hpl.hp.com>


Pat,

on second thoughts, I think that one of the editorial issues (still merely
physical on my paper copy - not yet in the virtual world) is in fact
critical.

The problem is the clarity of the use of words like "recommended" around the
behaviour of semantic extensions to RDF. (List and reification semantics).

RECOMMENDED (note the case) has a precise semantics defined by RFC 2119.

Possible changes are one of:

1) Add the following note:
[[ The use of the word like "recommended" and others reminiscient of
keywords in RFC 2119 needs more work. At this stage the Working Group has
not decided on any features of semantic extensions that are REQUIRED or
RECOMMENDED in that sense. ]]

2) Decide that we are not RECOMMENDing or REQUIRing anything of semantic
extensions. Then I suggest changing the occurrences highlighted below to not
use words that might be confused with RFC 2119 Keywords.

3) Decide that the recommendations highlighted are MUSTs on semantic
extensions, I provide suggested text below. (i.e. non-standard extensions of
List semantics are not allowed)

4)  Decide that the recommendations highlighted are SHOULDs on semantic
extensions, I provide suggested text below. (i.e. non-standard extensions of
List semantics are allowed, but require justification) [use text below but
substitute SHOULD for MUST and RECOMMENDED for REQUIRED).

===

My pref is option (3), it would be good to hear from other reviewers and
DanC and other WG members on this issuette.

===
Option (3) expanded:
[[
Particular uses of RDF, including as a basis for more expressive languages
such as DAML and 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 namespaces. We use this
convention in later parts of this document. All such extensions must however
conform to the semantic conditions in this document. In more operational
terms, any entailment which is valid according to the semantics described
here must continue to be valid in any extended semantics imposed on an RDF
namespace. We also recommend that entailment with respect to a more
restricted notion of interpretation should be indicated by the use of a
namespace entailment term, as introduced in section @@@ below.
]]
=>
[[
Particular uses of RDF, including as a basis for more expressive languages
such as DAML and 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 namespaces.
We refer to these as <dfn>semantic extensions</dfn>. Semantic extensions to
RDF are constrained in this recommendation using the language of RFC 2119.
An example semantic extension is RDF Schema, the semantics of which are
defined
in later parts of this document. All such extensions MUST conform to the
semantic conditions in this document. In more operational terms, any
entailment which is valid according to the semantics described here MUST
continue to be valid in any extended semantics imposed on an RDF namespace.
Any name for entailment in a semantic extension MUST be indicated by the use
of a namespace entailment term, as introduced in section @@@ below.
]]
[[
 They are discussed here in order to explain both the intuitive meanings
intended and recommended, but also to note the intuitive consequences which
are not supported by the formal model theory.
]] =>
[[
They are discussed here in order to explain both the intuitive meanings
intended and also to note the intuitive consequences which are not supported
by the formal model theory. Constraints are imposed on semantic extensions.
]]
[[
There are however clear recommendations on such extra restrictions, noted in
each case
]] => delete or
[[ Constraints are imposed on semantic extensions.   ]]
(if not used earlier)

[[
The recommended intended interpretation of these are that a triple of the
form

aaa rdf:type rdf:Statement .

is true in I just when I(aaa) is a token of an RDF triple in some RDF
document.
]]
=>
[[
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 of an RDF triple in some RDF
document.
]]

(we may want a MAY NOT against requiring some other interpretation).
[[
 As this example shows, it is also possible to write a set of triples which
underspecify a collection (_:777 in the example) by failing to specify its
rdf:rest property value. Extensions and applications of RDF can place their
own well-formedness restrictions on the use of this vocabulary. We recommend
that any semantic extension to RDF retains the convention that the subject
of a 'linked' collection of three-triple items of the form described above,
ending with an item ending with rdf:nil, should always describe a linear
sequence whose members are the denotations of the rdf:first values of the
items, in the sequence got by tracing the rdf:rest properties from the list
to rdf:nil.
]]
=>
[[
As this example shows, it is also possible to write a set of triples which
underspecify a collection (_:777 in the example) by failing to specify its
rdf:rest property value.
<p>
Various nonstandard interpretations of this vocabulary are possible:
+ there may be infinite directed chains of rdf:rest arcs.
+ a single resource may be related by either IEXT(I(rdf:first)) or
IEXT(I(rdf:rest)) to more than one other resource.
+ the domains of IEXT(I(rdf:first)) and IEXT(I(rdf:rest)) may be different.
+ rdf:nil may be in the domain of IEXT(I(rdf:first)) or IEXT(I(rdf:rest))
+ apart from rdf:nil there may be some member of rdf:List which is not in
the domain of IEXT(I(rdf:rest))

**sorry I have phrased this a lot less well than you can**

Semantic extensions MAY exclude any or all nonstandard interpretations of
the List vocabulary.

Semantic extensions MUST NOT require any nonstandard interpretations of the
List vocabulary.
]]

[[
. Again, we emphasize that these closure rules are not being recommended as
an efficient computational process.
]]
=>
[[
. Again, we emphasize that these closure rules are not being recommended as
an efficient computational process.
]]
=>
delete - you've already said it once.
The use of this language may suggest that a naive implementation of the
closure rules is nonconforming.

Jeremy
Received on Saturday, 9 November 2002 09:24:22 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:54:01 EDT