Re: non-derefencable http URIs and oa:SpecificResource quibble

One advantage is that it can be non-dereferencable today, and
dereferencable tomorrow.

I recently made it so that IRIs we have used in our software to identify
workflow fragments, e.g.

http://ns.taverna.org.uk/2010/workflowBundle/2f0e94ef-b5c4-455d-aeab-1e9611f46b8b/workflow/HelloWorld/processor/hello/

are now finally dereferencable through a "guessed service", 4 years after I
constructed and started using that namespace. You can try it and modify any
of the free texts, and it will claim all of them exist.

These URIs, used in our provenance and annotations, are minted like Bob
Morris suggests with an embedded uuid, but they are created at desktop
applications around the globe without them registering anything with our
servers (in fact, many would be quite worried if the software did such a
registration).

Now in my case I "baked in" enough info in the url, at the cost of making
it rather long. A second approach is to do some indexing or search of
public instances.
On 21 May 2014 22:46, "Robert Sanderson" <azaroth42@gmail.com> wrote:

>
> Hi Bob,
>
> On Wed, May 21, 2014 at 2:13 PM, Bob Morris <morris.bob@gmail.com> wrote:
>
>> It's my understanding that nothing presently accepted
>> by IETF, nor anything in this draft, requires that an http URI must be
>> dereferencable.
>
>
> Nor anything currently in the HTTP specification, for that matter.
>
> If I am wrong, I'd like to know why. By this I mean "Where in a
>> specification document do I find the text that contradicts me?"
>>
>
> You're not wrong, as far as I know, ...
>
>
>> If I'm right, I would hope to see the OA section on SpecificResources
>> have the sentence
>> "If the Specific Resource has an HTTP URI, then the exact segment of
>> the Source resource that it identifies ..."
>> be changed to
>> "If the Specific Resource has a dereferencable HTTP URI, then the
>> exact segment .... "
>
>
> ... however there's the principles of linked data to be kept in mind as
> well.  Even though the specification of the HTTP URI requirements doesn't
> mandate it, Linked Data layers on top of that to create additional
> restrictions and assumptions, which is where the requirement for Specific
> Resources comes from.
>
> I'd be opposed to changing this, as then clients encountering an HTTP URI
> for a specific resource would be required to attempt to dereference it in
> order to determine if it was dereferencable.  The specification currently
> short-circuits that request, as it will frequently result in failure, by
> requiring that the URI be dereferencable if it's in the HTTP scheme and
> providing an alternative for when it isn't.
>
> Put another way, what's the advantage of allowing non-dereferencable HTTP
> URIs for specific resources?
>
> Thanks,
>
> Rob
>
>