Separation of schema and instances is a good solution for this symptom. The
root of the problem seems to be that when the amount of data grows, "just
returning everything you know about something" is not going to cut it. A
solution for that seems to be still missing.
Perhaps we need a mechanism of views for linked data -- building upon the
notion of named graphs already implemented by SPARQL endpoints?
So:
http://dbpedia.org/ontology/Person?graph=schema
Would return only T-Box statements.
And:
http://dbpedia.org/ontology/Person?graph=instances
Would return only A-Box statements.
Meanwhile:
http://dbpedia.org/ontology/Person?graph=my-arbitrary-view
Would return only statements that Pablo thinks are important.
That being done, one could say that the default view would be
?graph=schema. This would perhaps address the issue more deeply?
Cheers,
Pablo
PS: Of course, feel free to read http://dbpedia.org/ontology where I said
"schema"; same goes for http://dbpedia/resource where I said "instances".
It's just an identifier.
On Wed, May 30, 2012 at 12:46 PM, Bernard Vatant <[email protected]
> wrote:
> +100!
>
> Separation of T-Box and A-Box descriptions seems quite a reasonable
> requirement, in particular when there are so many instances!
> Or does it mean that the only way to describe the class "Person" is in
> extension : nobody can provide a definition of what a Person is, but
> everybody knows when she meets one :)
>
> Bernard
>
>
> 2012/5/30 Adrian Gschwend <[email protected]>
>
>> Hi group,
>>
>> We work on some software which heavily relies on the ontologies used by
>> the data. This means we dereference the ontologies used on data sets and
>> do some inference to figure out additional stuff about the data. For
>> most ontologies this works pretty well.
>>
>> Last week we were test driving our software against some data at
>> DBPedia, namely the page of Tim Berners-Lee at
>> http://dbpedia.org/resource/Tim_Berners-Lee
>>
>> So far so good, in there we have several rdf:type definitions, including
>> dbpedia-owl:Person, which points to http://dbpedia.org/ontology/Person
>>
>> On that point we noticed that it took way too long to get the page,
>> cache it and do some stuff on it. So we started analyzing it and did it
>> by hand:
>>
>> % curl -I -H "Accept: application/rdf+xml"
>> http://dbpedia.org/ontology/Person
>>
>> HTTP/1.1 303 See Other
>> Date: Mon, 21 May 2012 19:00:08 GMT
>> Content-Type: application/rdf+xml
>> Connection: keep-alive
>> Server: Virtuoso/06.04.3132 (Linux) x86_64-generic-linux-glibc25-64
>> VDB
>> Accept-Ranges: bytes
>> Location: http://dbpedia.org/data3/Person.rdf
>> Content-Length: 0
>>
>> Not a problem, the system can handle redirects. So we get the other file
>> instead. And boy were we confused: It returns an 8MB file for the
>> request (which took quite some time to get btw) After analyzing it in
>> rapper I figured out that we got about 50'000 triples, probably less
>> than 20 are really related to the ontology and the rest is stuff like:
>>
>> <http://dbpedia.org/resource/Zygmunt_Balicki>
>> a <http://dbpedia.org/ontology/Person> .
>>
>> While I do see that this "reverse property" or however it is called
>> might be interesting when I browse the data set in my web browser it is
>> in my opinion plain wrong to return it on the URI which dereferences the
>> ontology.
>>
>> Our software is also targeted at smart phones, you can imagine that it
>> is not really fun to get 50'000 triples back on a crappy 3G link with
>> volume limits and then parse and cache them on a device which is running
>> on battery power. If I do that on several dbpedia data sets I'm probably
>> out of power very soon and didn't even get half of the ontologies used
>> in the data.
>>
>> What is your opinion on that? Is there a good reason for this or did you
>> just think it might be useful? As you can see this pretty much kills the
>> way we use ontologies and I think the "classical" way to dereference
>> ontologies makes way more sense, so I would vote to change this behavior
>> on dbpedia and return uniquely the definition itself.
>>
>>
>> thanks
>>
>> cu
>>
>> Adrian
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Dbpedia-discussion mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>
>
>
>
> --
> *Bernard Vatant
> *
> Vocabularies & Data Engineering
> Tel : + 33 (0)9 71 48 84 59
> Skype : bernard.vatant
> Linked Open Vocabularies <http://labs.mondeca.com/dataset/lov>
>
> --------------------------------------------------------
> *Mondeca** ** *
> 3 cité Nollez 75018 Paris, France
> www.mondeca.com
> Follow us on Twitter : @mondecanews <http://twitter.com/#%21/mondecanews>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Dbpedia-discussion mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dbpedia-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
