W3C home > Mailing lists > Public > www-archive@w3.org > March 2004

Re: Named graphs etc

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 8 Mar 2004 23:11:46 -0600
Message-Id: <p06001f28bc72ffa0a408@[10.0.100.76]>
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>

>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? 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.

>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.

>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?

>There is a wide range of different functions possible which take provenance,
>the autor'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.

>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?

>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?

Is it information, or better considered meta-information? Can the 
provenance info be accessed separately from the graph itself?

>
>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. How deep do we want to 
get into this stuff?

>
>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 00:11:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:32:25 UTC