- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Fri, 25 Oct 2002 15:52:04 -0400 (EDT)
- To: sandro@w3.org
- Cc: macgregor@ISI.EDU, www-rdf-interest@w3.org
From: Sandro Hawke <sandro@w3.org> Subject: Re: Meaning of URIRefs Date: Fri, 25 Oct 2002 14:51:06 -0400 > > > If I understand Sandro's position correctly, then if I use a URI > > foo:bar (when oh when are we going to finally add qnames to RDF?), > > I'm committed to "believing" all of the information > > stored in the corresponding document. > > Right. > > I thought I'd addressed your two points in my reply to Peter; I'll try > again. > > > Below, Sandro > > tempers that by saying you agree to all of the 'definitional' > > information. There are at least two problems with Sandro's > > proposal. One is that long experience with KR and DL systems > > indicates that a line between 'definitional' and 'non-definitional' > > is completely arbitrary, and therefore untenable as the basis > > of an RDF convention. For example, I would hope that we > > would all agree(?) that an rdf:type statement is 'definitional' (how > > else do we define constants like PI?). The statement > > (foo:GeorgeBush rdf:type foo2:Person) > > is perhaps non-controversial. However the statement > > (foo:GeorgeBush rdf:type foo2:SittingUSPresident) > > is not definitional. A fanatical Gore supporter might claim that > > Al Gore is still the rightful US President. > > > > Continuing, suppose the retort is that 'rdf:type' is NOT a definitional > > statement. Then we have a disagreement over what should be > > definitional and what should not, which just backs up my claim above. > > My proposed split-off of definitional information is NOT intended to > be done mechanically. I tend to agree with your point that dividing > "definitional" and "non-definitional" is, in the end, arbitrary. > > I propose, rather, that the split be done by authors and publishers. > If you are "coining" a URIRef which you want others to use, you should > provide good definitional content, not contaminated by any other > information. You should perhaps also make strong commitments to > steward that definition, but that's a different issue. The point of Bob's message, I think is that the only safe place to draw the line is at (foo:GeorgeBush rdf:type rdfs:Resource) Any other drawing of the line can be objected to. I strongly agree with this reasoning. > > A second problem is that I might want to disagree with a statement > > by citing the URI, and Sandro's proposal appears to prevent that. > > If I want to state that the individual denoted by 'foo:GeorgeBush' > > is not the president, is not a Person, or whatever, I'm going to have > > to reference 'foo:GeorgeBush' in my refutation. > > > > I imagine that Sandro might like to amend his proposal to allow > > quoted references to URI's without committing to their definitions? > > If we had quotation. Otherwise, it would be hard to express (in RDF) > > a disagreement with how someone else had constructed their ontology. > > I don't have to amend my proposal to allow this, since nothing I said > prevents it; you just have to keep such quoted URIs inside string > literals rather than use them as node or arc labels on your RDF graph. > > But, again, there is a way to point to something without using a > quoted URI or a URI at all: you can refer to it by some collection of > properties which identify it unambiguously. This is a technique often > used in RDF for identifying people. It requires more difficult > reasoning, but if for some reason you can't obtain or create good > definitional content, it works. This proposal has even more problems. How can I talk about George-Bush-the-lesser without commiting to some ancillary facts about him, such as the claim that he is the 43rd president of the United States? Even worse, I have to commit to some well-known notion of president and United States, which I may be unwilling to do. (I'll let the use of 43 go by, for now at least.) > -- sandro Peter F. Patel-Schneider Bell Labs Research
Received on Friday, 25 October 2002 15:52:22 UTC