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

sanity checking the LOD Cloud statistics

From: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Date: Wed, 1 Apr 2009 02:06:03 -0400
Message-Id: <18B10242-6C2D-4095-9270-46026B773F62@openlinksw.com>
To: public-lod@w3.org
Hello, all --

I've had a few minutes to start working to update my version [1] of the
LOD Cloud diagram [2], which means I got to start looking at the Data
Set Statistics [3] and Link Statistics [4] pages.

I have found a number of apparent discrepancies.  I'm not sure where  
came from, but I think they need attention and correction.

[3] gave some round, and some exact values.  It's not at all clear  
these values were originally intended to reflect triple-counts in the  
set, URIs minted there (i.e., Entities named there), or something else
entirely.  I think the page holds a mix of these, which makes them  
troublesome as a source of comparison between data sets.

[4] had few exact values, which appear to have been incorrectly added  
and apparently means to use only 3 "counts" for the inter-set linkages  
"> 100", "> 1000" "> 100.000".  Clearly, the last means more-than-one-
hundred-thousand -- because the first clearly means more-than-one- 
hundred --
but this was not obvious at first glance, given my US-training that the
period is used for the decimal, not for the thousands delimiter.

First thing, therefor, I suggest that all period-delimiters on [4]  
to comma-delimiters, to match the first page.  (I've actually made this
change, but incorrect values may well remain -- please read on.)

I think it also makes sense to add "> 10,000", and "> 1,000,000" to the
values here.  Just looking at the DBpedia "actual counts" which were on
the page, it's clear that a log-scale comparing the interlinkage levels
presents a better picture than the three arbitrarily chosen levels.
(Again, I've started using these as relevant.)

Now to the discrepancies.  From [3], I got this line --

    <http://dbtune.org/bbc/playcount/>   BBC Playcount Data      10,000

At first read, I thought that meant 10,000 triples.  But [4] indicated
these external link counts for BBC Playcount Data --

    <http://www.bbc.co.uk/programmes>    BBC Programmes     > 100.000
    <http://dbtune.org/musicbrainz>      Musicbrainz        > 100.000

I don't see a way for 10,000 triples to include 200,000 external links.
That means that the first count must be of Entities.  But going to the
BBC Playcount home page [5], I found --

    Triple count                        1,954,786
    Distinct BBC Programmes resources       6,863
    Distinct Musicbrainz resources          7,055

An obvious missing number here is a count of minted URIs -- that is, of
BBC Playcount resources/entities -- but I also learned that BBC  
URIs are not pointers-to-values, but values-in-themselves.  The count is
*embedded* in the URI (and thus, if a count changes, the URI changes!)  

    A playcount URI in this service looks like:


    Where <id> is the id of the episode or the brand, as in / 
programmes BBC
    catalogue, and <k> is a number between 0 and the number of  
    for the episode or the brand.

If we accept this URI construction as reasonable (which I don't), it  
that <k> must actually be a "natural" or "counting" number (i.e., an  
greater than or equal to 1).  A value of 0 is nonsensical, as it would  
in a Cartesian data set -- where each and every Musicbrainz resource  
a Playcount URI for each and every Programme resource -- and most of  
Playcount URIs would have <k> = 0, for most Musicbrainz resources were  
played in most Programmes.

Even if Zero-Play URIs are created only for those Musicbrainz resources
which were played in *some* Programme, for those Programmes where they
weren't played, far more URIs are created than are needed.

I'm hoping that the folks who built this data set are reading, and will
consider restructuring it.  I'd suggest that the URI structure should be
more like --


-- where <id> reflects *either* Programmes *or* Musicbrainz ID (this may
mean further thinking, as I'm not directly familiar with these IDs, and
Programmes may conflict with Musicbrainz), and the count (the *value*)
is returned when the constructed URI is dereferenced.

More baffling, and more troubling, on [3] I found --

    <http://ieee.rkbexplorer.com/>     IEEE     111

-- which purports to be linked out as follows --

    <http://acm.rkbexplorer.com/>        ACM                    > 1000
    <http://eprints.rkbexplorer.com/>    eprints             > 100.000
    <http://citeseer.rkbexplorer.com/>   CiteSeer            > 100.000
    <http://dblp.rkbexplorer.com/>       DBLP RKB Explorer      > 1000
    <http://laas.rkbexplorer.com/>       LAAS CNRS           > 100.000

Looking to primary sources again --

    Current statistics for this repository (ieee.rkbexplorer.com) 

       Last data assertion  2009-02-06 13:28:04
       Number of triples    111442
       Number of symbols    31552
       Size of RDF dataset  8.2M

    Current statistics for the CRS for this repository  

       Last data assertion   2009-03-25 16:52:19
       Number of URIs        15142
       Number of bundles     25410
       of which active       4874

(Also according to this site, 'A CRS maintaines "bundles" of URIs  
which are
deemed to be equivalent', which I presume means they are tied by  

It seems clear that the initial statistic was reported as thousands, and
should be changed.  However, the out-links still don't add up.  300,000
links (to eprints, CiteSeer, and LAAS CNRS) cannot be made with a third
that many total triples.  A little more digging revealed [6] --

    DBLP RKB Explorer   dblp.rkbexplorer.com       5053 URIs
    ACM                 acm.rkbexplorer.com        2511 URIs
    CiteSeer            citeseer.rkbexplorer.com    888 URIs
    eprints             eprints.rkbexplorer.com     602 URIs
    LAAS CNRS           laas.rkbexplorer.com         93 URIs

-- (sorted by external URI counts, and trimmed to include only those  
sets linked by more than 100 URIs, plus LAAS which apparently was  
included in the existing list).

Clearly, whomever posted these values to the table read "100.000" to  
"one-hundred and zero-thousandths" rather than "one-hundred-thousand".

The correct information for IEEE appears to be --

    <http://ieee.rkbexplorer.com/>     IEEE     111,442

-- which purports to be linked out as follows --

    <http://acm.rkbexplorer.com/>        ACM                 > 1000
    <http://eprints.rkbexplorer.com/>    eprints             >  100
    <http://citeseer.rkbexplorer.com/>   CiteSeer            >  100
    <http://dblp.rkbexplorer.com/>       DBLP RKB Explorer   > 1000

-- (and I've applied these corrections to [3] and [4]).

How many other errors are there in this data?  And how much will those
corrections change the diagrams based upon it?

I'll continue reviewing and correcting things, but thought you should
all be aware that the current table and diagrams may be substantially

Be seeing you,


[1] <http://virtuoso.openlinksw.com/images/dbpedia-lod-cloud.html>
[2] <http://www4.wiwiss.fu-berlin.de/bizer/pub/lod-datasets_2009-03-05.html 
[3] <http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets/Statistics 
[4] <http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets/LinkStatistics 
[5] <http://dbtune.org/bbc/playcount/>
[6] <http://ieee.rkbexplorer.com/crs/foreign.php>

A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Evangelism & Support         //        mailto:tthibodeau@openlinksw.com
OpenLink Software, Inc.      //              http://www.openlinksw.com/
OpenLink Blogs              http://www.openlinksw.com/weblogs/virtuoso/
     Universal Data Access and Virtual Database Technology Providers
Received on Wednesday, 1 April 2009 06:09:53 UTC

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