Re: Named graphs etc

On Mar 09, 2004, at 19:08, ext Pat Hayes wrote:

>
> --DS5724938971518013616
>
>> On Mar 09, 2004, at 13:18, ext Chris Bizer wrote:
>>
>>>
>>>> Is it information, or better considered meta-information? Can the
>>>> provenance info be accessed separately from the graph itself?
>>>
>>> Yes.
>>
>> Here's where I think we need to make an important distinction between
>> "authoritative" qualification of a graph and third-party qualification
>> of a graph.
>>
>> It may be the case that an agent trusts certain third parties, and 
>> even
>> may choose to trust statements made about a graph by a third party 
>> over
>> statements made about the graph in the graph itself (e.g. the owner
>> of the graph specifies a higher accuracy percentage than the 
>> more-trusted
>> third party, or the owner of the graph doesn't explicitly state that 
>> the
>> graph is asserted but the third party does, etc.).
>>
>> Note that the ability to consider third party statements about a graph
>> still doesn't preclude the need for a bootstrapping mechanism, since,
>> after all, one has to determine the trust associated with the graph
>> containing those third party statements as well...
>
> Interesting thought. Let me modify my earlier suggestion, or maybe 
> extend it. Asserting is publishing with a publishMode="assert" tag

OK. Or alternately, perhaps an intra-graph statement:

    x:thisGraph x:publishMode x:assert .

> (if tag omitted, publication is assumed as a SW default, but legal 
> tightness might require it).

I think that it will -- probably mandated by interchange policies which
(eventually) require graphs to be signed and in conjunction, their
assertion status explicitely stated. But that's another issue...

>  Alternatively, one can give a URI which points to another document 
> which acts as a 'publication warrant'; this might for example record 
> provenance information, give security key information, things like 
> that. And it can be stored on a secure server somewhere, safe from 
> harm, and providing a checksum to use as security against malicious 
> changes to the warranted graph. The publication warrant should itself 
> have a publishMode="assert" tag on it, and can refer to the original 
> graph by name, and can assert in RDF that it is warrant for the named 
> graph. This would be very hard to fake, and can easily be made 
> exponentially harder by adding more warrant layers referring to even 
> more secure sources of warrantability. The very fact that the warrant 
> URI is in a secure namespace uses the Web to provide a high degree of 
> security.

Hmmm.... yes, that's an interesting approach. Though it is just one
additional possible form of graph qualification that some folks
may choose to adopt. Yet it still requires that foundational
bootstrapping machinery (either semantic/vocabulary or 
syntactic/markup).

Consider that the bootstrapping mechanism could be a single class. 
Nothing
more. E.g. x:GraphQualificationProperty.

The semantics of this class, or rather, of all properties which are 
members
of this class, defines the special bootstrapping interpretation needed.

Then, different folks can create their own vocabularies of particular
instances of x:GraphQualificationProperty to e.g. refer to a 
'publication
warrant', or a graph signature, a checksum, or specify an authority, or
source, or precision/accuracy rating, etc. etc.

In each case, the interpretation of such properties would be constrained
to the graph in question, thus allowing the owner of each graph to
unambiguously qualify that graph in various ways.

And, if the semantics can be defined for x:GraphQualificationProperty,
it is immediately usable with all RDF serializations and query 
expression
languages.

I think it's safe to presume that adding XML attributes to RDF/XML is
out of the question, and simply adding them to TriX is not going to
greatly benefit the RDF community at large, so a vocabulary approach
seems the most promising (thanks, Chris, for getting me to think along
those lines...)

>
> Notice also that this entire thing can  be set up without any 
> publication actually happening until the publishMode property on the 
> warrant is set, and changing this value can 'turn off' the 
> publication; so this provides a kind of trusted-third-party control 
> over assertion: if you hold my warrant, then you can un-assert my 
> publications.  Of course I can just not refer to your warrant, but 
> then who is going to trust me?

Right. And that is also compatible with the vocabulary approach. The key
here is being able to authoritatively associate the 'warrant' with the
graph.

>
>>> 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.
>>>
>>
>> We at least seem to agree on this particular point.
>>
>> Cheers,
>>
>> Patrick
>>
>> (sorry, Pat, for being in a closer timezone to Chris and pre-empting
>> your right to first reply...)
>
> S'OK, I see this as a free-for-all in any case. One of the joys of 
> email is that you can interrupt without actually interrupting, if you 
> see what I mean.

Yup.

Patrick


--

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

Received on Wednesday, 10 March 2004 03:22:40 UTC