Identifiers 2.0 new internal WD

[Marco Molinaro]

Hi Norman, Markus, all,

2015-05-13 11:28 GMT+02:00 Norman Gray <norman at astro.gla.ac.uk>:
> I think I was a little elliptical, sorry.

more probable: I am thick-headed. Thanks for clarifying.

> Consider for example an IVORN like ivo://norman/weather?2015-05-13.  Its value might be 14 degrees, and its description 'today's weather'.  Tomorrow, I will have to change its description to 'yesterday's weather', but its name will remain ivo://norman/weather?2015-05-13, and its value will remain 14 degrees even if we have a heat-wave (20 degrees -- the human body can't stand it!!).
>
> If, on the other hand, I have a resource ivo;//norman/weather?today, then its value today will be 14 degrees, and its description will be 'today's weather', but its _value_ tomorrow (as opposed to its description) will change.
>
> So, presuming that the 'logical resource' here is the value 14 degrees (in practice, presumably a larger dataset), is this  resource ivo://norman/weather?today conformant with the prescription 'Furthermore, the identifier SHOULD refer to at most one logical resource over all time; that is, IVORNs should not be reused.'?  Or, put another way, what is a 'logical resource' (the term appears only here)?

I think here "logical resource" couples with the "discretion of the
publisher" and generates the _OR_ between forbid and permit you're
trying to fix.

> I think it would be reasonable to permit this (or at least unreasonable to forbid it at this level), but I could read the text here as forbidding it _or_ permitting it.  Of course, we wouldn't want people to re-use identifiers which have simply fallen out of use.

> _If_ this is to be permitted, then can I suggest as alternative text:
>
>     Furthermore, an identifier SHOULD refer to at most one resource over time; that is, IVORNs should not be reused for unrelated resources.  Note that a resource may potentially be dynamic (such as 'weather at telescope' or 'current version of the standard') -- here, there is a conceptually unique resource, even though the content of it may change in time.
>

>From my understanding, it is permitted and your alternative text seems
attractive to me, but it's up to the authors :)
My claim, when I thought of this before, was: if I use
ivo://my.auth/resource for an SCS, and later for a TAP (or even a data
collection), a change that is permitted as per the reasoning above,
would this impact Apps? (in an ideal world the answer is: no)
I think that's the reason for last sentence in paragraph 1 in Sect.3,
not for the one you've offered a re-wording.

> Sentence 2 in this section does, I think, rule out a resource such as ivo://foo/version-of-the-server which might be different (is this right?) depending on which registry you resolved it from.  Is that what that sentence was getting at?

uniqueness within IVOA means to me that, whatever the registry,
ivo://foo/version-of-the-server brings you the same (quite) VORes
description. So, I think the answer is yes, you cannot make an IVORN
resolve to 2+ resources.

ciao
    Marco

>
> All the best,
>
> Norman
>
>
> --
> Norman Gray  :  http://nxg.me.uk
> SUPA School of Physics and Astronomy, University of Glasgow, UK
>