In message <[email protected]>, Lee Passey 
<[email protected]> writes
>On 3/15/2011 5:00 PM, Richard Light wrote:
>
>> In message<[email protected]>, Lee Passey
>> <[email protected]>  writes
>>
>>> /No/ link is an identifier, except coincidentally. Whoever suggested
>>> that URLs could be identifiers, and that URIs should look like URLs but
>>> not be locaters should be scorned and ridiculed incessantly.
>>
>> That'll be Sir Tim BL, then, and the Linked Data principles?  Or is it
>> just non-dereferenceable identifier URLs you hate?
>
>If it's non-dereferenceable then it's not a URL.

Fair comment.  I packed one adjective too many into that phrase, in a 
misguided attempt at pithiness, and thereby produced nonsense.

What I was getting at is that the Linked Data approach is that 
identifiers (of concepts, not resources, and this is maybe the nub of 
this point-of-view mismatch) should be dereferenceable. IOW, identifiers 
should be links.

>If it refers to an
>identifiable resource (verbatim copies of which may exist simultaneously
>at different locations on the internet), and there is an implied
>agreement that the identifier will be used exclusively and permanently
>to reference that resource, then it's a URI.

... and therein lies an interesting difference.  The Linked Data URL 
adopts the opposite approach, by providing precisely one place where you 
can expect to retrieve the resource.

The advantage of the LD model is that you don't need any "implied 
agreement" about what you get when you dereference the identifier: it's 
what the publisher chooses to provide.  The disadvantage is one of 
scalability: you can't spread the load of requests for this URL - 
although of course it isn't necessary to dereference it every time, in 
order to use it.

>A reference that meets the syntactical requirement of both systems is
>possible, and this is where we engender confusion. A reference may
>/look/ like a URL but not be one, because the web context has changed or
>it was never intended to be one in the first place. A reference may
>/look/ like a URI but not be one, because the resource pointed to may be
>in a constant state of flux, or be replaced on a regular basis (the URL
>of a blog is certainly not a URI of the content).

OK, I'm certainly happy to agree with you that a URL which is meant to 
be an identifier, but which doesn't resolve to anything, is neither use 
nor ornament.

Conversely, though, I'm interested to learn how you get from the 
non-dereferenceable URI you describe to one of these multiple places 
where the information it represents is to be found.

>If an identifier begins with an indicator of a web protocol (http:,
>ftp:, snmp:, nnp:, ldap:, etc.) I assume it is a URL, and because the
>internet is dynamic I will also assume that it is /not/ a URI because of
>the fluidity of the internet. I could be wrong on both points, but I
>have no way of knowing without trying. I have found only one way of
>determining whether an identifier is a URI: Google it, and see if anyone
>is talking about it as though it were a URI (not very amenable to
>automated data processes).

Sure: this is partly a question of the context in which you find these 
chaps. (Which - possibly - brings us back to the kicking-off point of 
this discussion, which is where in the OL structure do you put different 
sorts of identifiers.)  If I find URLs as the subject, predicate or 
object of an RDF triple, I would have different expectations of them 
compared with URLs I found as links on a web page.

>What I hate is a system where an identifier cannot be distinguished
>between the two roles, leading even people like you to be confused about
>the two. Somewhere, someone took the notion of the Universal Resource
>Locator (as URLs were known in the Good Old Days) and said, "let's take
>the URL syntax and repurpose it to become Uniform Resource Identifiers.
>Sometimes a URI might be a URL, and that's close enough for government
>work." To misquote Garrison Keillor, "URLs and URIs are like the color
>green and the letter 'e'; sometimes you see a green 'e', but you learn
>not to expect it."

Well, yes: but that's back to my original point. The Linked Data "meme" 
(as they say) does involve overloading _some_ URLs with an identifier 
role. And using them to identify concepts leads to bizarre beasts like 
the "non-information resource".  Personally, I think that the Topic Map 
approach to identifiers is cleaner.  But there you go.

Best (and apologies to the list for the digression),

Richard

-- 
Richard Light
_______________________________________________
Ol-discuss mailing list
[email protected]
http://mail.archive.org/cgi-bin/mailman/listinfo/ol-discuss
To unsubscribe from this mailing list, send email to 
[email protected]

Reply via email to