Re: DBpedia: limit of triples

Hi,

see the "Limitations on browseable data" section on http://www.w3.org/DesignIssues/LinkedData .
That section pretty much covers your 2nd remark, the one afterwards your 1st one.

But yes, i also consider DBpedia buggy in this sense (hence the crossposting):
I guess that many newcomers won't even notice that they might not have gotten any sensible triples at all.
It seems that internally the URI dereferencing results are capped at a 2001 triples max. At the same time the incoming (/ reverse) links are given first, then the outgoing links. For example, if you dereference http://dbpedia.org/resource/United_States you'll get 2001 incoming links (?s ?p dbpedia:United_States), but not even an rdfs:label: http://dbpedia.org/data/United_States.ntriples .

I also guess it would be better to construct the given document first from the outgoing triples, maybe preferring the ontology mapped triples, and then incoming links up to a 2000 triples limit (if necessary to limit bandwidth).
That would fit the description in the above mentioned section way better than the current implementation.

Best regards,
Jörn


On 8. Aug. 2011, at 17:15, Basil Ell wrote:

> Hi,
> 
> I wonder about the limit of triples when accessing DBpedia URIs:
> 
>  $ rapper -c "http://dbpedia.org/resource/Netherlands"
>  rapper: Parsing URI http://dbpedia.org/resource/Netherlands with parser rdfxml
>  rapper: Parsing returned 2001 triples
> 
> When I access that URI by browser I receive the complete data, this means that machines are underprivileged
> whereas they are the ones that are capable of processing the amount of data instead of human users.
> 
> Wouldn't it be nice to:
> 1) whenever such a limit is applied to return a triple that states that a limit has been applied,
>     then the machine knows that it does not know everything there is to know and
> 2) to include triples based on their expected relevance? For example the rdfs:label is generally of interest.
> 
> Best regards,
> Basil Ell

Received on Tuesday, 9 August 2011 10:27:40 UTC