- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Tue, 9 Mar 2004 10:57:08 +0200
- To: "ext Pat Hayes" <phayes@ihmc.us>
- Cc: <www-archive@w3.org>, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>, <chris@bizer.de>
On Mar 09, 2004, at 06:47, ext Pat Hayes wrote: > > --DS-5576863329265350185 > >> On Feb 27, 2004, at 03:13, ext Pat Hayes wrote: >> >>> We may, though, end up with an infinite recursion. I.e., we have >>> a graph X that is asserted. In order to say that X is asserted, >>> we have to have another graph X' containing a statement that >>> X is asserted. But if X' is also asserted, we have to have another >>> graph X'' with a statement saying that X' is asserted, etc., etc. >>> >>> Lewis Carroll was there first: >>> >>> http://www.lewiscarroll.org/achilles.html >>> >>> >>> ??? >>> >>> >>> >>> Nah, don't worry about it. Once you assert something, its asserted. >>> You don't need to assert the assertion. >>> >> >> Sorry, Pat. I don't follow you. >> >> If there is a graph X and a graph Y, and there is a triple in graph Y >> that says that graph X is asserted, yet we find no triple saying that >> graph Y is asserted, then is graph X actually asserted? If the triple >> asserting graph X is not asserted, then how can graph X be asserted? > > Maybe we are at cross purposes. I'm assuming that publishing a graph > amounts to asserting it. If not, then you are right: there is no way > to get something asserted by just publishing more statements about it, > if publication does not qualify as assertion. You have to have a plain > assertion somewhere to get the process started. > On the other side of the coin, if publication (or maybe, publication > in some mode or form) amounts to assertion, then there's no need to > add another graph asserting the assertion. That's what I meant in my > response above. > No. I was not presuming that publishing a graph equates to asserting it. Publishing a graph is simply that, making it publically available. How it is intended to be used or what its overall purpose is, is another matter entirely. This came up in the long debates about social meaning. TimBL wanted what you are suggesting, that if someone publishes a graph, they are accountable for the statements made therein, as automatically asserted. The problem with that, is (a) is publishing an RDF/XML instance the same as publishing a graph? (b) how can one publish a graph as an example, such that its purpose has nothing to do with the substance of any statements within it, yet use of the graph as an example requires manipulation of triples (not other forms of quotation, reification, etc.). The ability to explicitly mark a graph as asserted is, I think, a needed mechanism. Publication of a graph, or an RDF/XML instance, should not equate to assertion. > Either way, there's no utilility in having a graph X saying that > another graph Y is asserted. Unless X is asserted then it has no > effect on Y ( as you note); and if you can assert X in some way, the > you can do that to Y directly, so X is unnecessary (as I note). Right. Hence my recent proposal of a special vocabulary having intra-graph bound semantics, which can be used to qualify graphs. > >> That said, I'm starting to appreciate some of Chris' arguments about >> all statements being asserted, no matter what. >> >> I still have some questions about how to "bootstrap" trust, such that >> it seems there must be some requirement for each graph to contain >> statements reflecting its source/authority (a signature perhaps?) >> otherwise, how do you anchor your trust in terms of a given graph? > > There are folk who worry about this in other settings. I gather there > are recognized techniques, eg having a 'super' source which is trusted > by everyone and acts as a kind of World Bank for certifying trusted > signatures. Things like notary publics are useful as well. But there > dos have to be some kind of infrastructure for anchoring the trust in, > you can't just make it happen by asserting things. > Right. One way or another, you've got to bootstrap your architecture. But ideally, that bootstrapping machinery should be as lightweight as possible, pushing as much as possible into the scope of the RDF MT. It also should be as decentralized as possible. Patrick > Pat > > >> >> Patrick >> >> >>> Pat >>> >>> >>> -- >>> >>> --------------------------------------------------------------------- >>> IHMC (850)434 8903 or (650)494 3973 home >>> 40 South Alcaniz St. (850)202 4416 office >>> Pensacola (850)202 4440 fax >>> FL 32501 (850)291 0667 cell >>> phayes@ihmc.us http://www.ihmc.us/users/phayes >>> >> >> -- >> >> Patrick Stickler >> Nokia, Finland >> patrick.stickler@nokia.com > > > -- > --------------------------------------------------------------------- > IHMC (850)434 8903 or (650)494 3973 home > 40 South Alcaniz St. (850)202 4416 office > Pensacola (850)202 4440 fax > FL 32501 (850)291 0667 cell > phayes@ihmc.us http://www.ihmc.us/users/phayes > > > --DS-5576863329265350185-- > > -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Tuesday, 9 March 2004 03:57:06 UTC