Re: Examples in the LDP primer

So, we all understand the following:—

Just because a URI denotes something which isn’t itself a web resource doesn’t mean that de-referencing the URI doesn’t work — that’s rather the point of Linked Data. If I assign a LD URI to a copy of a printed book, dereferencing it results in data about that book (i.e., a web resource) being returned. The *URL* of that web resource is not the same as the *URI* for the book, even though dereferencing them both will ultimately result in the same resource being delivered to the user-agent (there being a couple of different ways of doing that).

Moreover, and I feel quite strongly about this:—

There’s no particular reason to be imprecise about this, nor to promote patterns which conflate the two, it just seeds further confusion. The benefits of the examples reading -slightly- simpler are massively outweighed IMO by downsides of promotion of misconceptions in a wider audience.

The examples should be, oddly enough, exemplars. When learning, people rely on examples to show them the right way of doing things. While there might be disagreement in general about what *is* ‘the right way’, opting for something which is clearly wrong instead really doesn’t help anybody.


On  2013-Dec-18, at 10:11, Roger Menday <> wrote:

> Well, I think there isn't a clear cut answer on this one. I appreciate the answers from Kingsley, but, when appealing LDP to a broader audience, a lot of people will probably appreciate the simplicity that comes from allowing a URI entity to also be directly de-referencable ??
> My opinion is that we are 'good' in the Spec, use both ways in the Primer, and (as Steve suggested) outline the pros-and-cons of both in the BP&G.
> Roger
> On 16 Dec 2013, at 20:37, Kingsley Idehen wrote:
>> On 12/16/13 1:20 PM, Wilde, Erik wrote:
>>> On 2013-12-16, 10:11 , "Kingsley Idehen" <> wrote:
>>>>   On 12/16/13 12:31 PM, Roger Menday
>>>>     wrote:
>>>>     Maybe we should be good in the Spec, and be naughty in the
>>>>       Primer ... (?)
>>>>   No, once its naughty it just gets naughtier and harder to rectify.
>>>>   History (e.g., RDF and Web) shows, it can even take 13 or so years
>>>>   to fix the ensuing misconceptions.
>>> agreed that it's different for linked data, but on the web, having
>>> identifiers that do not resolve is perfectly acceptable. that's why
>>> hypermedia links are typed: you follow the ones where the type implies
>>> they're dereferencable, and you only use them as identifiers where the
>>> type implies they are identifiers only.
>>> i am not sure if what roger suggests is to point out that this is what's
>>> natural for the larger web and REST in general. i agree that we should be
>>> careful to promote/show patterns that are not exactly the way how things
>>> should be done in a certain context, but then again, if that demonstrates
>>> how things are done in practice (even though it may not be the ideal way
>>> of doing them), then there might be value in describing those examples as
>>> well.
>>> cheers,
>>> dret.
>> As far as I can understand, Roger is seeking clarification about entity (thing) denotation using HTTP URIs. Right now, we have examples in the LDP specs that inaccurately denote entities (that aren't Web accessible Resources) using HTTP URLs.
>> As I said, an HTTP URL is an HTTP URI that denotes a Web Resource.
>> A WebID is an HTTP URI that denotes an Agent.
>> HTTP URIs can be used to denote anything i.e., any kind of entity.
>> Another way to look at this is through the difference between "words" and "terms" .
>> A "term" is a specialization of a "word" i.e., a "term" is a "word" that embodies denotation (naming) and reference such that a name resolves to the description of its referent. [1]
>> The World Wide Web is comprised of webby words i.e., words link to documents (using controls like <a/> in HTML , no referent description is implied this particular association.
>> The RDF based Linked Open Data Web is comprised of webby terms i.e., you have denotation and reference at the very core.
>> [1]

Mo McRoberts - Chief Technical Architect - Archives & Digital Public Space,
Zone 2.12, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
MC3 D6, BBC Media Centre, 201 Wood Lane, London W12 7TQ,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E

This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to

Received on Wednesday, 18 December 2013 10:38:20 UTC