- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 26 Nov 2013 09:59:14 -0500
- To: public-lod@w3.org
- Message-ID: <5294B742.3060602@openlinksw.com>
On 11/26/13 9:48 AM, mike amundsen wrote: > Martynas: > > No "by extension" needed here. Affordance is a quality of a thing that > allows action. > > RDF alone (w/o an added ontology) affords "data interchange." RDF on its own does offer a little more than data interchange. It enables structured data representation where actual relationship semantics are discernible and comprehensible by both humans and machines. Kingsley > > > On Tue, Nov 26, 2013 at 7:24 AM, Martynas Jusevičius > <martynas@graphity.org <mailto:martynas@graphity.org>> wrote: > > Mike, > > You wrote > > > Yes, > > > > <http://example.com/xxxxx> a foaf:Image . > > > > is an affordance. > > Then, by extension, RDF classes are affordances, and vocabularies are > specifications of them. > So this gives me the impression that Linked Data applications can > solve the affordance issue using the standard components that have > always been there - RDF and vocabularies/ontologies? > > Martynas > graphityhq.com <http://graphityhq.com> > > > > > > of course, that affordance (like HTML.IMG) relies a number of > expectations > > which most all of us recognize when we see it. > > > > From the network perspective, the expectations are (to keep it > simple): > > - this is a "safe"[1] and "idempotent"[2] operation > > - an image media type to be returned. > > > > From the client application perspective, the expectations are: > > - use an HTTP.GET when executing this operation > > - take the results of the locator and "transclude" it into the > existing view > > > > if any these expectations are not fulfilled, the affordance is > usually > > considered "broken" (the network failed) or "mis-used" (the > client did > > something else). > > > > <snip> > > By the way, nothing stops me from having <a > href="isbn:343-224122"> either. > > It will probably be clickable, but won't work. > > </snip> > > I would restate this as "it is *possible* to have..." since > there is, > > actually something that stops you - the expectations of so many > others who > > recognize this affordance. > > > > Think of the HTML.A as a door in a room. If i go up to a door, > turn the > > handle, and nothing happens (I don't "navigate" to a new room), > I consider > > the door broken or (as Donald Norman might say) that the door is > "lying to > > me." If I encounter a home where many of the doors act in this > unexpected > > way, I find the experience off-putting. I might even judge the > architect > > incompetent to, at the least, perverse. > > > > Now consider a hypermedia representation where many of the > affordances are > > either not working as expected (as in your case) or are actually > inscrutable > > to me; ones that just don't tell me enough to be usable. > > > > There is an advantage to using affordances in that they offer a > shared > > understanding without the need for narrative or instructions. > That's why we > > can drive most vehicles if we've already learned to drive one. > Why we can > > operate most telephones, etc. Devices that have unfamiliar or > > counter-intuitive affordances are frustrating and, in some rare > cases, can > > be dangerous. > > > > > > > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1 > > [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2 > > > > > > mamund > > +1.859.757.1449 <tel:%2B1.859.757.1449> > > skype: mca.amundsen > > http://amundsen.com/blog/ > > http://twitter.com/mamund > > https://github.com/mamund > > http://www.linkedin.com/in/mamund > > > > > > On Fri, Nov 22, 2013 at 12:16 PM, Martynas Jusevičius > > <martynas@graphity.org <mailto:martynas@graphity.org>> wrote: > >> > >> Mike, > >> > >> so if RDF representation includes a triple such as > >> > >> <http://example.com/xxxxx> a foaf:Image . > >> > >> is that an affordance? Because that gives me enough information to > >> render it as <img src="http://example.com/xxxxx"/>. > >> > >> By the way, nothing stops me from having <a href="isbn:343-224122"> > >> either. It will probably be clickable, but won't work. > >> > >> Martynas > >> > >> On Fri, Nov 22, 2013 at 4:42 PM, mike amundsen > <mamund@yahoo.com <mailto:mamund@yahoo.com>> wrote: > >> > <snip> > >> > A browser for example doesn't render the string > >> > http://example.com/343-224122 as a clickable link unless you > mark it up > >> > as > >> > one using the <a> tag. > >> > </snip> > >> > > >> > Yep, the A element is the thing that _affords_ clicking. it > is the A > >> > element > >> > which is the affordance. > >> > > >> > Affordances don't just supply addresses, they supply > information about > >> > what > >> > you can _do_ with that address (navigate, transclude, send > arguments, > >> > write > >> > data, remove data, etc.). The appearance of a URL alone > provides very > >> > little > >> > affordance. > >> > > >> > For example: > >> > - http://example.com/xxxxx > >> > - http://example.com/yyyyy > >> > one of the two URLs points to a blog page to which the user can > >> > navigate, > >> > the other points to a logo which should be displayed inline. > which is > >> > which? > >> > > >> > Now this: > >> > - <a href="...">blog</a> > >> > - <img href="..." /> > >> > one of the two URLs points to a blog page, the other points > to a logo. > >> > which > >> > is which? > >> > > >> > Note it is not the URL that provides the information (which > is for > >> > navigation, which is for transclusion), but the element in > which the URL > >> > appears. The element is the affordance. These are HTML > affordances. > >> > There > >> > are a couple more hypermedia affordances in HTML. Other > message models > >> > (media types) contain their own affordances. > >> > > >> > It is the appearance of affordances within the response > representation > >> > that > >> > is a key characteristic of hypermedia messages. > >> > > >> > > >> > > >> > mamund > >> > +1.859.757.1449 <tel:%2B1.859.757.1449> > >> > skype: mca.amundsen > >> > http://amundsen.com/blog/ > >> > http://twitter.com/mamund > >> > https://github.com/mamund > >> > http://www.linkedin.com/in/mamund > >> > > >> > > >> > On Fri, Nov 22, 2013 at 10:13 AM, Markus Lanthaler > >> > <markus.lanthaler@gmx.net <mailto:markus.lanthaler@gmx.net>> > wrote: > >> >> > >> >> Hi Martynas, > >> >> > >> >> On Friday, November 22, 2013 3:12 PM, Martynas Jusevičius wrote: > >> >> > Markus, > >> >> > > >> >> > in the Linked Data context, what is the difference between > >> >> > "identifier" and "hyperlink"? Last time I checked, URIs > were opaque > >> >> > and there was no such distinction. > >> >> > >> >> These things quickly turn into philosophical discussions but > simply > >> >> speaking > >> >> the difference lies in the expectations of a client. In XML for > >> >> example, > >> >> namespaces are just identifiers. There's no expectation that > you can go > >> >> and > >> >> dereference that namespace identifier (even though in most > cases they > >> >> use > >> >> HTTP URIs). The same is true about RDF. All URIs are just > identifiers. > >> >> From > >> >> an RDF point of view, there's no difference between > isbn:343-224122 and > >> >> http://example.com/343-224122. As you say, they are opaque. > >> >> > >> >> But if you build applications, it is important to > distinguish between > >> >> identifiers and hyperlinks. A browser for example doesn't > render the > >> >> string > >> >> http://example.com/343-224122 as a clickable link unless you > mark it up > >> >> as > >> >> one using the <a> tag. > >> >> > >> >> Linked Data advocates that all URIs are dereferenceable. But > that's > >> >> communicated out of band. Apart from JSON-LD, which states > that URIs > >> >> SHOULD > >> >> be dereferenceable, no other RDF media type makes such a > statement. > >> >> Thus > >> >> you > >> >> need to use constructs such as hydra:Link and hydra:Resource > to make > >> >> the > >> >> distinction explicit. > >> >> > >> >> Hope this helps. If not, let me know. > >> >> > >> >> > >> >> -- > >> >> Markus Lanthaler > >> >> @markuslanthaler > >> >> > >> >> > >> > > > > > > > > > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 26 November 2013 14:59:46 UTC