- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Wed, 25 Sep 2002 11:25:28 +0100
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- Cc: Jeremy Carroll <jjc@hplb.hpl.hp.com>, w3c-rdfcore-wg@w3.org
Jeremy made some comments about (non-)monotonicity with which I'm not sure I agree. But I think the thrust here is worth exploring. To put it bluntly: Would it be acceptable to abandon the goal of monotonicity for uses of untyped literals? Which I think is along similar lines to what Brian is suggesting here. The non-monotonicity I'm contemplating is to assume (default) that untyped literals are strings unless more explicit information is available. Given that use of untyped literals seems to correspond to a "scruffy" style of information modelling, and an "unscruffy" equivalent can always be achieved by using bNodes and typed literals (with provision for explicitly unknown typing), it seems worth exploring whether loss of monotonicity for the "scruffy" style is truly harmful. I think this at least suggests a migration path from all forms of current usage. #g (who is yet undecided) -- At 09:55 AM 9/25/02 +0100, Brian McBride wrote: >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. >> >> >> >> >> >------------------- >Graham Klyne ><GK@NineByNine.org>
Received on Wednesday, 25 September 2002 06:05:25 UTC