W3C home > Mailing lists > Public > public-lod@w3.org > August 2009

Re: [Dbpedia-discussion] Fwd: Your message to Dbpedia-discussion awaits moderator approval

From: Kavitha Srinivas <ksrinivs@gmail.com>
Date: Mon, 10 Aug 2009 17:05:31 -0400
Message-Id: <E0FA4D5A-6BE6-494A-9AA6-90165B1AFBF2@gmail.com>
Cc: Pat Hayes <phayes@ihmc.us>, Anja Jentzsch <anja@anjeve.de>, public-lod community <public-lod@w3.org>, Tim Finin <finin@cs.umbc.edu>, dbpedia-discussion@lists.sourceforge.net
To: Kingsley Idehen <kidehen@openlinksw.com>
Yes will fix URIs and load to the ftp server.  Sorry about that issue.
Kavitha
On Aug 10, 2009, at 5:00 PM, Kingsley Idehen wrote:

> Pat Hayes wrote:
>> This website should be taken down immediately, before it does  
>> serious harm. It is irresponsible to publish such off-the-wall  
>> equivalentClass assertions. The presence or absence of  
>> hierarchies, or the similarity to tags, are completely irrelevant:  
>> the semantics of owl:equivalentClass are quite unambiguous and are  
>> fixed normatively by the OWL specs, so these assertions have a  
>> definite meaning; and with that meaning they are wildly,  
>> irresponsibly and dangerously false. Tim is treating it lightly,  
>> but this is in fact quite a serious matter. Please DISABLE public  
>> access to this resource until this is fixed.
>>
>> Pat Hayes
> Pat,
>
> Note, I loaded the triples into a separate Named Graph. The data is  
> hosted in the same Virtuoso instance that hosts DBpedia, but not  
> part of the main DBpedia data set. The Linked Data Spaces are  
> partitioned. This goes back to the very point I believe Alan was  
> making re. linksets and core knowledgebase datasets. Stuff can go  
> wrong, and I don't have to make a more problematic DELETE or UPDATE  
> against the entire DBpedia Named Graph in the Quad Store. Thus,  
> lets assume this needs to be scrapped, all I have to do is scrap  
> the Named Graph hosting the broken datasets using SPARUL (Update or  
> Delete).  On the other hand, lets assume I feel this is all fine,  
> but you disagree vehemently, all that happens is that when I SPARQL  
> I have the option to inference (albeit questionably) using these  
> rules, while you don't, since its just my relatively warped "world  
> view" (from say your view point) hosted in my own Linked Data Space  
> that happens to be Web accessible  :-)
>
> Just Another nice dog-fooding example, across many vectors re.  
> Linked Data and the Web.
>
> Kavitha: At the very least you need to fix the Freebase URIs, and  
> then I would also suggest the options Tim Finn offered. Once  
> implemented, I can just reload :-)
>
> Kingsley
>>
>>
>> On Aug 10, 2009, at 3:27 PM, Tim Finin wrote:
>>
>>> Kavitha Srinivas wrote:
>>>> I understand what you are saying -- but some of this reflects  
>>>> the way
>>>> types are associated with freebase instances.  The types are  
>>>> more like
>>>> 'tags' in the sense that there is no hierarchy, but each  
>>>> instance is
>>>> annotated with multiple types.  So an artist would in fact be  
>>>> annotated
>>>> with person reliably (and probably less consistently with
>>>> /music/artist).  Similar issues with Uyhurs, murdered children  
>>>> etc.  The
>>>> issue is differences in modeling granularity as well.  Perhaps a  
>>>> better
>>>> thing to look at are types where the YAGO types map to Wordnet  
>>>> (this is
>>>> usually at a coarser level of granularity).
>>>
>>> I think you need a different property to express the relation  
>>> between the
>>> freebase types and yago classes.  The whole point of grounding  
>>> OWL in logic is
>>> to allow people and computers to draw inferences from the OWL  
>>> statements.  Those
>>> statements in the dump do assert that anything that is in the set  
>>> yago:Uyghurs
>>> is also in the set yago:MurderedChildren and vice versa.
>>>
>>> Why not use rdfs:subClassOf to relate a yago class to a freebase  
>>> type when every
>>> member of the class is tagged with the type but not everything  
>>> tagged with the
>>> type is a member of the class.
>>>
>>> skos:narrower is another option, maybe.
>>>
>>>
>>
>> ------------------------------------------------------------
>> IHMC                                     (850)434 8903 or (650)494  
>> 3973
>> 40 South Alcaniz St.           (850)202 4416   office
>> Pensacola                            (850)202 4440   fax
>> FL 32502                              (850)291 0667   mobile
>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>
>>
>>
>>
>>
>>
>
>
> -- 
>
>
> Regards,
>
> Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
> President & CEO OpenLink Software     Web: http://www.openlinksw.com
>
>
>
>
Received on Monday, 10 August 2009 21:06:15 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:22 UTC