- From: Chris Bizer <chris@bizer.de>
- Date: Tue, 9 Mar 2004 12:18:22 +0100
- To: "Pat Hayes" <phayes@ihmc.us>
- Cc: "Patrick Stickler" <patrick.stickler@nokia.com>, <phayes@ihmc.us>, <www-archive@w3.org>, <jjc@hplb.hpl.hp.com>
----- Original Message ----- From: "Pat Hayes" <phayes@ihmc.us> To: "Chris Bizer" <chris@bizer.de> Cc: "Patrick Stickler" <patrick.stickler@nokia.com>; <phayes@ihmc.us>; <www-archive@w3.org>; <jjc@hplb.hpl.hp.com> Sent: Tuesday, March 09, 2004 6:11 AM Subject: Re: Named graphs etc > >Hi Patrick, > > > >>That said, I'm starting to appreciate some of Chris' arguments about > >>all statements being asserted, no matter what. > >> > > > >The argument isn't that they are all asserted, but that they are uncertain > >until the user applies a trust function to them. > > That seems inconsistent with general Web architectural ideas, though. > I publish some RDF, but what it means isnt determined until you read > it and apply your trust function? If we take current RDF, the meaning is determinated without a trust function, because a shared conceptualization is assumed. If we take into account that people might have a different understanding what a URI/concept/term means, a information consumer would even need a trust function to decide if he assumes the publisher has the same understanding of a URI. I personally wouldn't to that far, but follow TAG and generally assume a shared conceptualization. Shouldn't I have some say in the > matter? I'm the one doing the publishing. You are free to ignore me, > of course, but what I assert is surely up to me to decide. > Total agreement. But what is asserted to you, might not be asserted to me. > >I think it is a three step > >process: > >1. Graphs published on the Semantic Web are not asserted > > Well, the trouble is that most folk think that they are being > asserted, at present. So we have to preserve this understanding of > current normal usage. > See other mail. > >but uncertain to > >the user. > >2. Before a user does something with the information, he applies a > >subjective and task-specific trust function (or policy) to the information. > > Is this an architectural requirement, or just sound practical advice? > Advice. > >There is a wide range of different functions possible which take provenance, > >the author's reputation, related information published by other authors into > >account. > > Again., this sounds like a private matter for people to decide, not a > Web matter requiring protocols. > I partly agree. The decision is a private matter. What's a Web matter is designing a language which allows us to express the information relevant for the trust decisions in an efficient way. For example named graphs :-) > >3. After applying the trust function, the user treats the information as > >asserted, keeping in mind that there is still the risk that it is wrong. > > > >>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? > >> > > > >Not a strict requirement. I think a trust architecture shouldn't strictly > >require anything but use all trust relevant information it can get. > > > >There are different possibilities how provenance information could be > >attached to graphs: > >1. The author of the graph attaches provenance information and might also > >sign the graph. > > Is this required? What happens if a graph has no provenance attached? > It depends on the user's trust policy. If the policy requires provenance information e.g. "Only information from authors on my web-of-trust" than the graph would be filtered out. If the policy is "Take all information which doesn't contradict with other information" the missing provenance wouldn't matter. > >2. The crawler (or other information access architecture) that collects > >published information adds the information where it found the data. > > Is there any requirement that provenance information provide a route > back to the source, or identify a Web resource as the source? Or > could something like a simple timestamping count as a provenance? In > general, what is the intended purpose of provenance information? > Timestamping would count, but more sophisticated information would also allow more sophisticated trust policies. > Is it information, or better considered meta-information? Can the > provenance info be accessed separately from the graph itself? Yes. > > > > >This information can afterwards be used in trust evaluations like "Use only > >data that has been signed by authors I know" or "Use all information, no > >matter if it is signed and not matter from which source or author it > >originates". The first policy is obviously stricter. > > Policy reasoning can get very complicated, particularly as policies > can be defined by OWL ontologies themselves. Yes. On larger amounts of data only certain policies will be solvable, others won't. How deep do we want to > get into this stuff? > I see the trust layer more as an application domain for named graphs. So for defining named graphs we don't have to go too far. Chris >The attached WWW2004 poster describes these ideas in more detail. > > > I'll take a look. > > Pat > > > > >Chris > > > >Jeremy: You will get the paper outline this afternoon. > > > >Attachment converted: Betelgeuse:bizer-www2004.pdf (PDF /prvw) (000CE573) > > > -- > --------------------------------------------------------------------- > 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 > > >
Received on Tuesday, 9 March 2004 07:16:39 UTC