- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sun, 19 Jun 2011 20:34:45 +0100
- To: public-lod@w3.org
On 6/19/11 2:26 PM, Hugh Glaser wrote: > On 19 Jun 2011, at 13:04, Kingsley Idehen wrote: > >> On 6/19/11 12:05 PM, Hugh Glaser wrote: >>> "A step too far"? >>> >>> Hi. >>> I've sort of been waiting for someone to say: >>> "I have a system that consumes RDF from the world out there (eg dbpedia), and it would break and be unfixable if the sources didn't do 303 or #." >>> Plenty of people saying they can't express what they want without it. >>> And plenty of people saying they can't write some code that they might not be able to understand some RDF they receive properly. >>> But no actual examples in the wild (at least as far as I can tell in a lot of messages). >>> >>> This might be for quite a few reasons, such as: >>> 1) There are no such consuming systems; >>> 2) The existing consuming systems would not break. >>> >>> Number (1) would be too embarrassing, and is wrong because I have some, so I'll think about number (2). >>> >>> There seem to be some axes in the discussion: >>> publish / consume >>> long/medium term / shorter term >>> ideal / pragmatic >>> Interestingly, we don't seem to have a strong theory / practice axis, which is great. >>> >>> As a publisher, I/we have had to work pretty hard to conform to really quite complex requirements for publishing RDF as Linked Data; not just Range-14, but voiD, sitemaps and various bits and pieces that Kingsley always tells me to do in the RDF. >>> As a consumer, it has been pretty simple: "Well guv, thanks for the URI, here's some RDF." >>> It has always been something of a source of angst (if not actual pain) to me that none of the extra work I put into publishing RDF is ever used by me or anyone else, as far as I know. >> Er. we use it :-) > Er, I'm not sure you do :-) > You certainly consume it, and a very nice job you do to. > But the "use" is more than generic browsers - it suggest to me that something useful might happen as a result of the consumption (perhaps I learn that I can ask Jim to introduce me to Mary, as he knows her better than anyone else I know). Yes, and this is coming. Basically, as part of the WebID (powerful Linked Data and FOAF exploitation) Henry, I, and others are working on use of our respective efforts for semantically enhanced friending. We not only handle friending we also handle notifications such that from a single blog post, address book entry, calendar item creation of change etc., notices get progagated, but all of this is driven by a WebID (a personal URI). In addition to all of this, we have WebID based ACLs for powerful resource sharing etc.. We (at OpenLink) have even extended S/MIME with WebID which makes a world of difference re. helping folks regain control of their in-boxes and basically fixing email. > These things are usually called applications, or possibly services. Yes, that's the key to the matter. Make apps that make a difference via the standards we promote. Put differently, promote our beliefs via apps that illuminate standards that be believe in and promote. > They tend to be reasonably domain-specific, as generic things tend not to be easy to sue, or even fit for purpose for end users. > Sorry if I have missed stuff. Address Books, Calendars, Blogs, Discussion Forums, Comments, Pingbacks, In-boxes & Drop-boxes, Photo Albums, and Galleries etc.. all benefit immensely from Linked Data, we just need more applications as a few have existed in isolation for a while :-) Re. apps., one of the real problems with Linked Data is that the LINK is the key too everything. That said, when dealing with Apps., most think about UI first, and that's where matters can get confusing real fast i.e., some attempts at visualization utterly compromise Linked Data's essence. Likewise, slapping UI on to Linked Data with illuminating its essence in mind also introduces its own set of problems. [SNIP] -- Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Received on Sunday, 19 June 2011 19:35:22 UTC