Re: How do you go about versioning ?

Andrea,
 the "range of verifiability" extends so long as the linked resources
are also trustyuris. You could, of course, cache and hash those linked
assertions, for posterity.


m.

On Sun, Sep 21, 2014 at 2:42 PM, Andrea Splendiani
<andrea.splendiani@iscb.org> wrote:
> 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 22:17:14 UTC