Sebastian Hellmann wrote:
> Rob Lee schrieb:
>
>> Sebastian Hellmann wrote:
>>
>>
>>> Yes,
>>> there are disambiguation pages.
>>> Formerly data looked like this:
>>> :Apple a :FloweringPlant
>>> :Apple :kingdom :Plant
>>> :Apple :disambiguates :Apple_Inc.
>>>
>>>
>>> There were even worse cases.
>>> e.g. Braniff_(Disambiguation) was made to Braniff, which was a redirect
>>> to Braniff_International_Airways
>>>
>>> There is no correct algortihmic approach to solve this matter, so the
>>> reason, why we changed it, is that it reflects the pages on Wikipedia as
>>> they are, without any transformations, that might lead to a strange
>>> representation.
>>>
>>> If Apple is a FloweringPlant, how can it disambiguate Apple Inc.?
>>> The concepts have nothing to with each other, except sharing the String
>>> identifier.
>>>
>>>
>>>
>> I can see the logic and agree with it (I think), but I can't see any
>> evidence of the change in the changelog for 3.4 (have I just missed it
>> ?) It's quite a big change to have made (the disambiguation dataset has
>> nearly doubled in size between 3.3 and 3.4) - was there any discussion
>> on the mailing list as to the best implementation (for example, it might
>> be nice to add a reference to the disambiguation page - 'disambiguated
>> by' or similar) ? Is there any benefit in setting up a
>> dbpedia-developers list, in order to discuss these changes to the core
>> data ?
>>
>>
> The disambiguation issue was considered a bug and therefore just fixed.
> Especially, with the upcoming live extraction, DBpedia clearly needs to
> reflect Wikipedia on a page level.
>
Hmm, I'm not sure I agree on that, I don't think live extraction should
be driving the way data is represented in dbpedia. Live extraction
should be a technological solution to a problem, not impact the data model ?
I'd also question the fact that a 'bug' can just be 'fixed' without any
assessment or notification. When fixing a bug, you typically look at
the impact of the change to fix it, in this case the impact is large as
it drastically changes the model behind how disambiguations work (in
fact I 'd even question classifying it as a bug - there was a clear
design intent behind how it used to work, which someone in the dbpedia
team disagreed with and decided to change, rather than there being an
error in the code/implementation).
I'm guessing the way it used to work was designed/decided as a result of
this feature request/email :
http://sourceforge.net/tracker/index.php?func=detail&aid=1818166&group_id=190976&atid=935523
<http://sourceforge.net/tracker/index.php?func=detail&aid=1818166&group_id=190976&atid=935523>
However, I can't see any evidence of the bug that has been 'fixed' for
the 3.4 release in the bug tracker (I searched for disambiguation). Is
this being used by the current development team, is it worth people
raising bugs there anymore ?
<http://jira.mongodb.org/secure/ReleaseNote.jspa?projectId=10000&styleName=Html&version=10117>
Also, I'm still a little confused by the disambiguation issue, looking at
http://dbpedia.org/page/Visa
It still appears to have' disambiguates' properties ?
> A dbpedia-developers list is something, which is on our todo list, but
> it should not be another mailing list.
> Currently, our developers are busy. One thing is the live extraction,
> the other thing is the complete refactoring of the extraction framework
> in java/scala.
I don't know the reasons behind the rewrite (has there been any
discussion about it or if it's needed ?) but I always refer people to
http://chadfowler.com/2006/12/27/the-big-rewrite when this kind of thing
is touted.
> Code fluctuation is so high, that a developers list would be not effective.
>
I think thats an argument you could level at any open source project at
one time or another but other projects do manage to have them, in fact
when code fluctuation is high, thats a very good time to have one so
that people discuss changes ...
> However, I understand the concern, you have. There should be more public
> influence and we are working on that. Part of it comes bundled with the
> live extraction and also, once we have a steady code base, there should
> be appropriate places to discuss changes and enhancements properly.
> Also the vocabulary used should reflect consensus.
> As a preview, you can have a look here:
> http://meta.wikimedia.org/wiki/DBpedia
>
Thanks, I will have a look. Is it mentioned on the main dbpedia site
anywhere? I don't recall seeing it before.
> Regards,
> Sebastian
>
>
>> Rob
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Dbpedia-discussion mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>>
>>
>>
>
>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Dbpedia-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
