Hi Shivani,
We agree on the aesthetic improvement but we should not put any effort in
>> the graphics design. This will come with the other improvements we/you
>> suggest.
>>
>> Please elaborate on the kind of other improvements you would suggest as a
> part of the project.
>
The idea is to make the display page better for the end user. We already
provide links in the idea description to other linked data representations
as examples to what could be the end result.
A key point is to localize it and make it work for all language editions of
DBpedia. An interesting addition here would be to fetch data on-the-fly
from other linked sources and enrich the display.
This data may come from other DBpedia language editions and/or completetly
other sources (sameAs links).
So the 'better' we have as title is not related to colours and graphics but
to usability.
>
>
>
>> Identifying some major classes (e.g. person, concept, ...) and providing
>> a different layout for these is also a good choice
>> We could also provide different layouts for different properties (e.g.
>> dcterms:subject <http://purl.org/dc/terms/subject>,
>> rdf:type<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
>> )
>>
>>
> Yes, referring to the hyper-linked pages you gave for
> dcterms:subject<http://purl.org/dc/terms/subject>and
> rdf:type <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> it seems like
> a viable thing to undertake.
>
> Note that in DBpedia you cannot edit data like Freebase, our source is
>> Wikipedia so this is where the user should be redirected for editing.
>>
>> Regarding the parsing and the tags, I am not sure I can follow you.
>>
>>
> I am not entirely sure if I am right. But what I meant was directing users
> entering in the wiki to assign tags while writing data.
> For instance if I am a user indicating some reference articles for topic
> "foo", I would be expected to do that within the tags <lit> (for
> literature) and closing tag </lit>. So that when the scripts parse data
> from wiki, demarcating the respective types associated with the data
> becomes easy. Please do comment on the feasibility of this approach, since
> it is an off the head idea which I think should work at handling the random
> abstract data we have for each page.
>
This is about the extraction part of Wikipedia (extraction framework) and
*should not be* related to this idea. This idea is only about the display
of the extraction results.
BTW, the Wikipedia editors is a completely autonomous community and will
not make any such conventions for DBpedia.
If you want to get a better overview on the extraction process and the
internationalization you should read the following papers
1) Christian Bizer, Jens Lehmann, Georgi Kobilarov, Sören Auer, Christian
Becker, Richard Cyganiak, Sebastian Hellmann: DBpedia – A Crystallization
Point for the Web of Data<http://jens-lehmann.org/files/2009/dbpedia_jws.pdf>.
Journal of Web Semantics: Science, Services and Agents on the World Wide
Web, Issue 7, Pages 154–165, 2009.
2) Dimitris Kontokostas, Charalampos Bratsas, Sören Auer, Sebastian
Hellmann, Ioannis Antoniou, George Metakides, Internationalization
of Linked Data: The case of the Greek DBpedia
edition<http://www.websemanticsjournal.org/index.php/ps/article/view/319>,
Web Semantics: Science, Services and Agents on the World Wide Web, Volume
15, September 2012, Pages 51–61, ISSN 1570–8268,
10.1016/j.websem.2012.01.001.
>
>
>
>> The code we currently use for our display page is here :
>> https://github.com/dbpedia/dbpedia-vad-i18n
>> It is a simple server-client application, similar to php-mysql but in
>> this case we have VSP-Virtuoso triples store
>> this is the actual script that renders the final page:
>> https://github.com/dbpedia/dbpedia-vad-i18n/blob/master/dbpedia/vsp/description.vsp#L272
>> We don't have to use the same codebase but you can get an idea.
>>
>>
> File extension VSP is mainly used to organize and store digital images. I
> am not entirely sure why we are using that here.
> (Maybe I need to refer back to some more theory.)
>
There is an overlap here but I was referring to to the Virtuoso Server
Pages (VSP) :http://docs.openlinksw.com/virtuoso/vsp1.html
Cheers,
Dimitris
>
>
> Regards,
> Shivani
>
>
>
>> On Fri, Apr 12, 2013 at 2:15 AM, Shivani Poddar <
>> [email protected]> wrote:
>>
>>> Hi,
>>> I am an aspirant for the Google Summer of Code 2013 and would like to
>>> explore the synergy of my thoughts with the correct implementations of the
>>> idea "Design a better / Interactive display page"
>>> It would be great if I could be given a direction for the same.
>>>
>>> *2.6 Design a better / interactive display page.*
>>>
>>>
>>>> (A very naive approach as to how I think this can be tackled)
>>>> An immediate aesthetic improvement in the UI is needed.
>>>> Also some hierarchy is needed to recognize the major topics to the sub
>>>> topics .
>>>> Eg: The Freebase page recognizes the topic Literature to be the parent
>>>> of the articles cited in the host wiki page from which the information has
>>>> been extracted.
>>>> On the contrary a very homogeneous classification of topics (i.e.
>>>> without much demarcated hierarchy) is followed for DBPedia.
>>>>
>>>> Thus, more tags need to be added.
>>>> The UI wherein User enters data needs to be edited to support such
>>>> labels wherein the user is directed to indicate the parent classes the data
>>>> would tend to be covered in.
>>>> Say for instance if I want to write the articles which describe about
>>>> Barak Obama, I would first open with the tag <lit> article_foo </lit> ,
>>>> similar approach can be followed for books etc too.
>>>> The parser would finally just need to look for the main tags and thus
>>>> render a much better UI than we have now.
>>>>
>>>>
>>> Thank You,
>>> Shivani Poddar
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Precog is a next-generation analytics platform capable of advanced
>>> analytics on semi-structured data. The platform includes APIs for
>>> building
>>> apps and a phenomenal toolset for data science. Developers can use
>>> our toolset for easy data analysis & visualization. Get a free account!
>>> http://www2.precog.com/precogplatform/slashdotnewsletter
>>> _______________________________________________
>>> Dbpedia-gsoc mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/dbpedia-gsoc
>>>
>>>
>>
>>
>> --
>> Dimitris Kontokostas
>> Department of Computer Science, University of Leipzig
>> Research Group: http://aksw.org
>> Homepage:http://aksw.org/DimitrisKontokostas
>>
>
>
>
> --
> Shivani Poddar,
> Bachelors in Computer Sciences and MS in Exact Humanities, Sophomore
> International Institute of Information Technology, Hyderabad
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> Dbpedia-gsoc mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dbpedia-gsoc
>
>
--
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
Dbpedia-gsoc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dbpedia-gsoc
