Linking of data can be very successful, if it is not restricted to RDF 
enthusiasts. In this case the
vocabulary can grow extremely. Consider e.g. integration of healthcare data. 
Existing vocabularies like SNOMED
CT
http://www.ihtsdo.org/news/article/view/snomed-ct-and-interoperable-healthcare-conference-tutorials-tuesday-1st-july-2008/
contain about 400000 concepts with increasing tendency.

So if the vocabulary is huge, it is not adequate, that the browser software 
knows about the information for
human readable representation, but it could know how to download this 
information from the web using the
linked data concept.

If http URIs are used as identifier, it is possible to store the information 
for human readable representation
at the location where the http URI points to.

Are there up to now rules for this?

Best

Wolfgang

----- Original Message ----- From: "Richard Cyganiak" <rich...@cyganiak.de>
To: "Matthias Samwald" <samw...@gmx.at>
Cc: <public-lod@w3.org>
Sent: Tuesday, September 15, 2009 12:46 PM
Subject: Re: Making human-friendly linked data pages more human-friendly (was: 
dbpedia not very visible, nor
fun)


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-1d7968476cae.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.ay...@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







Reply via email to