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