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

Re: Named graphs etc

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 10 Mar 2004 10:09:32 -0600
Message-Id: <p06001f3abc74e7fc1ab2@[10.0.100.76]>
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Cc: Chris Bizer <chris@bizer.de>, Patrick Stickler <patrick.stickler@nokia.com>, ext Pat Hayes <phayes@ihmc.us>, www-archive@w3.org

>Mindful of time pressure ...

OK, but...

>I suggest the following approach for our paper ...
>
>1) introduce a property
>    rdfx:assertedBy
>
>whose domain is graphs and range is agents union documents.

It seems to me that no such approach can possibly fly.

The task is how to get graphs asserted. Asserted means that you are 
supposed to accept the truth of the statements in it, if you believe 
the asserter. If a graph is not asserted, in particular, you are not 
supposed to take it being true or making any claims: its just a graph 
for you to contemplate. It doesnt even have statements in it, just 
formulae: they only get to be statements when they are asserted. An 
unasserted graph is just wallpaper. So now, if asserting a graph is 
done by making a statement in a graph, how do ANY graphs EVER get 
asserted? Triples with that property in them can occur in a graph out 
the wazoo, but unless the graphs containing those triples get 
asserted, there's no reason to think that they are saying anything 
about anything: they are just there for you to contemplate. So they 
don't cause any asserting to be done.  There HAS to be something 
OUTSIDE the graph which indicates that the graph is being asserted, 
before there is any reason the accept the truth of any graph at all.

Having the graph refer to itself is no help: it you arent inclined to 
take it as being asserted, what it says about itself has no influence 
on you. If you are so inclined, then having it say its asserted is 
redundant.

>
>2) include examples in which a PKI signature of such a statement is 
>included in which the asserting agent signs the statement of 
>assertion
>
>3) include text that describes the bootstrapping problem and note 
>that the example provides one mechanism for bootstrapping trust, but 
>noting that the HTML web largely works, providing adequately trusted 
>information, without widespread use of such mechanisms

I'm not talking about bootstrapping trust, but bootstrapping 
assertions. If publication is not assertion then right now, NOTHING 
is asserted in any RDF anywhere. How do we get this whole RDF Web off 
the ground?

>
>We might also want an rdfx:notAssertedBy property for explicitly 
>stating that a graph is fictional, in the eyes of its author (or 
>anyone else).
>
>4) We could include text that suggests that documents published in 
>RDF/XML should be regarded by default as being asserted by their 
>authors, and point to the social meaning discussion to show that 
>this was never adequately resolved.

??? But if we do that, what is the new property FOR? What 
functionality does it add?

>
>To me, at least, that provides enough mechanisms for the publishing 
>of assertional intent, at least for most actual usage.
>
>I think Chris is correct to indicate that the reading agent's trust 
>is a separate problem

Agreed.

>that may be increased by the use of signatures but not increased to 100%.
>
>I think we should address this

Why do we need to address it? Seems like too large an issue for one 
short paper. Lets be casual whatever we do.

Pat


>by postulating a trust layer, which takes as input a set of named 
>graphs and provides as output a single graph, being the merge of 
>some of the input graphs, (those which the trust layer chose to 
>trust). Chris provides some potential trust metrics, and we include 
>the PKI signature as one of the factors which may be considered.
>
>
>Jeremy


-- 
---------------------------------------------------------------------
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 Wednesday, 10 March 2004 11:09:35 UTC

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