- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 04 Mar 2013 07:48:25 -0500
- To: public-ldp-wg@w3.org
- Message-ID: <51349819.1040203@openlinksw.com>
On 3/4/13 7:32 AM, Pierre-Antoine Champin wrote: > Kingsley, > > agreed, linked data is about using dereferenceable URIs everywehere, > so that everyone can discover the meaning of a URI they do not know. > > This is only one kind of affordance, though, and a client *has* to > start with some built-in knowledge for a set of URIs (just like > someone can not learn a new language by relying on a dictionnary, as > every word is described by other words). > > My argument was that other kinds of affordance as possible as well, > provided that you know how to interpret a given (set of) triple(s) -- > not only by dereferencing every URI "blindly". Yes, but there's an important difference between RDF and Linked Data eternally overlooked, they aren't the same thing. RDF enables one create very powerful Linked Data via the fusion of machine-comprehensible semantics and Web-scale data access that baked into structured data representation. As for understanding what one de-references, when dealing with RDF based Linked Data, the data consumer (human or machine) must understand RDF based entity relationship semantics. There's no way around that, hence the important role played by schemas/vocabularies/ontologies. Web-scale first-order logic (comprehensible by humans and machines) is the implicit affordance delivered by RDF based Linked Data, RESTfully :-) Kingsley > > pa > > > On Mon, Mar 4, 2013 at 12:16 PM, Kingsley Idehen > <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote: > > On 3/4/13 6:33 AM, Pierre-Antoine Champin wrote: >> Erik, >> >> I agree with you that RDF in itself does not provide affordances, >> and that the fact that it uses URIs does not mean that those URIs >> are links (in the hypermedia/REST sense). > > Yes, that's true re. RDF. > > RDF based Linked Data on the other hand do require HTTP URIs to > provide specific behavior i.e., said URIs resolve to documents > that describe the URI's referent. Every RDF based Linked Data > document bears content that describes something. The content takes > the from of an RDF model based entity relationship graph. > >> >> I think, however, that (RDF + some built-in knowledge about a >> given vocabulary) does provide affordances. > > As per comment above, when talking about RDF based Linked Data > since the "Linked Data" part is where the affordances come into > play re. link behavior. > >> For example, a client knowing what foaf:depication means can use >> it to provide a better representation of the depicted resource. > > Only if the entity in question is denoted using a de-referencable > URI (e.g., an HTTP URI). > >> >> The goal of the LDP recommendation is to describe the built-in >> knowledge that all LDP-client are expected to have about the ldp: >> vocabulary. And this knowledge about the ldp: vocabulary should >> apply to *any* RDF graph that the client encounters, regardless >> of the media-type it got it from (Turtle, RDF/XML, RDFa...). So I >> disagree with you that we need a specific media-type for LDP. > > Correct, this argument with Erik is basically been going on > forever. It resolution can only truly occur via solution > implementation and demonstration. > > RDF != Linked Data. > > RDF based Linked Data is what LDP is based on. Thus, the > affordances and everything else are totally baked in, as Henry has > demonstrated repeatedly via the use of ontology definition to > navigate these matters. > >> >> Of course, it would be good to provide the client with a hint of >> the vocabularies it can expect to find in some RDF, even *before* >> parsing it. This is where I think your profile proposal adds some >> value, as something *orthogonal* to the media-type. > > In reality, the whole thing (RDF based Linked Data) is a close > loop. The challenge is getting to the point where > ontologies/vocabularies and demonstrations drive the LDP dialog > instead of prose. > > RDF based Linked data is a fusion of data representation, access, > and first-order logic. It's all about relations and their semantics. > > Kingsley >> >> pa >> >> >> On Mon, Mar 4, 2013 at 9:50 AM, Wilde, Erik <Erik.Wilde@emc.com >> <mailto:Erik.Wilde@emc.com>> wrote: >> >> hello john. >> >> On 2013-03-03 18:41 , "John Arwe" <johnarwe@us.ibm.com >> <mailto:johnarwe@us.ibm.com>> wrote: >> >Erik, your HTML example strengthens the suspicion that had >> been growing >> >in me about your initial response (paraphrased playback) >> "the rows on >> >that page are not affordances", i.e. about how you were >> using the word. >> >As you're >> > using it, affordances are at a higher level of abstraction >> and what the >> >wiki page lists (or did, last I looked - on a plane now so >> unable to >> >check) are "just" spec options - things overtly relegated to >> >implementation choice. Those would have an n:m relation >> > with affordances, by your definition. Getting closer? >> >> do you have any idea where the >> http://www.w3.org/wiki/RdfAffordances page >> originates? i would argue that it contains some really >> misguided ideas, >> such as looking at the URIs in RDF as links. this mixes RDF's >> data model >> (which happens to be URI-based) with an entirely different >> issue, which is >> the question of how to represent hypermedia affordances (now >> i am using >> the term as i am used to it from the hypermedia/REST >> community), and once >> you start doing that, i don't think there's any way to get >> out of this >> initial conflation of concepts. >> >> for me, affordances are the critical parts of hypermedia >> formats that >> guide clients through the media type, allowing them choices of >> navigational paths while they are traversing the interlinked >> set of >> resources exposed as hypermedia. RDF doesn't have anything to >> contribute >> here as it doesn't have links. so affordances (again, in my >> view of the >> term) would be the kinds of things a hypermedia format such >> as LDP would >> add, saying "when you find this link in a representation, >> then you can >> follow it, and you have to interact in the following way when >> you follow >> it, and then you can expect the following thing to happen." >> >> cheers, >> >> dret. >> >> >> > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web:http://www.openlinksw.com > Personal Weblog:http://www.openlinksw.com/blog/~kidehen <http://www.openlinksw.com/blog/%7Ekidehen> > Twitter/Identi.ca handle: @kidehen > Google+ Profile:https://plus.google.com/112399767740508618350/about > LinkedIn Profile:http://www.linkedin.com/in/kidehen > > > > > -- 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 Monday, 4 March 2013 12:48:49 UTC