W3C home > Mailing lists > Public > public-prov-wg@w3.org > October 2012

Re: Provenance specs: have we lost sight of the goal?

From: Reza B'Far (Oracle) <reza.bfar@oracle.com>
Date: Wed, 10 Oct 2012 22:29:55 -0700
Message-ID: <50765953.5090808@oracle.com>
To: public-prov-wg@w3.org
Graham -

I'm a rather quiet member of the group and have been providing some 
input in the background during the past 2 years, mostly off-thread since 
some of the topics have been controversial (Agent, etc.).  I run a very 
large product at Oracle (GRC).  GRC announced at OOW that version to be released in very short time will support an 
implementation of Prov.  While I can't put what the revenue is for the 
product, I can tell you that it is a VERY significant product, with a 
very large engineering team.  I can tell you that an investment in prov 
would not have been made if we thought it was useless.  Let me enumerate 
feedback from the engineers in my team who have touched prov (more than 
a handful):

 1. Very elegant separation between model (Prov-DM) and serialization
 2. Very elegant mechanism to capture constraints.
 3. Core entities are very clear and applicable to many models, if not
    all models, in our space (risk, compliance, finance, audit,
    regulations such as health, etc.)

Do you know a lot of enterprise products with large revenue that 
implement other semantic standards other than OWL and RDF? Outside of 
those 2, I see the biggest hope for Prov.  I can provide a lot more 
information, but I'd rather do it off-line so it's not archived (I'm 
very uncomfortable with the archive/searchability of these threads given 
I work for a commercial entity that charges people for IP, there is 
product release times, etc. all sorts of liabilities).

Also, FYI, on one thing that I'm enamored with Prov -- based on the 
architectural decisions in Prov, I recommended (though I can't take 
credit for the result as others picked up the mantel, I just pushed the 
initial idea) the separation of model and serialization in LDP 
(LinkedData... W3C) and now serialization is separated there from the 
model.  This was really a hallmark, I feel for a standard.

I'll share more in due time as I work on something to send W3C for 
announcement, etc.


On 10/9/12 11:27 PM, Paul Groth wrote:
> Hi Graham,
> First, enjoy your holiday.
> I think you make 2 a bit different points that I'd like to respond to
> around adoption and simplicity.
> 1) Adoption
> I'm actually enthusiastic about adoption. We already have two software
> implementations coming from outside the WG [1], [2]. As well as
> positive reports of usage by WG members. Once we get to
> recommendations prov will be included as part of the rdfa initial
> context [3] and I already know of several other users and extensions
> of prov.
> Obviously, we need to do more to encourage and increase adoption. I'm
> open for suggestions here. Personally, I would like to do more blog
> posts showing the ease with which you can use prov, for example, in
> RDFa.
> 2) Simplicity
> As you know, the group has done a lot of work on making things simpler
> and easier to access. prov-primer and prov-o are both simple. I think
> prov-xml will also be easy to understand. PROV-DM is long but has a
> clear organization and is not meant as the entry point for the specs.
> Clearly, prov-constraints is not simple but is not aimed at the target
> audience of non-provenance specialist.
> So my question, is there any way, that we can get concrete criticisms
> so that we can address these concerns?
> One suggestion I would make is to put the information on "where to
> start" on our wiki page so that people know what they should read.
> I think the whole group wants to make prov a success and I think it
> will be. The demand for provenance interchange is there and we have a
> solid solution. Now we need to complete the specs and also make sure
> that they are properly communicated.
> regards,
> Paul
> [1] OpenRDF Auditing Repository
> http://www.openrdf.org/doc/alibaba/2.0-rc5/alibaba-repository-auditing/index.html
> [2] Callimachus
> http://lists.w3.org/Archives/Public/public-prov-comments/2012Oct/0001.html
> [3] http://www.w3.org/2011/rdfa-context/rdfa-1.1
> On Wed, Oct 10, 2012 at 12:04 AM, Graham Klyne <GK@ninebynine.org> wrote:
>> (Now that I'm on holiday, away from the day-to-day pressures of getting stuff
>> done, I find a little time to put down some nagging doubts I've been having
>> about how our work is going...)
>> Over the past few weeks, I have had informal discussions with a small number of
>> people about the provenance specifications.  A common theme that has emerged is
>> that the provenance specs are over-complicated, and that as a result many people
>> (being non-provenance specialists) just will not use it.  I've suggested to
>> these people that they submit last-call comments to the working group, but the
>> general response has been along the lines of "Why should I bother?  It doesn't
>> matter to me, I won't use it".
>> This raises for me the possibility that we are working in an "echo chamber",
>> hearing only the views of people who have a particular and deep interest in
>> provenance, but not hearing the views of a wider audience who he hope will
>> include and consume limited amounts of provenance information in their applications.
>> Maybe it's only me, and the rest of you aren't hearing this kind of comment.
>> But if you are I think that, as we go through the last call process, it is
>> appropriate to reflect and consider if what we are producing is really relevant
>> to the wider community we aim to serve.  Have we become too bound up with fine
>> distinctions that don't matter, or don't apply in the same way, to the majority
>> of potential provenance-generating and provenance-using applications?   Have we
>> sacrificed approachability and simplicity that encourages widespread take-up on
>> the altar of premature optimization to support particular usage scenarios?
>> While I think these are relevant questions, I'm not sure if and what we might do
>> about them.  But I also fear that what we produce may turn out to be irrelevant
>> in the long run.
>> #g
>> --
Received on Thursday, 11 October 2012 05:30:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:19 UTC