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