[Developers] Question about the backend software and data

Kavitha Srinivas ksrinivs at gmail.com
Fri Oct 5 13:19:20 UTC 2007 

Hi Shawn
    I don't think I was clear about what I was proposing in my  
previous message.  Here's what I was saying:

1.  Avoid functional properties and cardinality restrictions  
(cardinality restrictions are a generalized form of functional  
properties), unless you want to be able to make the sorts of  
inferences I described earlier.
2.  I was proposing removing the domain/range restrictions because  
they are global restrictions (precisely for the reasons you describe,  
that is, many types may share the same property, so domain and range  
applied globally is inappropriate).  Instead, I was suggesting  
modeling the same link between properties and types as existential  
restrictions.

Concretely as an example from your people.owl file, we have a type of  
modeling [A]:

    <owl:ObjectProperty rdf:ID="place_of_birth">
       <rdfs:domain rdf:resource="#Person"/>
       <rdfs:range rdf:resource="http://www.freebase.com/owl/ 
location#Location"/>
       <rdf:type rdf:resource="&owl;FunctionalProperty"/>
     </owl:ObjectProperty>
     <owl:ObjectProperty rdf:ID="nationality">
       <rdfs:domain rdf:resource="#Person"/>
       <rdfs:range rdf:resource="http://www.freebase.com/owl/ 
location#Country"/>
     </owl:ObjectProperty>

What I am proposing is an alternative type of modeling [B]:
     Person is a subclass of \exists.place_of_birth{Location} AND  
\exists.nationality{Country}

Logically, [B] is saying that if you are a person, you must have a  
place of birth property that has a type of Location and nationality  
property that has a type of Country (although the specific instance  
may not actually be specified in the data).  Using local constraints  
like those in [B], one can avoid the problem in [A] of specifying the  
constraints globally.  As you noted, [A] poses a problem when several  
types share the same property.  This is why a lot of life sciences  
OWL models choose [B].  Note, that [B] could be automatically  
generated from freebase, just the same way you are generating [A].   
Your point about automatically generating models from Freebase is  
well taken.  I agree with that completely.

Kavitha


On Oct 5, 2007, at 1:36 AM, Shawn Simister wrote:

> Thanks for the feedback. I can see what you mean about the  
> functional properties so I'll switch those over to cardinality  
> restrictions. With respect to placing existential restrictions on  
> certain properties, I don't think that that will be feasible for a  
> couple of reasons.
>
> First of all, I'm not aware of any such restrictions in the  
> Freebase type system (although it might be nice to have them), so  
> if I were to add these sorts of restrictions to ontologies there  
> would be no guarantee that future RDF dumps of the Freebase data  
> would actually conform to those ontologies.
>
> Secondly, due to the fact that there are no explicit existential  
> restrictions on any of the Freebase properties I would have to  
> enter these restrictions by hand which is not easy given the  
> growing number of types within Freebase. Even if someone where to  
> model all these restrictions by hand, maintaining them over time as  
> the types change would be a challenge.
>
> One other issue that I have just noticed is that some domains have  
> multiple types which have properties with the same names. For  
> example, In the /measurement_unit domain, both DatedInteger and  
> CountAsOfDate have a property named number. This causes a naming  
> collision in some of the OWL ontologies. My first instinct was to  
> simply merge the two properties into a single property which shares  
> the domains and ranges of both properties.  The down side to this  
> is that we would be making a naive assumption about the similarity  
> of the properties being merged.
>
> An alternate approach would be to model each Freebase type as a  
> separate OWL file so that each type has a unique URI. I think that  
> this approach is probably safer in the long run but I'd appreciate  
> any input on what people think is a better design.
>
> Shawn
>
> Kavitha Srinivas wrote:
>> Shawn
>>   This is really very good.  I had a couple of suggestions:
>> (a) Avoid usage of functional properties for integrity constraints  
>> and use them instead for when you'd like to discover something.   
>> For instance, let's assume that you marriedTo is a functional  
>> property, so that if the same person A is married to two people B  
>> and C then
>> you want to infer B and C are the same person.
>> (b) Another pattern you've used is to model domain and ranges for  
>> all properties of a Person (e.g., Place of Birth, etc).  This is  
>> fine, but I don't know if you want to capture the fact that any  
>> Person always has a Place of Birth (but we may not necessarily  
>> know what that place might be).  That is, Person can be modeled as  
>> an existential restriction (exists.PlaceOfBirth{Location}).  This  
>> latter form of modeling is a commonly adopted pattern in many  
>> large life sciences ontologies.
>>
>> Kavitha
>>
>> On Oct 3, 2007, at 5:40 AM, Shawn Simister wrote:
>>
>>> I've just put together a first attempt at representing the  
>>> Freebase type system as OWL ontologies. There's still some work  
>>> to be done but I figured I'd give you guys an update and  
>>> hopefully get some feedback on how I'm modeling these domains in  
>>> OWL.
>>>
>>> You can download it at http://www.simister.ca/temp/freebase- 
>>> owl-03-10-07.zip. The way that it's set up right now is one OWL  
>>> ontology per file per Freebase domain. Let me know what you think.
>>>
>>> Shawn
>>>
>>> Kavitha Srinivas wrote:
>>>> Not really, am in interested in modeling issues rather than a  
>>>> specific domain.  Thanks!
>>>> Kavitha
>>>>
>>>> On Sep 30, 2007, at 4:24 PM, Shawn Simister wrote:
>>>>
>>>>> I'm just putting together a new version of the ontology now  
>>>>> which I will make available on my website. Is there a  
>>>>> particular domain that you want to see? Right now I'm just  
>>>>> focusing on the 67 or so main Freebase domains.
>>>>>
>>>>> Shawn
>>>>>
>>>>> Kavitha Srinivas wrote:
>>>>>> Is Shawn's OWL ontology available somewhere?
>>>>>> Kavitha
>>>>>>
>>>>>> On Sep 28, 2007, at 9:52 PM, John Giannandrea wrote:
>>>>>>
>>>>>>
>>>>>>> Kirrily Robert wrote:
>>>>>>>
>>>>>>>> To me, RDF sounds like it meets those criteria.
>>>>>>>>
>>>>>>> I agree that an RDF dump of the data makes sense.
>>>>>>> There are important details though, like how to represent
>>>>>>> the schema.  Shawn Simister previously posted about
>>>>>>> creating an OWL ontology from the freebase types, rather
>>>>>>> than using RDF Schema, which seemed sensible.
>>>>>>>
>>>>>>> The key point was that Shawn was able to extract the data
>>>>>>> and turn it into those formats, using HTTP, MQL and JSON.
>>>>>>>
>>>>>>> -jg
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Developers mailing list
>>>>>>> Developers at freebase.com
>>>>>>> http://lists.freebase.com/mailman/listinfo/developers
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>> Developers at freebase.com
>>>>>> http://lists.freebase.com/mailman/listinfo/developers
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>

More information about the Developers mailing list