- From: Dan Brickley <danbri@w3.org>
- Date: Tue, 30 Jan 2001 06:41:18 -0500 (EST)
- To: Ian Horrocks <horrocks@cs.man.ac.uk>
- cc: "King . Dany" <DKing@drc.com>, "'www-rdf-logic'" <www-rdf-logic@w3.org>
hi Ian, On Tue, 30 Jan 2001, Ian Horrocks wrote: > On January 29, Dan Brickley writes: > > > > On Mon, 29 Jan 2001, Ian Horrocks wrote: > > > > > > Syntactically however, it is... mostly (discrepancies: 1. RDF is requires > > > > acyclic subclass relations, DAML+OIL allows cyclic subclass relations; 2. > > > > DAML+OIL requires one syntax for cardinality to avoid exposed content, thus > > > > other equivalent and legal RDF syntaxes are illegal for DAML+OIL > > > > cardinality; 3. RDF allows only one range restriction per property, DAML+OIL > > > > allows multiple; 4. the "daml:collection" doesn't exist in RDF). > > > > > > 1 and 3 are likely to change in RDFS. > > > > Ahem! Pointer please to evidence for claim (1). Or a PaperTrail > > (http://www.w3.org/DesignIssues/PaperTrail). > > > > Regarding (3), my inclination is to agree (and also fix rdfs:domain). The > > important thing with domain/range is to define what they mean, not how > > many times one can write down statements using them. The RDFS prose gets > > this wrong imho. I agree. As an editor I can't change this without RDF working group sayso. We don't currently have an RDF working group, but I expect that situation to change shortly. Watch this space... > > There have been extensive discussions about (3) on the RDF list(s), > w.r.t. both range and domain, most/all of which led to the conclusion > that the original specification was a mistake and should be > changed. My claim regarding (1) is rather more doubtful. The evidence > is as follows: > > a) I spoke to Ora Lassila about it and he didn't raise any strong > objections. <shrugs/> Ora didn't raise any strong objections to the contrary position at the time either. As I remember (RDFS WG mail archive search seems broken currently) the decision regarding subclass cycles was explicitly brought to Guha and Ora's attention (as our resident KR gurus), and it got their OK. I originally proposed that we used reciprocal sub-class relations between classes as an idiom for representing class synonymy. This led to discussion of subclass loops, the decision to exclude them and thereby punt 'class synonymy' off to future RDF working groups. Others may remember this differently! The cycles thing could've gone either way. I can't profess a strong view on this, except to note that "likely to change" is a rather concrete claim. If only we make make a W3C REC from everything Ora didn't "raise strong objections to" the Web might be a more interesting place... ;) > b) The restriction is clearly senseless, so it is bound to be dropped > eventually. You're sounding more and more like TimBL! There are a world of reasons beyond the purely mathematical for making this kind of design decision. We might for eg consider the usability angle. RDF, DAMLOIL and the like are already rather tough for mainstream Web developers to get their heads around. Even though subclass cycles are not mathematically problematic, I suspect you'll agree they're a little counterintuitive for folk from non KR/math backgrounds. Similarly, the ability to generate a decent user interface from schema information is important; tree widgets are plentiful and a common UI metaphor; general graph viewers are less readily available and less well known. But I don't want to overstate my case. I'd be happy to see this constraint lifted. I'd be slightly happier to see the RDF-Logic community define some utility relations for class synonymy and the like, rather than overload the sub-class relation with this work. But either would do. BTW I wouldn't take "this is kinda dumb; therefore it will doubtless be fixed" as a guiding rule for predicting Internet standards evolution. Hopefully that'll be the case with domain/range. I'm yet to be persuaded re sub-class loops, though I'm inclined to believe whatever Ora says on this :) dan -- mailto:danbri@w3.org
Received on Tuesday, 30 January 2001 06:41:21 UTC