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

Re: reviewer feedback on prov-o ontology

From: Jim McCusker <mccusj@rpi.edu>
Date: Thu, 23 Feb 2012 18:53:02 +0000
Message-ID: <CAAtgn=T=Tp6WQTW6V7N17_iGzsL+xRRQnDhf7at7sR2jt_ujSQ@mail.gmail.com>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Cc: Provenance Working Group WG <public-prov-wg@w3.org>
I was thinking that that was more good practice for a software engineering
project. I know of quite a number of APIs that support incompleteness
already. Jena, Sesame, OWL-API, SuRF... :-)

Really, if a tool will only load information that is complete and throw an
exception otherwise, it's given up the opportunity for the tool user to use
that tool to fix their data.

Jim

On Thu, Feb 23, 2012 at 3:35 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk>wrote:

> **
> Jim,
>
> Nice feature, but I would argue that it is not in scope, because
> here we would be opening a research topic.
> Incomplete, uncertain, probabilistic, etc are not in scope.
> It would require probably a few years more to come up with a
> Recommendation ;-)
>
> Luc
>
>
> On 02/23/2012 03:17 PM, Jim McCusker wrote:
>
> I guess my point is that implementations should support incomplete
> knowledge. It should be possible for the implementations to represent (and
> check) incomplete or otherwise invalid data. This is going to be especially
> critical to support interchange of scruffy provenance.
>
>  Jim
>
> On Thu, Feb 23, 2012 at 2:41 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk>wrote:
>
>>  Hi Jim,
>> I didn't say it was a bug. I said it was not aligned.
>>
>> It's a feature, maybe, but that's not expressible in prov-dm, which means
>> that other implementations e.g. java, xml, or whatever would not
>> understand that feature.
>>
>> So, from an ontological viewpoint, a nice feature, but one that does not
>> help with
>> interoperability.
>>
>> Luc
>>
>>
>> On 02/23/2012 02:21 PM, Jim McCusker wrote:
>>
>> On Thu, Feb 23, 2012 at 9:30 AM, Luc Moreau <L.Moreau@ecs.soton.ac.uk>wrote:
>>
>>> Furthermore, the ontology allows for instances of involvements to be
>>> expressed, without
>>> specifying its subclass (Usage, Generation, etc). This is not aligned
>>> with the data model.
>>>
>>
>>  This is a feature, not a bug. Even if Involvement were defined as
>> equivalent to the union of subclasses, it would still be possible (and
>> consistent) to assert that something is an Involvement without saying what
>> the subclass is. We simply wouldn't know.
>>
>>  Jim
>>  --
>> Jim McCusker
>> Programmer Analyst
>> Krauthammer Lab, Pathology Informatics
>> Yale School of Medicine
>> james.mccusker@yale.edu | (203) 785-6330
>> http://krauthammerlab.med.yale.edu
>>
>> PhD Student
>> Tetherless World Constellation
>> Rensselaer Polytechnic Institute
>> mccusj@cs.rpi.edu
>> http://tw.rpi.edu
>>
>>
>>   --
>> Professor Luc Moreau
>> Electronics and Computer Science   tel:   +44 23 8059 4487
>> University of Southampton          fax:   +44 23 8059 2865
>> Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
>> United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
>>
>>
>
>
>  --
> Jim McCusker
> Programmer Analyst
> Krauthammer Lab, Pathology Informatics
> Yale School of Medicine
> james.mccusker@yale.edu | (203) 785-6330
> http://krauthammerlab.med.yale.edu
>
> PhD Student
> Tetherless World Constellation
> Rensselaer Polytechnic Institute
> mccusj@cs.rpi.edu
> http://tw.rpi.edu
>
>
> --
> Professor Luc Moreau
> Electronics and Computer Science   tel:   +44 23 8059 4487
> University of Southampton          fax:   +44 23 8059 2865
> Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
> United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
>
>


-- 
Jim McCusker
Programmer Analyst
Krauthammer Lab, Pathology Informatics
Yale School of Medicine
james.mccusker@yale.edu | (203) 785-6330
http://krauthammerlab.med.yale.edu

PhD Student
Tetherless World Constellation
Rensselaer Polytechnic Institute
mccusj@cs.rpi.edu
http://tw.rpi.edu
Received on Thursday, 23 February 2012 18:53:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:56 GMT