W3C home > Mailing lists > Public > public-lod@w3.org > September 2009

Re: Making human-friendly linked data pages more human-friendly

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 15 Sep 2009 19:04:03 -0400
Message-ID: <4AB01D63.6010902@openlinksw.com>
To: Hugh Glaser <hg@ecs.soton.ac.uk>
CC: "public-lod@w3.org" <public-lod@w3.org>
Hugh Glaser wrote:
> I agree with Richard and think I also agree with Matthias.
> We do need to have nice publishing of our Linked Data.
> But I really don't see why it should be the publisher of the Linked Data
> that (yet again) bears the brunt of the work.

Linked Data is about separation of:
- identity
- storage
- representation
- access
- presentation

This is the heart of the matter, and the sooner we internalize it the 
sooner we get more done, across the community at large.

> And of course they are likely to do a less than great job, not being UI
> specialists.
Not being specialist, or even when capable, simply not top priority.

> They are better spending their time doing what they are good at - publishing
> LD.

What they are good at, or what works best for their strategic priorities 
etc.. Again we have heterogeneity here also :-)
> I almost use zitgist as the standard html publisher of my LD (and certainly
> link to it), and I am sure that a greater effort to provide top quality
> generic browsers that do the simple things well would obviate the need for
> me to provide anything of my own (other than the metametadata to inform the
> rendering).
> There are related technologies such as fresnel that could inform the process
> (we publish fresnel descriptions for many our Things).
> It's time we had more specialists in LD, eg people who specialise in:
> publishing LD;
> defining ontologies;
> identifying linkage;
> consuming LD.


Heterogeneity of interests, world views, and skill sets,  are data 
access realities that Linked Data brings to the fore :-)

