hvdsomp / signposting

7 stars 0 forks source link

actionable Target IRI #2

Closed hvdsomp closed 6 years ago

hvdsomp commented 6 years ago

The current language requires the Target IRI of an "identifier" link to be actionable and describes actionable as:

actionable means that protocol-based read access to the resource identified by the URI is possible. For example, an HTTP URI is actionable because read access is possible by issuing an HTTP HEAD or GET request against the URI.

The motivation is to avoid the use of non-actionable identifiers, in the sense that we want the agent to be able to follow it's nose to the Target IRI and be able to move forward from there. But John brought an issue up:

Would email addresses count as social ids? (eg, I confuse people with my multiple address, with jak@ucop.edu preferred)

Which suggest that mailto: should be an acceptable URI scheme, even though it's not actionable in the above sense.

So: Should the actionable aspect be relaxed, e.g. not be part of the definition but just something that is mentioned in passing as recommended?

And also: Does this have impact on the permitted cardinality of "identifier" links. The current language says there should only be one. Should that become one per URI scheme?

hvdsomp commented 6 years ago

This comment by Simeon fits under this issue as it really argues in favor of an actionable identifying URI:

finally, should there be a stronger statement about the expectation (perhaps even using a SHOULD) that resolving/following-redirects from the identifying URI gets one to a copy of part of the "same thing" that the actual URI resolved too? I think the language will be tricky because there isn't a definition of "same thing" (and probably can't be), but at the moment this seems implied by the purpose of reference but not make explicit.

But is also seems to suggest requiring "same content". I really don't think we can do that. For example, that requirement does not hold in the Preferred Social Identifier case, e.g. linking with "identifier" from one's homepage to one's ORCID.

hvdsomp commented 6 years ago

I would like to add something to this thread. The "identifier" link is about providing a URI that is preferred for referencing. That means, an agent working on behalf some kind of application (e.g. bookmarking tool) picks up the URI from e.g. the Link header and uses it as a reference in its environment (e.g. stores it in its bookmarks dbase). Later on that URI is being re-used. It is because of that re-use that we want the URI to be actionable. If it's not, the agent is stuck when the URI is being re-used.

zimeon commented 6 years ago

The key idea (as @hvdsomp mentions) is that we can use the identifying URI as a more stable and long-lived alternative to the actual/access URI. It seems to me that unless it resolves to something that has a reasonable correspondence with the resource identified by the actual/access URI, it doesn't serve that purpose. Even in the social id use case, we say "because it is most complete, kept up-to-date, or expected to be long-lived" which still suggests actionable in the sense of resolvable.

I wonder whether the name "identifying URI" is catching us up a bit here -- identifying isn't the key concept, referencing is. I hesitate to suggest is, but should we even consider calling it the "referencing URI" or "reference URI" instead?

hvdsomp commented 6 years ago

I could live with @zimeon's suggestion to use "referencing URI" or "reference URI". It is indeed the most accurate term to convey the intent as per the discussion in this thread.

The wording may become a bit awkward in that we would end up with sentences like "the referencing URI, which is the preferred URI for the purpose of referencing" But this would have to be checked in the text itself.

We definitely want a decision on this prior to submitting ID-00 to IETF.

hvdsomp commented 6 years ago

I used "reference URI" and it actually works. However, I am a tad worried now that we may get IANA feedback that we should name the relation type "reference" instead of "identifier". Which I really don't want to do as we have been promoting "identifier" for some time now.

phonedude commented 6 years ago

I understand the reasoning for "reference" and I'm partially sympathetic to it, but I'm also concerned about H's point that the feedback will be s/reference/identifying/g and then we'll end up with a registered rel type that few people understand ("that's just for library stuff, right?") and doesn't have an obvious tie with what is likely the major use case (doi/handle/purl/ark/etc.)

I would prefer "reference" to be used in fleshing out the idea of "identity". It seems to me the real utility is supporting the "if you can only link to 1 thing, this is the thing you should link to". That can be bc of part/whole relationships, "first-among-equals", or "start at the `top' and follow your nose bc things might have changed". All of those things feel like "identity" or "preferred identity".

hvdsomp commented 6 years ago

This feedback by @phonedude and some further thinking I did led me to changing the terminology back to identifying URI:

hvdsomp commented 6 years ago

I think this issue is resolved. We found a good solution.