Re: How do you go about versioning ?

Hi!

  I think it would still work -- if you consider versions more complex than
just a single number.

  For example, the major/minor/patch versioning number approach would
permit you to have your concept under major version number 1. Then all
subsequent minor/patch updates still give you the latest concept when asked
for major version 1 only. That is a lot how versioning in software package
systems works.

  With that approach, you never ever have to go beyond major version 1 and
you get exactly the behavior as you desire. Having said that, if the
concept does change radically, you just transition to major version number
2 and get a whole new world of knowledge to populate.

  Does that make sense?

Best wishes,

Kim

On 19 September 2014 09:31, Andrea Splendiani <andrea.splendiani@iscb.org>
wrote:

> Hi, I don't think that would work in general.
> One of the issues that I have is that, in general, I don't want to change
> all references because a release changes.
> So if I link to CONCEPT1, that's the id. If CONCEPT1 gets new properties
> in time, it is still CONCEPT1 and I don't want to break the link.
> But basically, I use versioned URIs only for retrieval (they are named
> graphs ids) they "never" appear in the data (in case they do in metadata,
> but that's an additional layer).
>
> ciao,
> Andrea
>
> On Fri, Sep 19, 2014 at 6: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/ <http://purl.uniprot.org/uniprot/>P04637 is the protein URI that returns what is currently known about this protein.
>>>
>>> http:// <http://purl.uniprot.org/uniprot/>example <http://purl.uniprot.org/uniprot/>/ <http://purl.uniprot.org/uniprot/>P04637/V2 is the URI of a version (a set of statements) that return what is known for http:// <http://purl.uniprot.org/uniprot/>example <http://purl.uniprot.org/uniprot/>/ <http://purl.uniprot.org/uniprot/>P04637 at a given time.
>>>
>>> Note that http://example/ <http://purl.uniprot.org/uniprot/>P04637/V2 doesn't appear in results (except in predicates linking different versions, like "replaces")
>>>
>>>
>>> Basically I never have an assertion as:
>>>
>>> http:// <http://purl.uniprot.org/uniprot/>example <http://purl.uniprot.org/uniprot/>/ <http://purl.uniprot.org/uniprot/>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
>>>
>>>
>>
>