Initially (in summer 2006), Tim Berners Lee composed the Linked Data publishing guideline to address shortcomings of predominant data providing practices in the Web and to promote the benefits of utilizing Semantic Web knowledge representation models for that issue. Later, people started realizing the independency of these principles to concrete applied technologies, i.e., the Linked Data publishing guideline is generally independent from Semantic Web technologies. This movement is especially propagated by Kingsley Idehen (see [1]).
The Linked Data publishing guideline addresses the following five main principles. Whereby, the fifth one is a recently made, optional addition that was suggested by Matthew Rowe (see [2]).
- Use a name reference mechanism for resource identification, e.g., URIs (cf. the first interface constraint of the REST architectural style).
- Use an information resource delivering mechanism on top of that name reference mechanism, e.g., a URI scheme, for example, HTTP URIs, to enable the transfer of a document that contains at least the information resource to a requested resource identifier (cf. the second interface constraint of the REST architectural style*).
- Use a resource description mechanism to facilitate the expression of knowledge (assertions) regarding the denoted resource, e.g., RDF (cf. the forth interface constraint of the REST architectural style).
- Provide a resource connection mechanism to permit the embedding of links. They refer to other resources to establish meaningful (unambiguously as possible) interpretations of a received information resource. This enforces knowledge exploration, e.g., via the HTTP Link header field, if, for instance, the specification of the media type does not make link embedding in the representation possible (cf. “follow your nose” and the fifth interface constraint of the REST architectural style).
- Provide an information resource modification mechanism by allowing (optionally) the transfer of (a) modification(s) of received content by using the resource identifier of the request, e.g., changes are entered in a (HTML) form and sent to the server by applying the HTTP PATCH method (cf. the third interface constraint of the REST architectural style).
Thereby, especially the last principle directs into a read and write enabled Linked Data information space scenario (see [3]). A good overview of relevant specifications for Linked Data in the context of the Semantic Web can be found at linkeddata-specs.info.
*) Note, this constraint was later explicitly phrased, see the referenced presentation.
[1] Idehen, Kingsley; “What is Linked Data, really?”; openlinksw.com; 2011
[2] Rowe, Matthew; “A Proposed 5th Rule/Principle for Linked Data: Push”; matthew-rowe.com; 2010
[3] Berners-Lee, Tim; “Read-Write Linked Data”; w3.org; 2010
Further related resources:
- Ferris, Bob; “The common, layered Semantic Web technology stack”; smiy.org; 2011
- Ferris, Bob; “On Resources, Information Resources and Documents”; smiy.org; 2010
Some More Individual 
Afternoon – rules 1-2 look pretty sound, 3 is more of a “provide a way to have linked data / RDF googles”, and as for 4 & 5:
Link header is representation metadata, not resource level (can’t be used to make links from the effective request uri) – this is the grand misunderstanding on the web, people think that a link rel is from the uri, it’s not, it’s from the representation, and the representation isn’t named with a uri. { [] a :Representation } you might say, although technically { {} a :Representation . } is more correct.
You can’t PATCH a graph unless you’re using rdf diff in N3 [ http://www.w3.org/DesignIssues/Diff ].
best,
nathan
Nathan, please consider that issue 1-4 should reflect a generalisation of timbl’s Linked Data publishing guide.
The HTTP Link header is only a possiblity for a resource connection mechanism especially for representation formats where link embedding is not possible, i.e. media types for graphics that do not have any metadata component. For this reason it should be an opportunity to provide an “is-described-by” statement that references a resource description of that concrete representation. In that resource description I can especially reference also the “effective request uri”.
Maybe, I have chosen a bit inappropriated example by mentioning HTTP Link header here 😉 (hypermedia types have that resource connection mechanism inbuilt).
From my point of view, I would consider the especially the Content-Location URI as the URI of the representation. However, please consider that I wouldn’t infer any from that component interaction, but rather everything from the delivered content – the resource description(s).
Of course, I have to describe the modification somehow. However, this is more or less an implementation detail. Please also consider, that even HTTP PATCH is here only a mentioned example.
Hey, I know what you mean, but sadly “I would consider the especially the Content-Location URI as the URI of the representation.” is false, all URIs, even those in the Content-Location refer to resources, the binding between resource and representation is /always/ 1-*, and thus representations are never identified by a URI, even if the Content-Location is used.
Do see this list which explains all, going by the specification(s).
Yes, I know what you mean. However, the bits of the e.g. HTML file (the origin of the representation) on the server should be exactly transmitted to the client. So the representation that the client then has is somehow equal to the HTML file on the server, or? That is why, one can may conclude that the concrete realization that is referenced via the Content-Location header, can “represent” the transferred representation. From my point of view, one initiate a request with a resource URI and the information provider would deliver a realization of the information resource that is identified via the document URI.
Nevertheless, please also consider the statement from me that I quote above 😉
PS: the Linked Data Architecture project has even a more comprehensive list that lists possible response codes (see here)
just noticed: “(hypermedia types have that resource connection mechanism inbuilt)” – you may be surprised to know, they don’t actually have resource connection mechanisms in built.
<link rel=”foo” href=”bar” />
actually == [ foo <bar> ] .
not <u> foo <bar> .
I recognize your path well my friend, have came to all the same conclusions you have, only to later find they were false.
Here, I would disagree, because if do not explicitly refer the subject, it would automatically use the URI of the document that is the enclosure of these statements. So, yes I would view the link element with rel relations as a resource connection mechanism.
(I’m really interested in further opinions to that issue e.g., from timbl or mamund)
Pingback: Tweets that mention A generalisation of the Linked Data publishing guideline | Some More Individual -- Topsy.com
rel=nofollow,external,noreferrer,bookmark,author,help,alternate,ping to name just a few, why don’t you have a quick read of the HTML 5 specification and see what they link from and to – somethings like nofollow and noreferrer don’t even link to anything, let alone from anything, things like alternate/help/bookmark depend entirely on context – but not one of them, ever, links from a resource to another resource, always from the representation, from some context (like an html element), or from nothing at all. Web Linking RFC will back this up.
I too always /assumed/ “links” were from resource to resource, until I read the specs, and found precisely nothing to back-up my assumptions, in fact it was quite the opposite. Just check the specs, you’ll see.
Nathath, I guess, all your mentioned relation types have in common the document URI as subject (or source element). Even “nofollow” and “noreferrer” have a referenced object (target element). So the resource connection mechanism still works. Even if there is not explicitly a relation type defined, then we have an untyped link (, which is btw itself also a type – “untyped” 😉 ).
Everytime, you associate a target somehow to a source element, then you describe a relationship or connection (from my point of view). Maybe, you didn’t recognized my view, that a representation (in the narrower sense) is at least in my definitions a sub class/type of resource (to be more concrete of realization), because everything is a resource (see “On Resources, Information Resources and Documents”.
Please notice, that I didn’t make any statement about, which resources are related and how the relationships from the delivered realization of the information resource to the requested resource have to be established.
PS: You can believe me, I checked very much the relevant specs during the last time. I’m now quite happy with my point of view that makes sense on that issues (at least for me 😉 ).
I’d rather see the Linked Data principles become less nerdy / technical. This characterisation introduces a lot of technical jargon that 99.9% of humans won’t understand.
The message as I understand it, is that data can be shared in the Web using the same techniques as other information, like the millions of Web pages we’re already used to seeing. And then when your Web data mentions other things that can be described in the Web, it’s good to use normal Web URIs (URLs to everyone else) as identifiers, so the information can be found and merged, and so that these little pieces of data can be linked together.
That’s still too nerdy for 99.525% of humanity, but if we can avoid talking about referents and resources and http headers, I’d guess we’ll be heading in a more universally understandable direction.
Thanks a lot for your response Dan. Yes, of course, the description of the guideline presented here is not intended to be fully graspable by endusers, because they won’t care about such a generalisation. Btw, the short (technical) form could look like the following one:
Anyway, endusers are not really interested in the applied technology and mechanism behind at all. They like have a machine (helper) that assist them by executing certain tasks. Thereby, the message (as you also said) is the same as always, which exists right from the beginning of the WWW project – “Let’s Share What We Know”.
Overall, it might be the best to hide URIs as much as possible (cf. my thoughts here) e.g., I can easily create a reference in a Facebook message by typing an ‘@’ and by entering further letters a filter is applied that reduces the information space for reference selection; thereby, I don’t see any URI at all (all the time nice human readable labels). That’s usability! URIs in general don’t deliver a quite good user experience if they are visible. However, the name reference mechanism behind delivers a cool user experience.
PS: I think that ‘referent’ and ‘resource’ (or synomyms of it) are not bad words for an everyday audience. I rather believe that they are quite natural.
Pingback: Problems of Linked Data 1/4 Identity