Re: Towards PROV-O Accounts

Jim,

At this stage, I can't say I find your argument compelling.  if anything, I draw 
the opposite conclusion to you:

Suppose there exists a graph which is signed by Tim.  What is it, actually, that 
time signs?  I would argue that (at the human-machine interface) it is a 
rendering of that graph - be it N-triples text or an RDF-a web page.  So I would 
think the signature should be attached to the rendering.  It then becomes the 
responsibility of the technicians (programmers, logicians, etc.) to establish 
evidence that the rendered graph that Tim signed conveys the same intent as the 
graph from which it was derived.  And if there are multiple instantiations of 
the graph, there needs to be evidence that they really are the same.  I guess it 
all comes down to provenance traces back to some verified copy or copies.

(Actually, this seems to be similar to what you say: "and the relationships 
between serializations and abstract graphs can be used to verify the signatures" 
- I guess my point is that the relationships have to be explicit and verifiable, 
not implicit and assumed.)

Without all this, we will be stuck without recourse in the face of software 
bugs.  (E.g. I, for one, wouldn't want my personal banking predicated on the 
kind of assumptions inherent in the notion of equivalence of what I can see with 
some abstract graph.)

What might help to convince me otherwise is a concrete example of an application 
which really depends upon signing an abstract graph.

#g
--


On 05/01/2012 13:51, Jim McCusker wrote:
> Graham,
>
> I disagree, mostly because there is an emphasis in RDF and Linked Data
> now that what matters is the content, not the format. RDF graphs are
> currently being served up in multiple alternative representations at
> once. How do we best relate them, and why should I have to know
> exactly which file Tim signed to be able to verify what he said?
> Getting abstract graph identities and relating them to more concrete
> representations (serializations and specific copies) is actually quite
> easy [1]. The signer can then sign whatever they are comfortable with
> and the relationships between serializations and abstract graphs can
> be used to verify the signatures.
>
> Jim
>
> [1] http://purl.org/twc/pub/mccusker2012parallel and
> https://github.com/timrdf/csv2rdf4lod-automation/raw/master/doc/publications/mccusker2012parallel.pdf
>
> On Thu, Jan 5, 2012 at 3:34 AM, Graham Klyne<GK@ninebynine.org>  wrote:
>> Hi Tim,
>>
>> I took a quick look at this (your [1]), and I was OK with the basic
>> structure used, but I'm not understanding why there is so much focus on a
>> name for the abstract triples as opposed to a user-supplied name.
>>
>> I'm guessing this may be related to a similar issue with digital signatures
>> over RDG graphs.  There has been work to apply such signatures to some
>> canonicalization or abstraction of the graph, but I don't see the necessity.
>>   In the real world, when one signs a document, one signs a *particular
>> rendering* of the document, and said signature can be used as evidence for
>> agreement to the abstract content of same.
>>
>> I see something similar applying to account graph assertions:  if a user
>> asserts an account graph, they assert a *particular instance* (or maybe
>> several) of that graph.  If one trusts that user, then one may license
>> inferences based on the abstract content of the graph, and by extension
>> inferences based on semantically equivalent graph instances, but that's a
>> separate issue IMO.
>>
>> Why do I care about this?  I think that the essential nature of using named
>> graphs to control the scope of what provenance accounts are actually being
>> asserted (or treated as asserted for some purposes of provenance analysis)
>> is confused and muddied by the discussion of different graph instances and
>> abstract graph content.
>>
>> #g
>> --
>>
>> PS: I don't know if it's at all relevant, but I made some personal notes a
>> long time ago about issues around using contexts for scoping assertions:
>>
>>   http://www.ninebynine.org/RDFNotes/UsingContextsWithRDF.html
>>
>> (It's kind of dated now; I use the term "formulae", from Notation3, to mean
>> roughly what we mean by named graphs.)
>>
>>
>>
>> On 05/01/2012 03:35, Timothy Lebo wrote:
>>>
>>> prov-wg,
>>>
>>> I have been working on some discussion [1] that is relevant to modeling
>>> Accounts in PROV-O.
>>>
>>> It is incomplete, but I think ready for some initial feedback.
>>>
>>> Modeling accounts is on the agenda for tomorrow's telecon [2], so I hope
>>> this can provide some discussion material.
>>>
>>> Regards,
>>> Tim
>>>
>>> [1] http://www.w3.org/2011/prov/wiki/Using_graphs_to_model_Accounts
>>> [2] http://www.w3.org/2011/prov/wiki/Meetings:Telecon2012.01.05
>>>
>>>
>>>
>>
>>
>
>
>

Received on Thursday, 5 January 2012 17:48:36 UTC