- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Thu, 31 May 2012 15:03:29 +0100
- To: Paul Groth <p.t.groth@vu.nl>
- CC: Provenance Working Group WG <public-prov-wg@w3.org>
Hi Paul, I suppose you meant this to be public. Yes, I think so. I am not sure whether it's alternate or whether it's specialization. Luc On 05/31/2012 02:50 PM, Paul Groth wrote: > would an interpretation be that the alias is an alternate in that bundle? > > cheers > Paul > > On Thu, May 31, 2012 at 4:26 PM, Luc Moreau<L.Moreau@ecs.soton.ac.uk> wrote: > >> Hi Paul, >> Yes, it's optional. When absent, the alias is the subject identifier. >> Luc >> >> On 05/31/2012 02:15 PM, Paul Groth wrote: >> >>> Hi Luc, >>> >>> Thanks for the explanations. >>> >>> I was wondering if the third argument is optional or not? >>> >>> Thanks >>> Paul >>> >>> On Thu, May 31, 2012 at 3:13 PM, Luc Moreau<L.Moreau@ecs.soton.ac.uk> wrote: >>> >>> >>>> Hi Paul, >>>> >>>> I don't think we can break up this ternary relation in two binary relations. >>>> >>>> 1. One of the use cases I suggested was: >>>> >>>> hasProvenanceIn(e1, b1, e) >>>> hasProvenanceIn(e2, b2, e) >>>> >>>> You would end up with >>>> >>>> hasProvenanceIn(e1, b1) >>>> alternate(e1, e) >>>> hasProvenanceIn(e2, b2) >>>> alternate(e2, e) >>>> >>>> But e1 is not in b1, it's e which is a topic in b1. >>>> Likewise for e2 and b2. How do we know what to look for in b1? >>>> >>>> Furthermore, e itself may not be a topic at all in the current bundle. >>>> >>>> What in addition, I have another alternate relation >>>> alternate(e1, e3)? >>>> How do I know what is the alias for e1 in b1? >>>> >>>> >>>> 2. Another use case I suggested was: >>>> >>>> hasProvenanceIn(e, b1, e) // provenance of e found in b1, no aliasing >>>> hasProvenanceIn(e2, b2, e) // I had to choose alias e to e2 in the current >>>> bundle >>>> because I specialize it differently >>>> >>>> >>>> hasProvenanceIn(e, b1) >>>> hasProvenanceIn(e2, b2) >>>> alternate(e2, e) >>>> >>>> Given alternate(e2, e) implies alternate(e, e2) >>>> >>>> We are faced with a similar problem, which one is aliased, which one is not? >>>> >>>> >>>> 3. Furthermore, I definitely would like to subtype this relation. >>>> The only possiblity in the context of prov-dm is to allow for prov:type to >>>> be expressed. >>>> >>>> hasProvenanceIn(e1, b1, e, [ prov:type= XXX ]) >>>> >>>> 4. I do not know whether the following is a way out, but it may help. >>>> >>>> If we consider that the third argument of >>>> >>>> hasProvenanceIn(e1, b1, e) >>>> >>>> is an alias, then when we write "e", we really mean the identifier "e" and >>>> not the entity denoted by "e". >>>> As opposed to "e1" which denotes an entity with a name. >>>> >>>> >>>> So, an alternative is to write it as follows: >>>> >>>> hasProvenanceIn(e1, b1, [ prov:alias='e']) >>>> >>>> We are stating that entity e1 has Provenance in b1/is a topic in b1, but we >>>> need to look for it under >>>> the name 'e'. The value associated with prov:alias must a URI or a >>>> qualified name. >>>> >>>> >>>> Luc >>>> >>>> >>>> >>>> On 05/31/2012 12:43 PM, Paul Groth wrote: >>>> >>>> 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? >>>> >>>> Thanks >>>> Paul >>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Professor Luc Moreau >>>> Electronics and Computer Science tel: +44 23 8059 4487 >>>> University of Southampton fax: +44 23 8059 2865 >>>> Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk >>>> United Kingdom http://www.ecs.soton.ac.uk/~lavm >>>> >>>> >>> >>> >>> >> -- >> Professor Luc Moreau >> Electronics and Computer Science tel: +44 23 8059 4487 >> University of Southampton fax: +44 23 8059 2865 >> Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk >> United Kingdom http://www.ecs.soton.ac.uk/~lavm >> >> > > > -- Professor Luc Moreau Electronics and Computer Science tel: +44 23 8059 4487 University of Southampton fax: +44 23 8059 2865 Southampton SO17 1BJ email: l.moreau@ecs.soton.ac.uk United Kingdom http://www.ecs.soton.ac.uk/~lavm
Received on Thursday, 31 May 2012 14:05:13 UTC