Re: Best practice for specialization

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.

regards,
Tom
---
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
>