> Best
> Hugh
> On 15/09/2009 12:46, "Richard Cyganiak" <richard@cyganiak.de> wrote:
>> Hi Matthias,
>> Please allow me to present a contrarian argument.
>> First, there are some datasets that combine linked data output with a
>> traditional website, e.g., by embedding some RDFa markup. Of course,
>> in that case, all the rules of good web design and information
>> presentation still apply, and the site has to first and foremost
>> fulfill the visitor's information needs in order to be successful.
>> That's self-evident and not what we are talking about here.
>> Most linked data is different. The main purpose is not to create a web
>> site where visitors go to look up stuff. The main purpose is to
>> publish data in a re-usable way, in order to allow repurposing of the
>> data in new applications.
>> In that case, the "audience" for the human-readable versions of the
>> RDF data is *not* a visitor that came to the site while googling for
>> some bit of information. It's more likely to be a data analyst, mashup
>> developer, or integration engineer. So what I suggest is to think of
>> these pages not as something that end users see, but rather as
>> something akin to Javadoc. Javadoc pages are auto-generated pages that
>> describe a public interface of your system. Linked data pages are the
>> same, but rather than a Java API, they describe your URI space. And
>> unlike Javadoc, they are directly connected to the documented
>> artifacts (URIs).
>> I think that the pages should mostly answer the following questions:
>> What concept is identified? What *exactly* is the URI of this concept
>> (careful with /html or #this at the end)? Who curates this identifier?
>> Can I trust it to be stable? Most linked data pages actually do a
>> fairly decent job at answering these.
>> Every data publisher has limited resources, and spending them on
>> prettifying the HTML views is very low-impact. It's much more
>> important to increase data quality, publish more data,  improve other
>> documentation, and create compelling demos/apps on top of the data.
>> The "namespace documentation" is usually good enough, and the
>> geekiness of the pages actually helps to drive home the point that
>> it's about *re-using this data elsewhere*, rather than looking at the
>> data in the boring old web browser.
>> That being said, of course nicer-looking pages that present
>> information in a more useful way are of course always better, but
>> that's a somewhat secondary problem in the linked data context.
>> Best,
>> Richard
>> On 15 Sep 2009, at 10:08, Matthias Samwald wrote:
>>> A central idea of linked data is, in my understanding, that every
>>> resource has not only a HTTP - resolvable RDF description of itself,
>>> but also a human-friendly rendering that can be viewed in a web
>>> browser. With the increasing popularity of RDFa, the URIs of these
>>> resources are not only hidden away in triplestores, but become
>>> increasingly exposed on web pages. People want to click on them,
>>> and, hopefully, not all of these people come from the core community
>>> of RDF enthusiasts.
>>> This means that the HTML rendering of linked data resources might
>>> need to look a bit sexier than it does today. I dare to say that the
>>> Pubby-esque rendering of DBpedia pages such as
>>> http://dbpedia.org/page/Primary_motor_cortex
>>> is helpful to get a quick overview of the RDF triples about this
>>> resource, but non-RDF-enthusiasts would not find it very inviting.
>>> This could be improved by changes in the layout, and possibly a
>>> manually curated ordering of properties. For example,
>>> http://d.opencalais.com/er/company/ralg-tr1r/f8a13a13-8dbc-3d7e-82b6-1d796847
>>> 6cae.html
>>> definitely looks more inviting than the typical DBpedia page (albeit
>>> still a bit sterile).
>>> In the case of DBpedia, it might be better to expose the excellent
>>> human-readable Wikipedia page for each resource, plus a prominently
>>> positioned 'show raw data' tab at the top. For other linked data
>>> resources that are not derived from existing human-friendly web
>>> pages, a few stylistic changes (ala OpenCalais) already might
>>> improve the situation a lot.
>>> Note that this comment is not intended to be a criticism of DBpedia,
>>> but of all Linked Data resources that expose HTML descriptions of
>>> resources. DBpedia is just the most popular example.
>>> Cheers,
>>> Matthias Samwald
>>> DERI Galway, Ireland
>>> http://deri.ie/
>>> Konrad Lorenz Institute for Evolution & Cognition Research, Austria
>>> http://kli.ac.at/
>>> --------------------------------------------------
>>> From: "Danny Ayers" <danny.ayers@gmail.com>
>>> Sent: Tuesday, September 15, 2009 4:03 AM
>>> To: <public-lod@w3.org>
>>> Subject: dbpedia not very visible, nor fun
>>>> It seems I have a Wikipedia page in my name (ok, I only did fact-
>>>> check
>>>> edits, ok!?). So tonight I went looking for the corresponding
>>>> triples,
>>>> looking for my ultimate URI...
>>>> Google "dbpedia" => front page, with news
>>>> on the list on the left is "Online Access"
>>>> what do you get?
>>>> [[
>>>> The DBpedia data set can be accessed online via a SPARQL query
>>>> endpoint and as Linked Data.
>>>> Contents
>>>> 1. Querying DBpedia
>>>> 1.1. Public SPARQL Endpoint
>>>> 1.2. Public Faceted Web Service Interface
>>>> 1.3. Example queries displayed with the Berlin SNORQL query explorer
>>>> 1.4. Examples rendering DBpedia Data with Google Map
>>>> 1.5. Example displaying DBpedia Data with Exhibit
>>>> 1.6. Example displaying DBpedia Data with gFacet
>>>> 2. Linked Data
>>>> 2.1. Background
>>>> 2.2. The DBpedia Linked Data Interface
>>>> 2.3. Sample Resources
>>>> 2.4. Sample Views of 2 Sample DBpedia Resources
>>>> 3. Semantic Web Crawling Sitemap
>>>> ]]
>>>> Yeah. Unless you're a triplehead none of these will mean a thing.
>>>> Even
>>>> then it's not obvious.
>>>> Could someone please stick something more rewarding near the top! I
>>>> don't know, maybe a Google-esque text entry form field for a regex on
>>>> the SPARQL. Anything but blurb.
>>>> Even being relatively familiar with the tech, I still haven't a clue
>>>> how to take my little query (do I have a URI here?) forward.
>>>> Presentation please.
>>>> Cheers,
>>>> Danny.
>>>> -- 
>>>> http://danny.ayers.name



Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com
Received on Tuesday, 15 September 2009 23:04:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:00 UTC