- From: Thomas B. Passin <tpassin@home.com>
- Date: Fri, 19 Oct 2001 21:12:28 -0400
- To: <www-rdf-interest@w3.org>
[Peter F. Patel-Schneider] > From: "Thomas B. Passin" <tpassin@home.com> > Subject: Re: RDFCore Update > Date: Thu, 18 Oct 2001 23:52:44 -0400 > > > [Peter F. Patel-Schneider] > > > > > > > > I don't know how you could handle a prescriptive meaning for rdfs:range in > > > an open environment. You certainly can't say that the target object has > > to > > > belong to the range when the triple is read because there is no notion of > > > order in RDF. > > > > But that only means that you cannot validate the graph until the whole thing > > is constructed. That's no different that for XML Schema itself. Why do you > > think that would be unworkable? It would let you separate graph > > construction and validation into separate processing layers, which should be > > good not bad. > > > > Cheers, > > > > Tom P > > But the approach of waiting introduces non-monotonicity. > > When do you know that you have everything you need? RDF allows information > to be accumulated from multiple sources. If you say that you ``validate'' > when you have everything you know about, then you can have the following > situation: > > An RDF system looks around to find all available information, and finds: > > John sister Susan . > sister rdfs:range Person . > > It complains that Susan is not (known to be) a Person. (How? Well the only > way so far is to have no possible models.) > > The user points out a new source of information that states > > Susan rdf:type Person . > > and now the RDF system is perfectly happy. Voila---non-monotonicity. Hold on a minute, Peter, not so fast. As I understand it, monotonocity means that if you add additional facts to the universe of interest, you do not contradict already established facts. In this case, you have not added any inconsistency, so no non-monotonicity (gad, that's a terrible phrase - did I really write it?). I agree that you could have done (Susan rdf:type Dog), but on the web, that is always going to be a real possibility anyway and has to be dealt with. Back to your example, say the processor finds your first statement first, it would either not try to type match (since it has no information) or it would infer that Susan must be a Person. This is akin to "lax" validation in XML Schema. If later it discovers some other type information about Susan, the processor must check and see if there is an inconsistency or not. Again, the possibility has to dealt with somehow. So I don't see why it is any different an issue that for any other assertions. I do agree that this argument supports the descriptive view over the prescriptive view. Now suppose that the type is an integral part of the label of a literal. The issue of knowing that Susan is a sister but not that Susan is a person doesn't arise (unless the literal value omits this fact), but the problem is just removed one step. Somewhere that datatype has to be defined, we hope in RDF, and because order of evaluation is not specified - as you pointed out, right? - who is to say that the processor would have discovered that type before it discovered Susan the sister? And even if this were handled, there could still be an inconsistency between the type as defined and the type as used in the assertion about Susan. So it seems to me that every point you raised would be an equal objection for the other approaches that are being discussed. On the other hand, I am a fan of Conceptual Graphs, and they do use the label block to specify the type. But it is assumed that the processor has already sucked up the classification of types, which is not the case here, is it? Cheers, Tom P
Received on Friday, 19 October 2001 21:06:59 UTC