- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 05 Jun 2013 07:41:35 -0400
- To: Erik Wilde <dret@berkeley.edu>
- CC: public-ldp@w3.org
- Message-ID: <51AF23EF.9000603@openlinksw.com>
On 6/5/13 1:13 AM, Erik Wilde wrote: > hello kingsley. > > On 2013-06-04 15:17 , Kingsley Idehen wrote: >> On the assumption that we both agree there is no such thing as >> unstructured data: >> HTTP (Hypertext Transfer Protocol) transfers Data. >> RDF (Resource Description Framework) enables you describe and >> understand Data. >> RDF based Linked Data enables you describe, understand, and refer to >> Data by combining the items above. > > now that sounds really great, but it really is a bit generic. would > you mind spelling out for alexandre and me how a client that has no > prior knowledge of LDP will, when it encounters text/turtle LDP > resources, be able to figure out which links to follow with which > interactions (GET/PUT/POST/PATCH), what to send as request payload, > and what that is going to do in terms of LDP protocol semantics? thanks! > > cheers, > > dret. > > Simple, bearing in mind the assumption that LDP means "Linked Data Platform" i.e., the principled approach outlined in TimBL's meme about Linked Data applies. Steps: 1. denote (name or "refer to") entities using HTTP URIs. 2. create a document at a Web Addresses (an HTTP URI/URL) so that entity names (from #1) can resolve to the content of these documents. 3. use the RDF model (a W3C standard) to create document content that describes the named entities (from #1) i.e., describe these entities using RDF statements re., document content. 4. make your entity descriptions richer (and more useful) by adding relations that associate them with other entities . #4 means: keep on adding more RDF statements to your entity description as you discover more about the entity you are describing. The text/turtle matter: RDF (Resource Description Framework) is a composite comprised of: 1. Model -- First-order logic foundation 2. Syntax -- note, this is the grammar of the model 3. RDF Data Expression Notation -- this is where Turtle comes into play 4. Actual RDF Data Serialization -- Turtle also plays here. An RDF based system that also supports Linked Data principles MUST assume that text/turtle content is either RDF expression (meaning: text to be post processed en route to manifesting an RDF graph) or that its actually a serialization of an RDF graph). Every Relation (these are entities denoted by URIs too) in RDF is denoted by URI. The Relation entity plays the predicate role in an RDF statement (another entity). The predicate is the relationship facilitator comprised of a Subject and an Object. # Turtle Notation (describing entities using a collection of RDF statements/relationships) # <> a <#Document>; <#describes> <#StatementX>, <#subject>, <#object> . <#StatementX> a <#RDFStatement> ; <#subject> <>; <#object> <#Document> ; <#describedBy> <>. # Turtle end # Now, barring any typos, you can cut an paste the above into a document and then publish the document to the Web using then file create, save, and share pattern. Share the URL of the document, then based on the rules outlined you will be able to follow-your-nose (via HTTP URI de-reference) through the graph that manifests. Everything is related. The only question is how? This is what RDF based Linked Data is all about i.e., denote entities using URIs such that URIs resolve to their meaning via RDF based content that describes the URI's referent. This is ultimately a game of true or false since each Relation is a function. Thus, publishing the Turtle content above is enough to prove or disprove my claims. We don't need lengthy wordy arguments for that :-) -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 5 June 2013 11:42:04 UTC