[Developers] Question about the backend software and data
Shawn Simister
narphorium at gmail.com
Fri Oct 5 15:59:10 UTC 2007
So just to clarify what you are suggesting. Does this refactored person
ontology illustrate the changes that you have described below?
Kavitha Srinivas wrote:
> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: people.owl
Type: text/xml
Size: 7388 bytes
Desc: not available
Url : http://lists.freebase.com/pipermail/developers/attachments/20071005/c2dad6af/attachment-0001.bin
More information about the Developers
mailing list