W3C home > Mailing lists > Public > public-prov-wg@w3.org > May 2012

Re: PROV-ISSUE-385 (haProvenanceIn-complexity): The hasProvenbanceIn relation is over-complicated [prov-dm]

From: Paul Groth <p.t.groth@vu.nl>
Date: Thu, 31 May 2012 14:43:28 +0300
Message-ID: <CAJCyKRrET0UgV7v+8TsOhiZ-kVPCgW=Kk2Ha3N4T1auA3MoHOA@mail.gmail.com>
To: Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
Cc: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Luc, Graham:

I wonder if one can see

hasProvenanceIn(entity, bundle, alias-for-entity)

as a proxy for

hasProvenanceIn(entity, bundle)
alternate(entity, alias-for-entity)

Is this a possible interpretation?


On Thu, May 31, 2012 at 11:09 AM, Graham Klyne
<Graham.Klyne@zoo.ox.ac.uk> wrote:
> On 30/05/2012 10:41, Luc Moreau wrote:
>>> >> In my approach, retrieve bob:bundle4 to access provenance about alice:report1,
>>> >
>>> > But how can you, since alice:report1 is not in bob:bundle4?
>>> >
>>>>> *then* use the specializationOf information to infer that provenance for
>>>>> ex:report1 is also true for alice:report1.
>>> OK, I should have said "retrieve bob:bundle4 to access provenance about
>>> ex:report1" there. The rest stands.
>> But again, how do you know where to find provenance for ex:report1.
>> You seem to have
>> hasProvenanceIn(alice:report1, bob:bundle4, -)
>> specializationOf(alice:report1, ex:report1)
>> This does not say which bundle I can find provenance for ex:report1.
> Maybe I was right first time... I've lost the context of this example.
> Moving on...
>>> What I think we should *not* do is add things to PROV-DM purely to support
>>> operational concerns (like incremental discovery). That would be to have the
>>> tail wagging the dog.
>> I think we may put to much emphasis on 'incremental discovery' as per PAQ.
>> The PROV data model in effect specifies a distributed graph structure
>> (distributed across bundles I mean here, services are a side issue).
>> To me, it is essential for the model to provide accurate linking across bundles
>> so that the data structure can be navigated.
> I think this is a reasonable and appropriate way to frame the problem.
>> By accurate, I mean that I want to be able to link an entity in a bundle with
>> another entity in another specific bundle.
> This seems to me to be a different requirement; viz "to link an entity ... with
> *another* entity".  If that's a requirement, I think it should be orthogonal to
> the cross-bundle linking.
> What I do not argue against is the construct:
>   hasProvenanceIn(entity, bundle)
> What I am questioning is the purpose of
>   hasProvenanceIn(entity, bundle, alias-for-entity)
> Why is the former construct alone insufficient to "provide accurate linking
> across bundles so that the data structure can be navigated"?
> (AT this point, we probably need to revisit the examples, but I'm out of time
> right now.)
>> Without it, bundles are effectively not usable, and very quickly we will see
>> constructs like the one I suggest, to aid this navigation
>> of the graph, and we will have failed in achieving interoperability.
> <aside>
> "interoperability" is not a simple binary property.  No specification can
> reasonably underpin total interoperability.  What a spec can do is provide a
> basis for interoperability for a particular set of activities (scope).  Any
> application will build upon a spec with additional elements (which may or may
> not be interoperable with other applications).
> Of itself, by virtue of being technology neutral, PROV-DM *cannot* be regarded
> as achieving interoperability - additional technology layers will always be
> needed for that.  It's a fairly common problem in standards development to try
> and "boil the ocean", rather than focus on documenting a clear consensus.  Each
> standard is just part of a bigger ecosystem, and should focus (like good
> software products) on achieving some clear goals really well and play well with
> other components.
> None of this is arguing against the desirability of adequately describing a
> "distributed graph structure" - I think that is a reasonable goal here - but not
> because not doing so would mean "we will have failed in achieving
> interoperability" - in these terms, we will always fail to achieve interoperability.
> </aside>
> #g

Dr. Paul Groth (p.t.groth@vu.nl)
Assistant Professor
Knowledge Representation & Reasoning Group
Artificial Intelligence Section
Department of Computer Science
VU University Amsterdam
Received on Thursday, 31 May 2012 11:44:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:15 UTC