Re: Named graphs etc

>On Mar 09, 2004, at 23:13, ext Pat Hayes wrote:
>
>>>
>>>One thought that occurred to me is that it might be cleaner/better to
>>>bootstrap the trust architecture using a specialized vocabulary which
>>>applies *only* to the graph in which statements using that vocabulary
>>>occur.
>>
>>that is essentially a 'this graph' naming function, right? "This 
>>graph asserts..."
>
>Correct.
>
>>
>>>
>>>This could also serve to allow folks to specify whether a graph is
>>>asserted or not.
>>
>>I'm coming to think that we need to provide for separating out a 
>>graph from its assertion. Example: A publishes and asserts a graph, 
>>but B wants to refer to it without (re) asserting it (maybe B wants 
>>to argue with it). So B must be able to refer to the graph and its 
>>content without referring to the assertion of the graph. So there 
>>has to be a conceptual distinction between the published (named) 
>>graph and its assertion.
>>
>>(Quick side question: do named graphs allow one to publish a 
>>reference to a graph without publishing the graph (never mind about 
>>asserting)? that is, can I say " a graph called "ex:myprivategraph" 
>>exists but I'm not going to show it to anyone" ??)
>
>I don't see why not. People frequently refer to their private
>parts and make claims about them without whipping them out
>in public ;-)

Clearly you spend too much time in bars, Patrick.

