- From: Timothy Lebo <lebot@rpi.edu>
- Date: Fri, 1 Jun 2012 13:29:17 -0400
- To: Paul Groth <p.t.groth@vu.nl>
- Cc: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
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