Re: Named graphs etc

On Mar 10, 2004, at 21:42, ext Pat Hayes wrote:
>>
>> 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.

Well, certainly not *those* kinds of bars...  ;-)

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

See other messages for why I think it can ;-)

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

It's not about whether a given agent can treat my graph as asserted.

It's about whether a given agent may make a decision to treat my
graph as asserted based on something another agent said!

*I* say whether my graphs are or are not asserted. And while some
agent may still choose to believe some third agent over and beyond
what I say about my graphs is another issue -- but the authentication
and trust machinery should support the distinction about what the
owner of a graph says versus what some third party says about the graph.

And of course, you still have the infinite chain of asserting graphs,
where graph A is asserted by a statement in graph B which is asserted
by a statement in graph C which is asserted by a statement in graph D,
.... ad nauseum until at some point some graph is simply presumed to
be asserted in the absence of any explicit statement about assertion
in any graph.

Better, I think, to avoid that recursion and allow each graph to
be self qualifying and taken on its own terms, insofar as authoritative
qualification is concerned.

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

Sorry, I just don't accept that.

I could publish a graph having some statements about fictional products,
and explicitly state that the graph is unasserted (not believed to
be true) but provided for some other purpose, perhaps as an example.

If some third party says, no, that graph actually *is* asserted, i.e.
is intended to be considered as true, and yet another agent then
syndicates both graphs, takes mine as asserted, and includes links to
those fictional products in some registry resulting in a huge influx
of inquiries from potential customers -- that could result in monetary
loss -- just for publishing some graph that was never intended to
be taken as reflecting reality.

In short, I think the ability for one graph to "bootstrap" the 
statements
of another is a can of worms best avoided.

Furthermore, if you cannot allow a graph to be self qualifying, then
if you have three graphs, A, B, and C where A contains some misc.
statements, B says the source/authority of A is Bob and that A is
asserted and C says the source/authority of A is Jane and that A is
not asserted, then who is to say who the actual source/authority of
A is and whether it is or is not asserted? Shall we look then for
yet more graphs to find out the source/authority and assertiveness
of graphs B and C, and what about the source/authority and assertiveness
of those additional graphs?

It's like the old Chinese belief about the world being on the back
of a turtle... what's under the turtle? another turtle. it's turtles
"all the way down"...

I'd rather not have the trust architecture based on the idea that
"it's graphs all the way down..."

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

Yes, but we may choose to constrain our trust of statements
about graphs to those made in the graphs themselves and authenticated
in a reasonable manner.

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

But again, we can constrain certain decisions to statements made about
graphs within those graphs where the graphs are authenticated/validated
by reasonable means.

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

The external tag/bit/flag is provided by the semantics of the 
bootstrapping
interpretation of the particular graph.

Once a graph is accepted as asseted and authentic, the boostrapping 
statements
should be "safe" for normal RDF/OWL reasoning, and yet also *useful* as 
a
foundation for more comprehensive layers, for systems that preserve 
graph
membership of statements.

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

Right. We need the extra, special bootstrapping interpretation to allow
the graph to assert itself. RDF/OWL alone wouldn't suffice.

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

True, but also, triples having special predicates with special
intepretations if qualifying the same graph in which the statement
occurs, can provide the bootstrapping we need, while not impacting
normal RDF/OWL reasoning if such statements occur in other graphs.

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


;-)


Patrick


--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Thursday, 11 March 2004 06:16:40 UTC