- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Wed, 14 Nov 2001 12:15:36 -0600
- To: Patrick.Stickler@nokia.com
- Cc: w3c-rdfcore-wg@w3.org
> > >I'm not saying it's false. I'm saying the test of the constraint >> >fails. Those are very different things. >> >> Then please define the second one (in terms I can understand?). > >I'm trying... believe me... > >> RDF(S) makes assertions; as far as I can tell, that is all it does. >> An assertion is true or false in every interpretation. Where in this >> picture are there any 'constraints' other than assertions? > >What you suggest is that if we have > > someProperty rdfs:range someType . > >and > > someResource someProperty _:1:"foo" . > _1:"foo" rdf:type someOtherType . > >we end up with > > someResource someProperty _:1:"foo" . > _1:"foo" rdf:type someOtherType . > _1:"foo" rdf:type someType . > Yes, that could be inferred if we allow literals as subjects, and using the extended model theory. >since RDFS only "asserts" things. Well, not 'only'; it could be inferred because that would be a valid consequence according to the semantics of RDFS. >Now, if someOtherType is not a subClassOf someType, then >we should flag some sort of error about the incompatible >data types, right? If those assertions are inconsistent then I would expect an RDFS engine to tell me that, yes, and maybe such a report ought to be taken seriously as a sign that something is wrong somewhere, indeed. But exactly what is wrong, and what should be done about it, are questions that lie outside the scope of RDFS meaning. However, in this example, I would note that there is no way to express in RDFS that one class is *not* a subclass of another, so this situation could never arise, in fact. This may be just a technical quibble, but it does illustrate the general point, since the implied clash between someType and someOtherType will only be visible to an engine that knows more about those types than RDFS can or should know. (BTW, there is an ongoing divergence of opinion in this field about quite what 'verification' ought to constitute. The DAML+OIL group for example has been having some internal discussions about whether a verifier should flag conditions which are semantically correct, strictly speaking, but which are very likely to indicate an error, in practice, eg using a class name which has no definition (which is legal in DAML+OIL), or a very long subClassOf loop. Clearly, this notion of 'verifying' is somewhat flexible, and different notions are useful in different contexts. I think this debate might be relevant here. It seems to me that there are several clear distinctions that ought to be observed, most notably between flagging something syntactically illegal/something contradictory (impossible in RDFS, by the way)/something which violates an external criterion of correctness/something'odd' according to some external criterion. As far as I can see, RDFS (unlike DAML+OIL) simply is unable to express a direct contradiction, so all normative flags, other than syntax errors, have to be of the 'external' variety. For example, something that was using RDFS to record datatyping information might well barf if RDFS delivered it both someType and someOtherType; but I would say that was it's business, not RDFS's business. >What this means is that, if rdfs:range is used in >a descriptive sense, you end up with the above >un-flagged conflict. No, that does not follow. Saying that the language is descriptive does not imply that contradictions or conflicts must not be flagged. It only says how the language sets about identifying them (by inference.) >If rdfs:range is used in a prescriptive sense, as >a true constraint, it doesn't add the statement > > _1:"foo" rdf:type someType . > >but provides the means for determining whether the >statement > > _1:"foo" rdf:type someOtherType . > >is acceptable within the scope of the given property. But what is the difference between those two cases, for RDFS ? The inferences involved seem identical; and RDFS has no notion of 'acceptable' (or indeed of 'scope' in this sense), so whatever this means, it must be outside the scope of RDFS itself. It seems to belong to the domain of some other system that is imposing a 'prescriptive' interpretation on the information that is encoded in RDFS; but that interpretation is not relevant to RDFS itself; and indeed it cannot be, since the required conceptual apparatus of being 'acceptable' or needing to be 'rejected', and distinctions like that between a violation of integrity as opposed to a difference of opinion, or that between a local and a global scope, are all entirely missing from RDFS. If they arise anywhere, it has to be from outside. > >> >At any given time, a system must be able to make decisions >> >based on the knowledge it has. >> >> It must be able to draw conclusions. (I do not know what it would >> mean for RDF(S) to make a *decision*, exactly. ) > >I didn't say that *RDF* makes those decisions. A computer >*SYSTEM* operating on RDF encoded knowledge makes those >decisions. Right, exactly. So all these distinctions that you insist must be imposed on RDFS, actually belong in this external SYSTEM. Some of them will interpret some information prescriptively, maybe. Others may not. Either way, its up to them , not to us. > >> I have no idea what 'sufficiency' of a statement means. > >I'm an engineer, and speaking in engineering terms (and >general, loose terms at that). Please try not to read too >much formalism into my explanations. I know that formalism >is good, and would result in better understanding, but >I have to work with the vocabulary I know. > >I'm an engineer, not a mathematician, but then, this group >needs all types, right? Right. I didn't mean to stop you using your vocabulary, but we all have to be ready to translate for one another. > > Validity >> means preservation of truth; > >As in an XML instance being Valid? ;-) Touché. I was using the logician's terminology maybe too carelessly. > >> >Any knowledge based system, at a single point in time, is >> >a kind of closed world. >> >> WRONG, a thousand times wrong. That is a traditional 'database' >> assumption, but it is not appropriate for the semantic web or RDF. >> (Take this up with the higher authorities; it is out of scope for the >> RDF WG to argue this point, I think.) > >Philosophize all you like, but the *reality* is that at any >given point in time when stuff has to happen in a computer >program, the knowledge it has at hand constitutes a temporally >distinct closed world -- and one may say that independent of >temporal progression it is not a closed world, but that just >doesn't cut it insofar as software operation is concerned. That term 'closed world' has a very particular meaning. I think that you are using it informally, but that is a very risky usage, as anyone with a computational logic background may well misunderstand you. If you really do mean to use it in the technical sense, then you really are plain knock-down wrong. The knowledge that it has at hand is limited, of course, but it need not, and often does not, and in RDFS certainly does not, constitute a closed world in the technical sense, where for example it would be valid to conclude from the absence of a piece of data that it is false. >The benefit of RDF is that it allows for transparent progression >along the sequence of temporally distinct closed worlds without >modification to the software logic. The fact that the logic is monotonic - transparently progressible, an elegant way to put it - is why the worlds cannot be taken to be closed. > >Whether or not this is within or outside the scope of this WG >is unclear to me, and probably beside the point anyway... > >> > > >This is of course, presuming that the type is defined locally >> >> >and a range is defined, otherwise the test can't even be made. >> >> >> >> What sense of 'locally' do you have in mind? (Local to what?) >> > >> >See my glossary at the start of the X proposal I just sent out. >> >> You don't define the term there either. > >I do. Here it is again (with the clarification of property value >versus data type value): > > >local type > > A data type associated directly with an occurrence of a > property value serving as the object of a statement That doesn't define it, since obviously 'local' means just as much or as little as 'directly' means, and you don't define that either. I presume you mean these terms to be understood in a syntactic sense, so that 'local' means something like 'syntactically close to'. But in RDFS there is no notion of name scope, so the usual CS local/global contrast has no precise meaning (everything is 'global' in this sense, strictly speaking.) > > > >> >> >So the constraint fails >> >> >> >> Why? Nothing 'fails' here; you just have incomplete information. > > > >> >Right, sorry for sloppy language. The constraint cannot be satisfied >> >and therefore the test fails. I.e., insofar as a system that needs >> >to make a decision, inability to confirm the validity of a value >> >is the same as an invalid value. >> >> No, it is not the same. This is like saying that larger is the same >> as smaller because they both imply not-equal. > >From the viewpoint of a computer system at a point in time, it >*is* the same. For some systems, possibly, but not for all. >This is not about philosophy, it is about executing >instructions that accomplish some useful result. I agree, but I suspect that I have a broader view on what kinds of instructions might be permitted. In particular, I would explicitly include instructions which implement a range of reasoning engines, and indeed regard those as central. BTW, I perceive that you use the word 'philosophy' as a rhetorical tool to undercut an opponent, a common tactic among engineers. I would advise against getting involved in a game of rhetorical oneupmanship, however. >Please stop philosophizing these issues. I am not 'philosophizing' anything. I am simply being minimally precise. >We are not dealing with >the "UNIVERSE", we are dealing with a set of explicitly reified >statements about some universe which are intended as input to >software applications which execute instructions that accomplish >some useful result. Thank you for your insightful lesson in semiotics. I marvel at your grasp of these basic principles, so elegantly expressed (for an engineer). > > > > >as it should, since in this case, an RDFS >> >> >processor cannot satisfy that foo:bar is a subClassOf xsd:integer >> >> >and the data is rejected as unreliable. >> >> >> >> NO!! Absolutely not. You cannot 'reject' data as unsuitable just >> >> because it is incomplete. New data might arise at any time. >> > >> >YES! YES! YES! ;-) >> > >> >If my system needs to make a decision, and it can't determine if some >> >value is acceptable, then it has every right to reject that value >> >as suitable for the task at hand. >> >> What task does RDF(S) ever 'have at hand'? > >Why do you keep interpreting "system" as meaning "RDF"?! > >system != RDF > >A system, or application, is a set of instructions executed by >a computer. RDF provides an expression of data that may be >meaningful to those instructions. > >> I really don't have time to argue this very basic point about >> nonmonotonicity with you. RDFS is a monotonic reasoner, period. To >> change that would take us WAY outside our charter, and in any case I >> strongly believe it should not be changed. > >I honestly don't think we are talking about the same things here. > >> >Yes, that knowledge may change, but inability to verify a critical >> >test due to insufficient knowledge is the basically the same as the >> >test failing on sufficient knowledge insofar as real time decisions >> >are concerned. >> >> I disagree strongly. > >Then I don't think I can ever hope to get you to understand >anything of import in my postings, I had already given up, my dear fellow. > because if you don't get >that, you probably won't get any of the rest. > >Sorry if that's a bit harsh. I'm sure you could make equally >valid criticisms of my inability to understand or express myself >in mathematics. > >Please try to re-read the above assertion, in terms of the >last clause that begins with "INSOFAR AS" which you seem to >miss in your interpretation of what I am saying, taking my >meaning as the assertion without that final qualifying clause, >which is of course not the assertion I'm making. But you do seem to be saying that for ANY software application that this equivalence holds, and that is not the case; there are pieces of software (some of them implemented by members of the WG) which are concerned with the distinction that you insist is meaningless. > > First, you havn't said what you mean by 'test' >> and 'fail'; > >Sorry. These are common software engineering terms. I hadn't >expected to have to define them explictly. First, we are not doing software engineering here (as I believe you have been at some pains to emphasize); but more to the point, you need to say why these distinctions are relevant to RDFS. > >> but insufficient knowledge is NOT the same as incorrect >> knowledge, and I insist that we do not make the basic error of >> confusing them. > >I'm not confusing them. See the qualifying clause beginning >with "INSOFAR AS". > >Saying that two things are functionally equivalent in a >given context is hardly confusing them (especially since >you must differentiate them first in order to define their >equivalence, eh?) > >> > >> >> >That's what constraints >> >> >are for. Right? >> >> >> >> Who mentioned constraints? >> > >> >Ummm... the RDFS Spec. >> >> Ah, I see. But it is careful to avoid the implications that you are >> putting on the usage of the term (Section 3, 2nd para): >> >> "RDF Schema provides a mechanism for describing such constraints, but >> does not say whether or how an application must process the >> constraint information. For example, while an RDF schema can assert >> that an author property is used to indicate resources that are >> members of the class Person, it does not say whether or how an >> application should act in processing that class information. We >> expect that different applications will use these constraints in >> different ways - e.g., a validator will look for errors, an >> interactive editor might suggest legal values, and a reasoning >> application might infer the class and then announce any >> inconsistencies." >> >> It is clear that as far as RDFS is concerned, a 'constraint' is >> simply an assertion about ranges and domains. > >Yes. An assertion, but not a statement. ?? You have completely lost me. What distinction are you making here? As far as I am aware, an assertion MUST be an assertion of a statement. >A constraint does not impart >*ANY* properties on the resources themselves! ? So anything will satisfy any constraint? Hardly seems worth making all this fuss over, then. >A constraint only says (prescribes) what should be, not what is. That distinction is completely invisible in RDFS. Nothing in the RDFS syntax or the RDFS data model or the RDFS semantics makes this distinction. I do not mean to assert that it is meaningless, but that it can only have meaning to something outside RDFS. Pat -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Wednesday, 14 November 2001 13:15:28 UTC