Re: How do you go about versioning ?

HI,
having hashes as part of URIs is very very good, ihmo, for datasets. They are IDs by definition.
For other kinds of informations it depends.
If I get correctly your proposal, you use hashes that extend to all references (e.g.: they hash the hash...).
I wouldn't consider version of references as part the entity (in the general case), for the simple reason that you don't know where to stop.
Do you work with Tobias ?

best,
Andrea

Il giorno 21/set/2014, alle ore 23:00, Michel Dumontier <michel.dumontier@gmail.com> ha scritto:

> 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
>>> 
>>> 
>>

Received on Sunday, 21 September 2014 21:42:44 UTC