- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Sun, 15 Feb 2004 09:04:08 -0500
- To: Mark Baker <distobj@acm.org>
- Cc: www-ws-desc@w3.org
On Feb 14, 2004, at 10:25 PM, Mark Baker wrote: > On Sat, Feb 14, 2004 at 07:16:05PM -0500, Bijan Parsia wrote: >>> It gives you >>> exactly the kind of extensibility you seem to require. >> >> Actually no. He requires "ignore unknowns" extensibilty *with* >> validation. > > Right. Granted, OWL can't express all the constraints of XML Schema, > but many of them it can. Technically, I believe that it can express almost none of them. It expresses *analogous* constraints, but one must be *very* careful not to be misled by the surface similarity. If nothing else, *what* they are constraining are radically different. > Actually, thinking more about it now, the > "name" example is, I think, an example of the kind of constraint that > OWL/RDFS can't express (limits on container structure). No, the problem is that an OWL class definition can't (in most cases) mandate the presence of information in a knowledge base (kb) or document. But for data validation, that's exactly what you want to do. For some discussion of the problmes see this thread: http://lists.w3.org/Archives/Public/public-sws-ig/2004Feb/0037.html where I discuss the "Decker problem". I should be posting another more overviewy message soon. Perhaps I should put up a web page on it :) Oh, more here: http://lists.w3.org/Archives/Public/public-sws-ig/2004Jan/0084.html > If the example > were Person/name/age then you could use OWL's cardinality mechanism. ? I don't think so. Suppose you had the class Name. This is a perfectly find OWL class. Add the restrictions that Name has exactly one firstName. Now consider these two RDF datasets: _:x rdf:type Name. and _:x rdf:type Name; firstName "Bijan". Both are consistent with the class definition. OWL (and RDF) are *designed* to work with incomplete information. In the first kb (with the class definition) I know that the name *must* have a firstName (in *the world*), but not what it is. > Ok, so maybe the fit isn't perfect, but it should work in many (most?) > cases. Hardly any, actually. And the pain would be high. You really need a different language of constraints on RDF, if this is what you want. But if that's true, you might as well go with a different language of constraints on XML. Actually, I believe schematron does the job. >> If you try to validate a specific profile of RDF/XML, you >> could have similar problems. > > What's a "profile" of RDF/XML, and what kind of validation do you mean? For example, you might want to constrain your documents to socalled "nTriples in RDF/XML" (I.e., one top level rdf:Description per triple, no abbreviations except rdf:resource for the object) where you only have properties from the dublin core. So, <rdf:Description rdf:about="#article1"> <dc:creator>Bijan Parsia</dc:creator> </rdf:Description> <rdf:Description rdf:about="#article1"> <dc:title>A simple way to solve all problems</dc:title> </rdf:Description> <rdf:Description rdf:about="#article1"> <dc:relation rdf:resource="#article2"/> </rdf:Description> You could fairly easily write a schema that rejected any document that used non dc properties in this format. So you could validate that the graph contained only assertions of dc properties, and even a certain number of ground ones. Cheers, Bijan Parsia.
Received on Sunday, 15 February 2004 09:04:08 UTC