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

Re: Best practice for specialization

From: Tom De Nies <tom.denies@ugent.be>
Date: Mon, 2 Apr 2012 10:33:02 +0200
Message-ID: <CA+=hbbe1Rn_TaGOKLkncqX8C8=etUA5UOn89QiWdu8JVKek7Ww@mail.gmail.com>
To: Jim McCusker <mccusj@rpi.edu>
Cc: "Miles, Simon" <simon.miles@kcl.ac.uk>, Provenance Working Group <public-prov-wg@w3.org>
I agree with Jim, that option 2 would be the safer option here.

Since we are discussing best practices, I would assume that the best
practice would be to account for these "unexpected' events. If a document
is able to change, even when it is not expected to, one should always
provide the possibility to retain a correct provenance account.

As you said, option 2 retains the correctness of the original account
provided with :doc, and increments it with the version-specific provenance.
I think it is indeed a good idea to include this in the primer.

Tom De Nies
Ghent University - IBBT
Faculty of Engineering and Architecture
Department of Electronics and Information Systems - Multimedia Lab
Gaston Crommenlaan 8 bus 201, B-9050 Ledeberg-Ghent, Belgium

t: +32 9 331 49 59
e: tom.denies@ugent.be

URL:  http://multimedialab.elis.ugent.be

2012/3/31 Jim McCusker <mccusj@rpi.edu>

> I would say that the best practice would be to try to conform to the FRBR
> model. We (RPI) have outlined application of FRBR to information resources (
> http://tw.rpi.edu/web/doc/parallelIdentitiesOGD) and have produced a
> mapping of FRBR to PROV (FRIR, in submission at IPAW). The OWL for FRIR (
> http://purl.org/twc/ontology/frir.owl) uses the vocab.org version of FRBR
> (http://vocab.org/frbr/core).
> To answer your question more directly, option 2 seems to be the safer
> approach. You should probably redirect :docInGeneral to :docv2 if you're
> using this for linked data.
> In FRBR, docInGeneral is a Work and docv1 and doc are both expressions.
> Jim
> On Sat, Mar 31, 2012 at 12:07 PM, Miles, Simon <simon.miles@kcl.ac.uk>wrote:
>>   Hello,
>> In working on the primer examples, I thought about a situation which it
>> seems could commonly occur, but for which the best solution is not clear to
>> me.
>> I create a document and give it an ID, :doc. I make the document public
>> along with metadata including PROV statements that it was generated by some
>> activity and suchlike.
>>   :doc a prov:Entity.
>>   :doc prov:wasGeneratedBy :editing.
>>   :doc dcterms:title "What I did on my holidays"
>>   etc.
>> I was not expecting to change the document, but later notice a serious
>> error which means I need to correct it. I describe the new version as a new
>> entity, :docV2. In describing :doc above, I was describing the document in
>> general, not a specific version of it, as I didn't expect multiple versions
>> to exist. I would like to say:
>>   :docV2 prov:specializationOf :doc.
>> but some of my statements above, like the wasGeneratedBy, are specific to
>> the original version.
>> So, I could either
>>  (1) Create an entity :docV1, state that :docV1 and :docV2 are
>> specializations of :doc, and change some of the original statements to be
>> about :docV1 where specific to the original version.
>>  (2) Don't change the original statements, treat :doc as referring to the
>> original version, create an entity :docInGeneral, which :doc and :docV2 are
>> specializations of, and re-assert each of the above statements about :doc
>> that are also true for :docInGeneral
>> Option (1) seems only possible if we assume copies of the statements do
>> not exist elsewhere, e.g. have already been downloaded.
>> Would guidance on this kind of situation be helpful to have in the best
>> practices document?
>> Is there more general semantic web guidance on what to do when you
>> thought you were identifying one thing and it turned out to be two?
>> Thanks,
>> Simon
>>  Dr Simon Miles
>> Senior Lecturer, Department of Informatics
>> Kings College London, WC2R 2LS, UK
>> +44 (0)20 7848 1166
>> Electronically querying for the provenance of entities:
>> http://eprints.dcs.kcl.ac.uk/61/
> --
> 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 Monday, 2 April 2012 09:08:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:11 UTC