Re: "recommended" semantics - attn pat, reviewers + connolly

My preference here is option 2.

(a) I'm wary of setting definite normative requirements on things that 
might happen in the future, and

(b) in my experience, the language of RFC2119 is a poor fit for things 
other than actual protocol specifications -- in this case, unknown future 
extensions.

#g
--

At 03:28 PM 11/9/02 +0100, Jeremy Carroll wrote:


>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

-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Sunday, 10 November 2002 06:47:21 UTC