- From: Graham Klyne <gk@ninebynine.org>
- Date: Sat, 24 May 2003 19:46:19 +0100
- To: Brian McBride <bwm@hplb.hpl.hp.com>, rdf core <w3c-rdfcore-wg@w3.org>
At 13:12 24/05/03 +0100, Brian McBride wrote: >Danbri and I have been discussing issue: > > http://www.w3.org/2001/sw/RDFCore/20030123-issues/#vass-01 > >Its quite hard to get a crisp quote of the problem from the email thread >but I think the issue is that schema does not layer the same way as, say >UML, in that classes can be members of themselves and one can take a >subproperty of subPropertyOf or rdf:type. > >I think we need to clearly articulate the advantages of the design choice >that has been made. I'm not convinced of a *need* to do this. (But if we can, then fine...) I think the main issue here is that the non-layering is a fundamental feature of the RDF we were tasked to clarify. I think we don't really have any discretion to consider other design approaches. >I suggest the following reason for the design choice and why we should not >change. I welcome comments and other suggestions: > >1) RDFS is designed to be a lower layer for the semantic web stack that is >extended by restriction. All structure at this layer is imposed on all >higher layers. A layered structure is not necessary and the principle of >minimal restriction suggests it should be omitted. > >2) A further consideration is the cost of change at this point. To switch >to a layered approach would require a massive rethink and would affect not >only the RDFCore specs but also OWL. Only a show stopping problem with >the current design could justify the cost of such a change. This might be underscored by mentioning the large number of implementations that currently depend on this model (esp schema uses where rdfs:Class is treated as both resource and class, and is a member itself, etc.). >We note that it is possible to build more strictly layered languages on >top of RDF(S), Owl DL/Lite being examples. A good point to make, I think. #g ------------------- Graham Klyne <GK@NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E
Received on Sunday, 25 May 2003 05:16:16 UTC