Re: How do you go about versioning ?

Facts about redirections are seldom kept in RDF systems. Also the
redirection for the representation is independent of the version IRI -
content negotiation on http://example/P04637/V2 might redirect to
http://example/P04637/V2.ttl.

Time-negotiation might also redirect to a different version -
http://www.mementoweb.org/guide/rfc/ID/


By keeping it in the RDF representation then one can find out the
relation between the two resources - it does not matter which one you
came in to. If someone told you about http://example/P04637/V2 then
you will find out that it is a version of http://example/P04637 (and
perhaps even the current version). If you come in to the unversioned
resource you know what is the "permalink" - so it's up to you which
one you want to use depending on what kind of annotation you want to
make.


The two resources SHOULD have "equivalent content" - however you want
to interpret that.

> "Equivalent content" is a loose definition, for instance the snapshot resource might include additional information to indicate it is a snapshot, and is not required to be immutable.

This would particularly be the case for HTML representations - RDF
representations could easily be the same - it's just that your
"starting point" within that graph would vary.


I did not want to encourage free-standing "version resources" that
don't contain the actual content - pav:hasCurrentVersion (and
pav:hasVersion) is a subproperty of prov:generalizationOf so that what
is said about the general (unversioned) resource should in large be
true also for the specific (versioned) resource.


dct:hasVersion and dct:isVersionOf leaves this possibility (and
others) open and only hints at a hierarchical element. pav:hasVersion
uses dct:hasVersion as superproperty - but notes:

> pav:hasVersion is a subproperty of dcterms:hasVersion to more strongly define this hierarchical pattern. It is therefore also a subproperty of pav:generalizationOf (inverse of prov:specializationOf).
> To indicate the existence of other, non-hierarchical kind of editions and adaptations of this resource that are not versioned snapshots (e.g. Powerpoint slides has a video recording version), use instead dcterms:hasVersion or prov:alternateOf.



One can from pav:hasVersion assume that the representation is somewhat
equivalent to what the unversioned resource would have looked like at
some point in time.



