Re: Relationship between PROV-O and PROV-DM

Luc,

On Jul 12, 2012, at 9:48 AM, Graham Klyne wrote:

> On 11/07/2012 16:52, 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?
> 
> Luc,
> 
> I think that does it, except that I'd suggest using the function name rather than the syntax production name in the PROV-N column (e.g. "entity" rather than "entityExpression").  Similarly, I'd use the definition name in the PROV-DM column (e.g. "entity" rather than "provdm:entity"), and the term name (e.g. as prov:Entity, rather than provo:Entity) in the PROV-O column.

I think this direction makes sense.

-Tim


> 
> I think this is particularly particularly useful where a single term on PROV-DM or PROV-N is represented by several terms in PROV-O qualified relations, etc.
> 
> I'd also suggest an introductory statement along the lines of:
> 
> [[
> PROV-DM, PROV-N and PROV-O describe the same underlying provenance data model. This table enumerates the corresponding terms that are introduced in each document.  In the case of PROV-O, several terms may be needed to express a single PROV-DM or PROV-N concept, as in the case of qualified relations.
> ]]
> 
> #g
> --
> 
>> 
>> 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
>>>>> --
>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>> 
> 
> 

Received on Thursday, 12 July 2012 15:04:40 UTC