- From: Simon Miles <simon.miles@kcl.ac.uk>
- Date: Tue, 6 Dec 2011 17:22:25 +0000
- To: Provenance Working Group WG <public-prov-wg@w3.org>
Hi Luc, Isn't the consequence of your argument not only that two entity records in different accounts may have the same identifier, but also that two entity records in the same account may have the same identifier, as every entity record about one entity has the same identifier? Your reasoning sounds to me more like a good argument against using the identifier for dual purposes than an argument in favour of scoped identifiers... >From an asserter's perspective, I like the suggestion from Paul's head that we reduce the burden of minting URIs simply by making record identifiers optional (but not scoped). But from a curator's perspective, I can see that it could be difficult to have provenance assertions we can't refer to or annotate later. For something more temporary than provenance, this might be fine, but I'm not sure it's a good idea here. I think overall, I prefer just to have the (light?) burden of minting URIs. Thanks,Simon On 6 December 2011 17:19, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote: > Hi Paul, > > So, OK, we could mint identifiers for entity record > > entity(<a minted identifier here>, [ex:param="a", ex:port="foo"]) > > (Which by the way is what OPM does.) > > How do you refer to the entity now? We don't know what this record is about. > > Luc > > On 12/06/2011 05:11 PM, Paul Groth wrote: >> So I always thought that you could mint identifiers for entity records >> but you didn't have to and we supported that. >> >> But maybe that's my head inserting text where it shouldn't have been.... >> >> Paul >> >> Luc Moreau wrote: >>> ... the conclusion issue ;-) >>> >>> No, we have no formal decision on this. >>> >>> We wrote this in the prov-dm document a long time ago (before fpwd), and >>> we have >>> been refining it over time. >>> >>> I think it's an inevitable consequence of two key decisions: >>> - distinguishing entities (in the world) from entity records (in the >>> provenance) >>> - not mandating the minting of new URIs for entity records >>> (no formal decision on this, but I think we have support for >>> it, since >>> we want to minimize the effort to generate provenance) >>> >>> Luc >>> >>> >>> On 12/06/2011 04:56 PM, Paul Groth wrote: >>>> Hi Luc, >>>> >>>> Do you have a pointer to wear we reached the consensus about the dual >>>> role of identifiers? >>>> >>>> Thanks, >>>> Paul >>>> >>>> Provenance Working Group Issue Tracker wrote: >>>>> PROV-ISSUE-183 (prov-dm-identifiers): identifiers in prov-dm >>>>> [prov-dm] >>>>> >>>>> http://www.w3.org/2011/prov/track/issues/183 >>>>> >>>>> Raised by: Luc Moreau On product: prov-dm >>>>> >>>>> >>>>> Hi, >>>>> >>>>> It think that it is now time to have a proper debate about >>>>> identifiers in prov-dm since comments are regularly expressed about >>>>> them. I have raised this issue about this topic so that we can track >>>>> the conversation properly. Our hope is to reach consensus on this >>>>> topic by the time of the third working draft. >>>>> >>>>> First, in the fpwd, there was a mention of "qualified identifier" >>>>> (appearing in a note see [1]). We have removed this term from the >>>>> second working draft. >>>>> >>>>> Second, the complementarity record now explicitly allows for linking >>>>> entity records across accounts. Its syntax allows for two accounts to >>>>> be named. >>>>> >>>>> Third, identifiers for entities in prov-dm have a dual role [3]. An >>>>> entity has got an id (typically given by an application). An entity >>>>> record --- i.e. what we say about an entity in a provenance record >>>>> --- also has an id. There is a consensus that we shouldn't mint >>>>> identifiers for provenance records. Hence, the identifier of the >>>>> entity record is defined to be the same as the identifier of the >>>>> entity. >>>>> >>>>> The consequence of this is that two entity records in different >>>>> accounts may have the same identifier: they may say different things >>>>> about the same entity. For example, the document ex:doc was >>>>> generated by latex in account1, while in account 2, ex:doc is >>>>> described to be the result of a survey of a field by different >>>>> authors. >>>>> >>>>> This explains why we needed the complementarity record to name the >>>>> accounts as well. This assumes that account names need to be named >>>>> uniquely (see [4]). >>>>> >>>>> So, entity records identifiers are scoped to accounts. Note, I said >>>>> entity *records*, not entities. Hence, we are not breaking the >>>>> semantic web approach: an entity is a resource and is denoted by a >>>>> URI, and this remains true in all accounts. (I guess that from a >>>>> semantic web perspective we are not looking at a provenance record as >>>>> resource, since we don't have a global URI to name it.) Finally, we >>>>> allow for accounts to be nested hierarchically; this fits nicely with >>>>> abstraction in provenance records. Again, see [4]. >>>>> >>>>> Can you express your views about this approach, as currently defined >>>>> in the second draft of prov-dm? >>>>> >>>>> Thanks, Luc >>>>> >>>>> [1] >>>>> http://www.w3.org/TR/2011/WD-prov-dm-20111018/#expression-identifier >>>>> [2] >>>>> http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#record-complement-of >>>>> >>>>> >>>>> >>>>> >>>> [3] >>>> http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#record-Entity >>>> >>>> >>>>> [4] >>>>> http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#record-Account >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> > > -- > 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 > > -- Dr Simon Miles Lecturer, Department of Informatics Kings College London, WC2R 2LS, UK +44 (0)20 7848 1166 PrIMe: A Methodology for Developing Provenance-Aware Applications: http://eprints.dcs.kcl.ac.uk/1382/
Received on Tuesday, 6 December 2011 17:22:53 UTC