Re: The Great Public Linked Data Use Case Register for Non-Technical End User Applications

On 6/24/13 9:12 AM, Antoine Isaac wrote:
> On 6/24/13 2:44 PM, Kingsley Idehen wrote:
>> On 6/24/13 6:23 AM, Antoine Isaac wrote:
>>> Hi Dominic,
>>>
>>> I agree with the relevance of the effort, and wouldn't argue against 
>>> centralizing. Not everyone will have the resource to search in a 
>>> decentralized fashion...
>>>
>>> What worries me a bit is how to learn lessons for the past. As you 
>>> (or someone else) has pointed, there have been previous attempts in 
>>> the past.
>>> For example http://www.w3.org/2001/sw/sweo/public/UseCases/
>>> I don't find the cases there super-technical. And is it really from 
>>> the past?
>>> Looking closer, it seems still open for contribution:
>>> http://www.w3.org/2001/sw/sweo/public/UseCases/submit.html
>>> Actually I have submitted a case there way after the SWEO group was 
>>> closed:
>>> http://www.w3.org/2001/sw/sweo/public/UseCases/Europeana/
>>>
>>> Now why do these things seem obsolete to newcomers?
>>> Just giving some account on what I've been involved in ...
>>>
>>> [Note: I'm sorry if sometimes it's going to read a bit as a rant. 
>>> It's not intended, just trying honestly to reflect the situation ;-) 
>>> It's also not purely about your case/requirement situation, but I 
>>> believe the issues are very similar!]
>>>
>>> [Perspective from the case providers]
>>> It's hard to know where to contribute. Existing don't often come in 
>>> the places where case owners are, or it's hard to tell whether 
>>> they're still open. And there's always a fresher initiative (like 
>>> the one you're trying to launch) which seems a good place.
>>> In fact I have actually created some updated description of the 
>>> Europeana case
>>> http://lodlam.net/2013/06/18/what-is-europeana-doing-with-sw-and-lod/
>>> But because the LODLAM summit was a more actual forum for me 
>>> recently, I've posted it there. And failed thinking of updating the 
>>> SWEO list, mea maxima culpa.
>>>
>>> [Perspective from the case gatherers] I have actually be involved as 
>>> 'initiator' of a couple of listing.
>>> 1. SKOS datasets (which are a kind of 'case for SKOS')
>>> We started with a web page:
>>> http://www.w3.org/2004/02/skos/data
>>> but as the list was difficult to maintain we soon created a 
>>> community-writable wiki:
>>> http://www.w3.org/2001/sw/wiki/SKOS/Datasets
>>> As it seemed not modern enough, we've then encouraged people to use 
>>> the same DataHub platform as the LOD cloud:
>>> http://datahub.io/dataset?q=format-skos
>>> But both are not very active. And they contain a lot of dead links...
>>> 2. Library-related datasets:
>>> http://datahub.io/dataset?groups=lld
>>> That list, started by the Library Linked Data W3C incubator, went 
>>> alright as long as the group was running. Now I think the rate of 
>>> new datasets is really small, even though I *know* there are many 
>>> new ones.
>>>
>>> Both as SKOS community manager and former LLD co-chair, I've tried 
>>> to actively mail people to create descriptions of their stuff. But 
>>> it requires time. Most often they assume *you* would do it!
>>> And after a while, the supporters of such effort just have other 
>>> things to do and can't afford very high level of commitment.
>>>
>>> What should we do if we want to build on existing lists and not 
>>> re-invent the wheel every six months or so?
>>> Or is it worth sending a regular (monthly?) reminder to lists like 
>>> public-lod, reminding everyone that these lists are available and 
>>> open for contributions?
>>> Create a list of lists, as Wikipedia does?
>>>
>>> Best,
>>>
>>> Antoine
>>
>> Antoine,
>>
>> As you've indicated, there have been many attempts at this over the 
>> years and they never take-off or meet their goals etc.. The problem 
>> is that a different approach is required. Basically, in this scenario 
>> lies a simple Linked Data publication usecase i.e., a problem that 
>> Linked Data addresses.
>>
>> The steps:
>>
>> 1. use a Linked Data document to describe you product, service, 
>> platform, usecase
>> 2. publish the document
>> 3. make people aware of the document.
>>
>> Crawlers will find your document. The content of the document will 
>> show up in search results.
>>
>> The trouble is that confusion around Linked Data makes 1-3 harder 
>> than it needs to be. Then add RDF misconceptions to the mix, and it 
>> gets harder e.g., that you must have generally approved vocabulary 
>> before you get going, when in fact you don't.
>>
>> People need to understand that "scribbling" is a natural Web pattern 
>> i.e., rough cuts are okay since improvements will be continuous.
>>
>
> Kingsley
>
> Two practical objection to this otherwise interesting approach.
>
> 1. For that kind of survey, as for the rest, people want trust. it 
> will have to be curated (I mean, besides people just putting little 
> bits of uncontrolled/outdated data out there), or it will fly only 
> when thee distributed descriptions are harvested and accessible 
> through something like Google/schema.org.
> Btw people also want visibility. You don't say anything about step 3...

You can sign documents. You can even sign claims. Even better, claims 
can be endorsed by others. These a issues naturally handled by Linked Data.

Verifiable Identity and Trust are areas where Linked Data shines.

>
> 2. It needs to be simple, as non-technical as possible. Step 1 is 
> already too much. Consider LD consumers, who don't publish any LD, why 
> would you ask them to publish an LD document?

"simple" is subjective. There are many routes to the same destination 
here. For instance, some will happily craft Turtle by hand, others may 
do so using other concrete syntaxes. Of course, some would prefer an 
HTML5 form based interface too. The key is to be dexterous enough to 
handle profile variety.


> Actually even in organization that publish LD having step 2 and 3 will 
> take some effort. Not much, I agree, but it won't be part of the core 
> business, and it will still need effort.
> Consider the need to have an (i) updated version; an (ii) interoperable.

It can be done, the problem has been that the approaches to date don't 
work and will never work. Thus, we need to try something different, one 
that's also a Linked Data dog-food exercise too.

>
> Taking a concrete example: me (again, sorry!). A while ago I've made a 
> description of data.europeana.eu as a voiD file. Nice, but now I hear 
> that there's DCAT around and I should read the doc and update my file. 
> Oh, and my dataset has been also updated.

There are even notification protocols that mesh nicely with Linked Data. 
Our problem is that there is too much fragmentation. Suggestions to 
tackle these issues via dog-food and "just do it!" patterns ultimately 
get lost is bizarre arguments rife with contradiction. If Linked Data is 
what is claims to be, then we can address these issues (collaboratively) 
via dog-food patterns.

> And I've got no idea who will consume this updated file and whether it 
> will happen one day...

The same thing applies to any content you put on the Web, you ultimately 
need an incentive to keep it up to date. The same thing applies to 
consumers too, they need an incentive to want to track etc..

> And I've got a hell of other more urgent things to do. So anything 
> that won't be populated by a trivial adaptation of the blog post, 
> which I've already written, will have to wait for a while.

Tweets and posts to other social media are effective mechanisms for 
discussion about data that aid discovery and curation. They can also be 
powerful incentive vectors.

Links:

1. http://slidesha.re/Ys79Jn -- ontology life cycle presentation I gave 
to some ontologies earlier on this year (note: the presentation includes 
live links too).


Kingsley
>
> Best,
>
> Antoine
>
>
>
>
>
>
>
>


-- 

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

Received on Monday, 24 June 2013 14:23:43 UTC