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

Re: ISSUE-385: hasProvenanceIn: finding a solution

From: Timothy Lebo <lebot@rpi.edu>
Date: Fri, 1 Jun 2012 13:29:17 -0400
Cc: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Message-Id: <0185C813-C2FB-4D9B-8CA2-3E4ABF5F260F@rpi.edu>
To: Paul Groth <p.t.groth@vu.nl>
Paul,

On Jun 1, 2012, at 1:11 PM, Paul Groth wrote:

> response in-line
> 
> On Fri, Jun 1, 2012 at 6:48 PM, Timothy Lebo <lebot@rpi.edu> wrote:
>> Paul, Luc, Simon,
>> 
>> On Jun 1, 2012, at 12:03 PM, Paul Groth wrote:
>> 
>>> Hi All,
>>> 
>>> It seems that a one approach would be to define an extensible version
>>> of hasProvenanceIn and leave it at that.
>>> 
>>> hasProvenanceIn(id, entity, bundle, attrs).
>>> 
>>> Like all our extensible relations, we would also have the straight
>>> binary version
>>> 
>>> hasProvenanceIn(entity,bundle)
>>> 
>>> This would allow for the extensibility to cater for Luc's use case but
>>> also for other use cases where extension is nice. For example, I can
>>> imagine a system wanting to put a time constraint on the applicability
>>> of provenance in a bundle to an entity.
>>> 
>>> This would leave it up to people to define specialization, alternate
>>> and derivation relations between entities as they want.
>>> 
>>> Would this be acceptable to the group?
>> 
>> 
>> 2)
>> As I've mentioned before, I'd prefer the name to be something closer to the names used in other data models, to facilitate adoption.
>> (hence, isTopicOf, or perhaps we just steal DC's local name: prov:isReferencedBy with a range of provBundle)
> 
> I'm fine with these relation names. It's the concept that counts.
> 
>> 3)
>> However, I'm not sure this simplification of hasProvenanceIn satisfies Luc's concern with his example.
>> I think that concern can be resolved with isTopicOf's  (isReferencedBy's?) interpretation of:
>> 
>>      "when you get that bundle, check for any generalizations that you know about, too"
> 
> Maybe this would satisfy his concern, but the key is that he can
> extend the relation and satisfy, however, he deems appropriate.

I don't see how it solves his problem, but if he's happy with your proposal, so am I.

> 
>> 
>> 4)
>> I'm surprised that the question of "where __is__ the bundle" hasn't arisen.
>> Is it because we are all assuming that they are "here"?
> 
> I believe this is because this is answered by the PAQ. We have a
> relation in the paq for finding the location of entities. This can
> also be used for bundles, I believe.


Cool. Four other documents always get in my way to rereading the PAQ :-(

-Tim
Received on Friday, 1 June 2012 17:30:11 UTC

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