Re: On Consensus

> 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 03:29:36 UTC