Relationship between PROV-O and PROV-DM (was: Are qualified<Foo> relations IFPs?)

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 17:35:33 UTC