On 22 September 2014 12:56, Andrea Splendiani
<andrea.splendiani@iscb.org> wrote:
> Nice.
> Why do you need the hasCurrentVersion link, instead of just relying on
> redirection ?
> The content served should/could anyway be the same of the last version, no?
>
> best,
> Andrea
>
> On Mon, Sep 22, 2014 at 1:04 PM, Stian Soiland-Reyes
> <soiland-reyes@cs.manchester.ac.uk> wrote:
>>
>> We have in PAV 2.3 also added pav:hasCurrentVersion which is the easy
>> way to link from an unversioned URI to a versioned URI.
>>
>> http://purl.org/pav/html#http://purl.org/pav/hasCurrentVersion
>>
>>
>> e.g.
>>
>> <http://example/P04637> pav:hasCurrentVersion <http://example/P04637/V2> ;
>>     pav:version "2" .
>> <http://example/P04637/V2>
>>     pav:version "2";
>>     pav:previousVersion <http://example/P04637/V1> ;
>>
>>
>> Both URIs should return (about) the same representation today - but at
>> a later stage, looking up the unversioned URI could have a different
>> current version:
>>
>>
>> <http://example/P04637> pav:hasCurrentVersion <http://example/P04637/V3> ;
>>     pav:version "3" .
>> <http://example/P04637/V3>
>>     pav:version "3";
>>     pav:previousVersion <http://example/P04637/V2> ;
>>
>>
>> In theory you can have multiple layers of versioning complexity to do
>> major/minor/patch - but the above should work for most.
>>
>>
>>
>> On 21 September 2014 22:00, Michel Dumontier <michel.dumontier@gmail.com>
>> wrote:
>> > Martynas,
>> >   The Cool URIs proposal does not address versioning (and neither does
>> > most metadata vocabularies), unfortunately.  There's no reason why you
>> > can't create URIs to return information that is known about an object
>> > under some condition (APIs do that all the time). The key is that the
>> > URI persists.
>> >   In our TrustyURI proposal [1], we show how to generate HTTP URIs
>> > that are verifiable, immutable, and permanent. Using these, one could
>> > relate a version of data with another, perhaps using
>> > pav:previousVersion [2], as we indicate in the HCLS note on dataset
>> > descriptions. That way, you'd be sure that you're getting back what
>> > you linked to in the first place.
>> >
>> > m.
>> >
>> > [1] http://www.slideshare.net/TobiasKuhn/trustyuris
>> > [2] http://purl.org/pav/
>> > [3] http://tinyurl.com/mg9ly9c
>> >
>> > On Sun, Sep 21, 2014 at 1:42 PM, Martynas Jusevičius
>> > <martynas@graphity.org> wrote:
>> >> Joachim,
>> >>
>> >> I think your proposal is in conflict with core Linked Data principle:
>> >> Cool URIs Don't Change.
>> >>
>> >> http://www.w3.org/TR/cooluris/#cooluris
>> >>
>> >>
>> >> Martynas
>> >> graphityhq.com
>> >>
>> >> On Fri, Sep 19, 2014 at 7:14 PM, Joachim Baran
>> >> <joachim.baran@gmail.com> wrote:
>> >>> Hi!
>> >>>
>> >>>   I would reorder the URI as "http://eample/V2/P1234". That way you
>> >>> make it
>> >>> more explicit that you are talking about data set releases, each of
>> >>> which is
>> >>> defined by its own URI prefix. That way you can have two P1234
>> >>> residing
>> >>> side-by-side even though they might be completely different.
>> >>>
>> >>>   Should the version always be part of an URI? I would say yes --
>> >>> despite
>> >>> seeing your argumentation about the temporal interpretation of URIs
>> >>> that you
>> >>> gave.
>> >>>
>> >>> Kim
>> >>>
>> >>> On 19 September 2014 08:38, Andrea Splendiani
>> >>> <andrea.splendiani@iscb.org>
>> >>> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> I'm posting here a question I have posted in some other forums.
>> >>>> How do you go about versioning ?
>> >>>>
>> >>>> I tend to think at the URI as pointing to the endurant, and this
>> >>>> leaves to
>> >>>> the "version" the meaning of "what was known/true about an entity at
>> >>>> a given
>> >>>> time". The latter is conveniently packed in a graph, whose URIs can
>> >>>> be
>> >>>> conveniently linked to the endurant URI.
>> >>>>
>> >>>>
>> >>>> So http://example/P04637 is the protein URI that returns what is
>> >>>> currently
>> >>>> known about this protein.
>> >>>>
>> >>>> http://example/P04637/V2 is the URI of a version (a set of
>> >>>> statements)
>> >>>> that return what is known for http://example/P04637 at a given time.
>> >>>>
>> >>>> Note that http://example/P04637/V2 doesn't appear in results (except
>> >>>> in
>> >>>> predicates linking different versions, like "replaces")
>> >>>>
>> >>>>
>> >>>> Basically I never have an assertion as:
>> >>>>
>> >>>> http://example/P04637 hasVersion 2, but version is only used to
>> >>>> filter
>> >>>> which pack of information is relevant. So if I mix results from
>> >>>> different
>> >>>> versions (e.g. quads) I can filter what is relevant and where to me.
>> >>>>
>> >>>>
>> >>>> Is this a common way of doing things ?
>> >>>>
>> >>>> If not, have you thought about it and if you took alternatives, why ?
>> >>>>
>> >>>>
>> >>>> best,
>> >>>>
>> >>>> Andrea
>> >>>
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> Stian Soiland-Reyes, myGrid team
>> School of Computer Science
>> The University of Manchester
>> http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718
>
>



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718

Received on Monday, 22 September 2014 12:37:46 UTC