>
>>
>>Back to main thread. But unless we prove for some kind of 
>>publish-as-assertion, we can't get off the ground. So, suggestion 
>>(putting together various ideas, including Patrick's below):
>>
>>0. Asserting is a relationship between documents (? resources? 
>>agents who publish documents? owners of resources? whatever....) 
>>and graphs.
>>
>>1. Primitive asserting is done by (publishing) a document with an 
>>asserting tag.  and which which contains a(n instance of a) graph. 
>>That document asserts that graph.  You need an asserting tag to get 
>>the whole process started, so asserting isn't something that can 
>>happen by accident.
>
>Right. Though
>
>(a) I think/hope that a specialized vocabulary could be used in the graph
>instead of in the serialization

See other messages for why I think this can't work.

>
>(b) I'd like to see the machinery generalized to graph qualification of any
>kind, including assertion, authentication/signing, scope/context, precision,
>etc.

Yes, I assumed it could be. But lets not set out to provide the full 
vocabulary for this just yet.

>
>>2. But, in addition, one asserted graph can assert another graph, 
>>by reference using the name. In this case the asserter of the first 
>>graph asserts the named graph.
>
>I don't buy this. Allowing one graph to assert another allows one person to
>modify the intended purpose of someone elses graph. If I publish a graph
>but do not assert it. Nobody should be able to publish another graph
>having a statement asserting my graph.

BUt they already can,  by importing it into their graph. You can't 
stop this happening, so why not try to use it?

>
>This is why I limit the interpretation of that special boostrapping
>vocabulary, members of x:GraphQualificationProperty, to the graph
>in whch they occur.
>
>The x:thisGraph term may prove too troublesome, and we may have to
>require explicit graph naming and explicit use of graph names, but
>still, qualification of a graph should be limited to the graph (or
>document by which the graph is published) and not allow "infection"
>from other graphs.
>
>This should be a fundamental principle of the boostrapping machinery:
>all graphs stand alone insofar as their qualifications are concerned.

Theres no infection involved. Graphs express content. If I assert 
your graph, I'm just endorsing your content. Nothing follows about 
YOUR attitude to that content, and the content isn't changed.

>
>>So I can assert something that is published and named, even if the 
>>thing I'm asserting wasn't asserted by its own publication. Someone 
>>else can deny it, maybe, and someone else can say something about 
>>it without taking any particular stance towards asserting or 
>>denying it. The graph expressing the content is just sitting there 
>>being referred to.
>
>Nope. Don't like it.

Well, you might not like sunshine either. Are you saying that its 
false? graphs DO just express content: thats what the RDF specs are 
all about.

>
>>
>>Note, if A asserts B and B asserts C, A does not necessarily assert 
>>C. Assertion is only done explicitly, not by transitive closure.
>
>Eh? So, if I'm reasoning over some set of graphs A, B, and C, I have to
>keep track not only of whether A, B, or C are asserted but *how* they are
>asserted, and perhaps one conclusion follows per statements in A but don't
>follow per identical statements in C because of where/how each graph was
>asserted? Yikes!

If we are going to talk ABOUT assertings, then yes, its important to 
keep track of WHO is the asserter. Patterns of reasoning about 
assertions can get very complicated (he said that she said that Joe 
denied the report that Bill had told Haley that...) .

Hey, you are the one who wants to put this stuff into the graphs: 
what did you expect was going to happen? Just using RDF we can have 
reasoning about classes of asserters. In OWL we will have derived 
classes like "agents who have asserted more than five graphs which 
have the value ex:spam of the property ex:BS-Classification".

>
>I think it would be far simpler, and more than sufficient, to allow the
>authority of each graph to specify whether a given graph is or is not
>asserted, and then build trust "filters" based on top of that foundation.

Ok, I tend to agree. But then don't do it by putting assertions about 
asserting into the graphs: do it by some external tag or bit or flag. 
Keep it embedded in some simple piece of machinery. Once its in the 
graphs we have no control over what users and reasoners can do with 
it.

>
>>On the other hand, if B says that A asserts C, and A asserts B, 
>>then A asserts C; that is, assertion *by A* is transitive.  Also, 
>>if A asserts B and B imports C, then A has asserted C.
>>
>>3. A graph can do both things at once, if it wants to. That is, it 
>>can be asserted with a tag, and it can say of itself that it is 
>>asserted. This is a very unambiguous way to assert yourself.
>
>Why couldn't it simply say of itself that it is asserted,

It can, but that doesn't get it asserted. (If it is asserted, then it 
says it is, which is redundant already: if it isn't asserted, then 
its not saying anything, so what it would say if it were asserted 
isn't relevant.)

>  and we can
>do away with the need for the tag/attribute entirely?
>
>>
>>It can also, BTW, say of itself that it does not assert itself, 
>>which is odd but not paradoxical, since asserting isn't transitive 
>>(unlike importing). Even if A does not assert itself, B can assert 
>>it; and this can make sense even if A and B are the same asserter 
>>(eg owned by the same owner doing the assertion.
>
>I still don't like external assertion. True, a given agent can 
>pretend that a graph
>is asserted, regardless of what the owner of the graph says, but 
>that is different
>from actually affecting the assertiveness of a graph in general by 
>agents syndicating
>numerous graphs and not realizing that one graph asserts another 
>graph, which otherwise
>would be disregarded by the agent as unasserted...
>
>I think here be lots of dragons...

Well, I agree there are dragons, but they happen as soon as you let 
graphs say that graphs assert. There's no way to keep a triple acting 
just like a local document tag: triples encode propositions, and can 
be sent all over the planet and inferred from other triples in odd 
ways.

>
>>
>>The only contradictory case is a graph *tagged as asserted* which 
>>says explicitly that it does not assert itself. And in this case we 
>>could just say that this is an assertion of a contradiction, and 
>>assertions of contradictions are content-free. Note this is not a 
>>logical (= RDF-semantic) contradiction, since the crucial asserting 
>>tag isn't visible from within the RDF itself.
>
>Yet if we simply do away with the tag/attribute, then such 
>contradictions would not occur.

They can be reproduced in the triples if the triples have assertional 
import by themselves.

>
>>
>>4. An assertion can be done by a pair of graphs, A which expresses 
>>the content (and is not asserted) and B which asserts A and is 
>>asserted, as in 2. above. But also, this can be modified/extended 
>>so that A tags B as its warrant, providing a kind of secure 
>>external assertion, a warranted handshake. Note that since each 
>>refers to the other, the warrant can only be used once in this case.
>
>But if you only first had graph A, which is unasserted, then you 
>could not IMO rightly
>interpret the statements of A to get the reference to its warrant 
>graph B, which then
>asserts A.

No, you could still get the actual reference: that just uses the URI 
layer of the Web. Then once you get from A to B, B asserts A for you.

>
>I like the idea of warrants, as a means of stronger 
>authentication/validation, but not
>as a mechanism for assertion.
>
>>
>>---
>>
>>All of these cases provide for a separation of content from 
>>assertion, since  A can refer to B by name without being understood 
>>to re-assert B; this allows A to express doubt about another 
>>assertion, say. (If A wants to re-assert B, it can do so 
>>explicitly.)
>>
>>I think this provides for most of what anyone could want.
>
>And a good bit of what we might not want ;-)

I think you have that whether you like it or not.

>
>>It can take existing usage and fix it up without changing any 
>>graphs (other maybe than to give them names: we can use their URLs 
>>for now :-)
>
>Yes, but it requires changes to RDF/XML, which is probably far more costly
>than most other approaches -- in terms of process/politics/acceptance
>rather than actual technical effort.

OK, then I'll modify my proposal. Instead of a property on the RDF 
element, we'll invent a new, enclosing, element with the property. 
RDF/XML is unchanged. but now there is *asserted* RDF/XML which has 
the form
<RDFA pubType="assert">
<some RDF/XML>
</RDFA>
and similarly for quoted RDF, questioned RDF, whatever. Will that be OK?

Hmmm, I guess not, on reflection. Damn, it seems crazy that the part 
of RDF that is absolutely the shittiest and least important aspect of 
it is the one that we absolutely cannot change. How did THAT happen? 
Isnt XML supposed to be HELPFUL ????

Pat

>
>>>
>>>Thus, the name of the graph is used in statements within that graph, and
>>>statements using a special property, e.g. x:isAsserted would
>>>only be interpretable if the subject of the statement is the
>>>same graph containing that statement.
>>
>>No, let it work for any pair. Then B can assert A even if A doesn't 
>>assert itself. Which makes perfect sense.
>
>It makes sense, but I think creates far more problems then it solves,
>per my comments above.
>
>Patrick
>
>--
>
>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

Received on Wednesday, 10 March 2004 14:42:27 UTC