- From: Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
- Date: Wed, 11 Jul 2012 00:03:07 +0100
- To: Paul Groth <p.t.groth@vu.nl>
- CC: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>, Luc Moreau <L.Moreau@ecs.soton.ac.uk>, Timothy Lebo <lebot@rpi.edu>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
On 10/07/2012 19:42, Paul Groth wrote: > 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, I see PROV-N as a direct textual representation of PROV-DM, so when I talk about round-tripping it could be either. I agree, defining alignment with reference to PROV-DM is probably the right thing (but I think it would need more than just links). #g -- > 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 >> -- >> >> >
Received on Tuesday, 10 July 2012 23:26:08 UTC