Re: Relationship between PROV-O and PROV-DM

Hi Graham and all.

I have added a table mapping prov-dm concepts to prov-o classes and 
properties and prov-n expressions.

It is in appendix A at the following
http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm.html#prov-dm-to-prov-o-and-prov-n

Regards,
Luc

PS. GIven respec.js inability to support cross-document navigation, I am 
linking to older versions
of prov-o and prov-n; so, some links are known to be dangling.


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
>>> -- 
>>>
>>>
>>
>>

Received on Thursday, 12 July 2012 12:43:18 UTC