- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Thu, 12 Jul 2012 10:32:26 +0100
- To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Cc: Timothy Lebo <lebot@rpi.edu>, Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>, Paul Groth <p.t.groth@vu.nl>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
I think it looks really good, it is not too verbose. I also like that PROV-N expressions are linked in. It would fit as an (informative?) appendix to PROV-DM. About this: > Bundle constructor ? We currently say: > A prov:Bundle is a named set of provenance descriptions that enables the expression of provenance of provenance. It is important to note that the set of provenance descriptions can assume forms beyond PROV-O triples, such as videotaped testimony or scribbles on a drink napkin. The subclass of Bundle that contains PROV-O assertions is not provided by PROV-O, since it is more appropriate to do so using other recommendations, standards, or technologies. In any case, a Bundle of PROV-O assertions is an abstract set of RDF triples, and adding or removing a triple creates a distinct Bundle of PROV-O assertions. I guess what this vagueness tries to say without enforcing anything is that a bundle is a resource, so to find the triples of its PROV-O statements you need to simply get hold of the resource. We don't say if it is an HTTP resource, named graph at an SPARQL endpoint or other kind of resource. We might want to use the word "Resource" in here though. On Wed, Jul 11, 2012 at 4:59 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote: > yes absolutely, I dont' know which document (possibly dm/possibly all). > > I am just trying to see whether the table is useful and addressing Graham's > concern. > > Luc > > > On 07/11/2012 04:55 PM, Timothy Lebo wrote: >> >> Would this go into an appendix? >> I think it's a bit distracting at the beginning of DM. >> >> -Tim >> >> On Jul 11, 2012, at 11:52 AM, Luc Moreau wrote: >> >>> Hi Graham, all >>> >>> I tried to outline a possible table. I just did it for a couple of rows, >>> obviously, we need >>> to continue for the others. >>> >>> Thoughts? >>> >>> It appears at the beginning of section 1 >>> >>> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-table.html#data-model-components >>> >>> (Ignore the rest of the document) >>> >>> Thanks, >>> Luc >>> >>> >>> On 07/11/2012 12:07 AM, Graham Klyne wrote: >>>> >>>> On 10/07/2012 20:51, Luc Moreau wrote: >>>>> >>>>> Hi Graham, >>>>> >>>>> While the prov-rdf mapping has been a useful tool for the design of the >>>>> ontology and the data model, >>>>> it has never been the intent of the WG that a mapping (even simplified) >>>>> was going to be part of a REC. >>>>> I would even argue that this is not part of our charter. >>>>> >>>>> This said, PROV-O qualified classes correspond to PROV-DM concepts. >>>>> The name of a PROV-DM core relation is also the name of the >>>>> corresponding PROV-O property. >>>>> >>>>> So, is just a matter of a table of prov-dm concepts and their >>>>> corresponding classes in prov-o? >>>>> This table could be added in appendix. >>>> >>>> Luc, >>>> >>>> I think a table might do it. I just think that it needs to be clear how >>>> they line up. The naming has sufficient variations that they're not enough >>>> for the purpose of a standard, IMO. >>>> >>>> #g >>>> -- >>>> >>>>> ________________________________________ >>>>> From: Paul Groth [p.t.groth@vu.nl] >>>>> Sent: 10 July 2012 7:42 PM >>>>> To: Graham Klyne >>>>> Cc: Stian Soiland-Reyes; Luc Moreau; Timothy Lebo; >>>>> public-prov-wg@w3.org >>>>> Subject: Re: Relationship between PROV-O and PROV-DM (was: Are >>>>> qualified<Foo> relations IFPs?) >>>>> >>>>> Hi Graham >>>>> >>>>> PROV-O had cross-refs to PROV-N. >>>>> >>>>> I had asked them to be taken out in my review. I was thinking that the >>>>> links directly into prov-dm were more informative >>>>> >>>>> Paul >>>>> >>>>> On Jul 10, 2012, at 19:34, Graham Klyne<Graham.Klyne@zoo.ox.ac.uk> >>>>> wrote: >>>>> >>>>>> On 10/07/2012 17:35, Stian Soiland-Reyes wrote: >>>>>>> >>>>>>> On Tue, Jul 10, 2012 at 4:11 PM, Graham >>>>>>> Klyne<graham.klyne@zoo.ox.ac.uk> wrote: >>>>>>>> >>>>>>>> Is round-tripping PROV-O and PROV-N a requirement? That could well >>>>>>>> be a can >>>>>>>> of worms. >>>>>>> >>>>>>> I don't think round-tripping various scruffy provenance is a >>>>>>> requirement, as it would become very difficult, specially PROV-O to >>>>>>> PROV-N. What if there is an anonymous node representing an activity's >>>>>>> start? >>>>>>> >>>>>>> But "anything" covered by PROV-DM valid by PROV-Constraint should be >>>>>>> covered by PROV-O, right? That is the principle we've worked on for >>>>>>> the last 6 months or so. >>>>>> >>>>>> That's what I assumed. >>>>>> >>>>>>>> Something I haven't seen in the specs I've is a description of the >>>>>>>> mapping >>>>>>>> between PROV-N and PROV-O (that's one of my comments on PROV-O). >>>>>>> >>>>>>> Right, we've kept that in the wiki - >>>>>>> >>>>>>> http://www.w3.org/2011/prov/wiki/ProvRDF (I'm sure this is quite out >>>>>>> of date, using PROV-DM WD3) >>>>>>> >>>>>>> as you see it can get quite verbose.. would you really want that as >>>>>>> part of the spec? Perhaps another note? >>>>>> >>>>>> Hmmm... the wiki, or a separate NOTE, doesn't really stand as part of >>>>>> W3C REC. >>>>>> >>>>>> I think there's a bit of a gap in the family of specifications if the >>>>>> mapping >>>>>> isn't clear as part of the REC set. I thought the whole idea was that >>>>>> PROV-DM/PROV-N defined a technology neutral model, and PROV-O was the >>>>>> RDF/OWL >>>>>> realization of that model. For that to work, we have to know what are >>>>>> the >>>>>> precise correspondences. >>>>>> >>>>>> I don't think we need to describe a mechanical translation process, >>>>>> which I >>>>>> think contributes to the bulk of the wiki page. I think a table of >>>>>> PROV-N forms >>>>>> and corresponding RDF forms would cover it. Maybe as an appendix of >>>>>> the PROV-O >>>>>> document, or woven into the cross-reference? >>>>>> >>>>>> I haven't previously been following the PROV-O work so closely, >>>>>> because I >>>>>> thought plenty of others were doing that, so didn't notice this >>>>>> previously. >>>>>> >>>>>> I think it's a potentially serious issue that we need to consider: >>>>>> why are we >>>>>> producing multiple REC-track specifications if we are not being quite >>>>>> clear >>>>>> about how they relate to each other? I'd be surprised if this isn't >>>>>> picked up >>>>>> in last-call -- if it isn't, I'd be suspicious that we are not getting >>>>>> enough >>>>>> serious external review. >>>>>> >>>>>> #g >>>>>> -- >>>>>> >>>>>> >>>>> >>> >>> > > -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester
Received on Thursday, 12 July 2012 09:33:20 UTC