Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]

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