- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 14 Apr 2015 08:52:33 -0400
- To: public-hydra@w3.org
- Message-ID: <552D0D91.9050808@openlinksw.com>
On 4/14/15 2:39 AM, Erik Wilde wrote: > > RDF, on the other hand, typically only exposes its metamodel and uses > the media type for serialization variants, assuming that saying "it's > RDF" is good enough. this makes resources self-describing *once you > process them*. RDF and metamodel is confusing characterization. RDF is a Language (system of signs, syntax, and role semantics for encoding and decoding information [data in some context]). RDF enables us express [in a form comprehensible to humans and machines] the fact that things exist in relation to other things, in a variety of ways, using a variety notations [how the sentences of a language are represented]. <link/> and HTTP "Link:" are valid notations for representing relations using RDF too. Unfortunately, that isn't emphasized in most RDF related literature. RDF is really a retrospective standardization of an aspect of the Web's fundamental design. Basically, the Web was always be about signs (in the form of HTTP URIs), syntax (triples or 3-tuples), and role semantics [1]. That's why "Link:" and <link/> are so powerful in regards to conveying the nature of the relationships types they facilitate. Their only shortcomings lies in their specificity to HTTP and HTML, respectively. RDF (the Language) doesn't have those limitations. Links: [1] http://bit.ly/evidence-that-the-world-wide-web-was-based-on-linked-data-from-inception -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 14 April 2015 12:52:58 UTC