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

Re: Named graphs etc

From: Chris Bizer <chris@bizer.de>
Date: Tue, 9 Mar 2004 12:18:22 +0100
Message-ID: <002701c405c8$3ea49cb0$1f12fea9@named4gc1asnuj>
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

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