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

>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.

I will fix the below as soon as I get back from lunch. MOst uptodate 
version is at 
http://www.coginst.uwf.edu/~phayes/RDF_Semantics_latest.html

>
>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)

Well then, why don't we just incorporate the full list semantics into 
RDF? In effect, this does that without pretending not to. I think we 
should do one or the other.

>
>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).


I prefer this for things like the lists and the 'informal' stuff. I 
didn't want to get into this territory there, and was aware that 
these words were dangerous, but wanted to convey something useful.

As editor I will choose options.  If the WG decides to prefer the 
others., it will be a trivial edit to fix.

Thanks for the prose :-)


>
>===
>
>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.

Yes, I think the strong stance is appropriate here.

>]]
>[[
>  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).

That might break some existing uses. I'd rather be a bit catholic at 
this point.

I like the 'MAY' trick. There's a hidden message here, right? We 
aren't saying YOU have to limit YOUR interpretations; but if you 
don't, and some OTHER bloke can't understand YOU, its not OUR fault, 
and its not HIS fault, so guess whose fault it is....

>[[
>  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.

Not sure about that. There could be some nonstandard interps that are 
harmless but useful for some apps, eg lists with hash tables 
incorporated into them, or some damn thing, I will try to craft 
appropriate wording which just imposes the right level of conformity.

>]]
>
>[[
>. 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.

Will fix.

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 Saturday, 9 November 2002 16:20:46 UTC