Re: How do you go about versioning ?

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

Received on Monday, 22 September 2014 11:05:41 UTC