monotonicity [was: Re: On Consensus]

A few remarks in response to Jeremy's analysis to test my understanding:

1) liked closing remarks about focus on pragmatic concerns.

2) Examining monotonicity, where it matters and where it doesn't is 
interesting avenue.

I believe that monotonicity is important for technical reasons in the model 
theory, but that both tidy and untidy semantics can be made to work there.

My understanding is that IT systems are often non-monotonic.  (Database 
query: is Fred an employee?  No.  Update database.  Is Fred and 
employee?  Yes.)  This suggests that nonmon may not be much of a problem 
for IT style applications.

However, there are a lot of folks in the semantic web community who wish to 
take a more "logic programming" approach.  I suspect, for them, nonmon 
would be a serious problem.

3) I think we demonstrated before that nonmon can be avoided with tidy 
semantics if we introduce another property.  Now before I get jumped on 
from a great height, I think we have accepted that the user community don't 
want to introduce multiple properties into their schemas.  I'm not 
suggesting that.

But, when an application gets the bitsPerPixel property value as a string 
and converts it to an integer, we could think of that as creating a new 
property with a new value:

    _:s <bitsPerPixelAsInteger> xsd:int"8" .

I think that would be monotonic.

IT style application designers may never think that this is what they are 
doing.  Logic programmers for whom nonmon is a concern could explicitly 
code in this style.

Brian


At 09:27 25/09/2002 +0200, Jeremy Carroll wrote:

> > I am therefore
> > suggesting that we put our thinking caps back on, better understand the
> > real concerns related to this issue
>
>May I suggest that both the tidy and untidy solutions are non-monotonic ....
>
>Procedural we have a problem that the tidy people see the problems with the
>untidy solution, and the untidy people see the problems with the tidy
>solution.
>
>Brian said:
> >  As
> > an example, the cc/pp bitsPerPixel property could be defined to be:
>
> >    A string which is the decimal representation of the integer number of
> > bits per pixel
>
>which may be something like
>
><rdfs:Property rdf:ID="bitsPerPixel>
>   <rdfs:comment>
>A string which is the decimal representation of the integer number of
>bits per pixel
>   </rdfs:comment>
></rdfs:Property>
>
>or it may be something like:
>
><rdfs:Property rdf:ID="bitsPerPixel>
>   <rdfx:range rdf:resource="&xsd;int"/>
></rdfs:Property>
>
>
>Faced with the following three triples:
>
><rdf:Description rdf:ID="foo"
>    ccpp:bitsPerPixel="8"
>    eg:name="8">
>   <eg:age rdf:datatype="&xsd:int;">8</eg:age>
></rdf:Description>
>
>then we may ask is the value of bitsPerPixel property equal to or different
>from the value of the eg:name property and/or the eg:age property.
>
>Before we have taken on board the things from the schema, there appears to be
>nobody in the group who would assert that the bitsPerPixel = "8" is equal to
>the age <xsd:int>"8" .
>
>It is difficult to justify why the bitsPerPixel "8" should (without the 
>schema
>information) be viewed as unequal from the eg:name "8".
>
>After we have read the schema, even the one with the comment and no range
>constraint; it seems that an RDF application would be justified in storing
>the bitsPerPixel as an int, and finding that it was equal to the eg:age and
>different from the bitsPerPixel.
>
>If we buy this end-to-end argument from the original document through to the
>final application level semantics we see that one equality is true initially
>and false at the end, the other if false initially and true at the end. This
>is the essence of non-monotonicity and somewhere we *must* have made a
>non-monotonic step.
>
>Of course this goes back to where Patrick came unstuck with his datatyping
>interpretation. Somewhere, it is reasonable, for an RDF application to
>convert a string that it knows represents a number into the number it
>represents; but when it does the equalities all change. If we admit in our
>specs that such a conversion is licensed then we insert a non-monotonic step
>in our specs.
>
>As I see it we have four different positions:
>
>1: tidy semantics - it really is a string.
>   Basically not saying a datatype is equivalent to
>  rdf:datatype="rdf:langstring"
>
>This outlaws any usage of bare literals as non-strings, as found in the
>owl:cardinality construct, the cc/pp bitsPerPixel construct, dc date
>constructs. Jos seems to be saying this.
>
>2: tidy semantics - mumbs the word
>   We know it isn't a string, but that is not our problem.
>   The RDF specs stay quiet about how the conversion happens.
>   A range constraint on a untyped literal is understood (in RDF) as talking
>about the lexical form not the value.
>   This was my understanding of S-B.
>   The non-monotonicity (the conversion from string to int) is pushed up 
> out of
>RDF into the application semantics.
>
>3: untidy semantics - RDF contains a non-monotonicity
>   The step from RDF to RDFS is non-monotonic, we can do some fancy 
> footwork to
>try and convince you otherwise (e.g. the blank system ID in Patrick latest
>attempts, e.g. my each literal is only in one triple dance;  e.g three valued
>logics).
>
>4: syntactic transform - tidy semantic
>    The syntactic transform, that reads
>
><rdf:Description rdf:ID="foo"
>    ccpp:bitsPerPixel="8"/>
>
>as two triples
>
>_:subj ccpp:bitsPerPixel _:newNode .
>_:newNode rdf:lex "8" .
>
>    This pushes the non-monotonicity the other way.
>Yes the ccpp:bitsPerPixel and eg:name XML attributes have the same attribute
>value, and yes the two blank nodes constructed for each have the same rdf:lex
>value, but if you want to regard the two rdf properties as having the same
>value then we are not going to help you.
>[Some people, such as Patrick, appear to argue for position [3] with  as a
>condensed form of 4 - hmm, I seem to see Patrick as arguing for both 3 and 4
>- there are faults with my analysis].
>This transform has the distinct disadvantage of changing the RDF graph 
>related
>with almost all RDF documents .... We would also need to think about what
>range constraint to put on rdfs:comment (and others) remembering that we want
>to permit both langstrings and xml literals).
>===========
>
>SUMMARY
>
>There is a nasty bump. We can push it one way or another way but it 
>doesn't go
>away. It is essentially an engineering decision about where the bump will
>cause the least accidents.
>
>
>
>
>
>
>

Received on Wednesday, 25 September 2002 04:58:13 UTC