[foaf-dev] Birth/death dates and places in the Bio vocab

Bob Ferris zazi at elbklang.net
Sun Oct 3 17:03:05 CEST 2010

Am 03.10.2010 15:46, schrieb Alexandre Passant:
> On 3 Oct 2010, at 14:44, Bob Ferris wrote:
>> Am 01.10.2010 15:23, schrieb Alexandre Passant:
>>> Hi Ian, all
>>> While the Bio vocabulary [1] provides classes for main life events, from where we can use dc:created / geonames:locatedIn to model dates and places it happened, I'd find useful to get simple properties for:
>>> - birthDate
>>> - deathDate
>>> - birthPlace
>>> - deathPlace
>>> 2 first ones would be datatype properties, last one object property.
>>> There are similar ones in DBpedia exports of persons, but I'd rather having them in this bio-related vocab.
>>> Any opinion on this ?
>> What's the problem with bio:Birth[1], e.g.
>> _:e a bio:Birth
>>      ; dc:date "1879-03-14"
>>      ; bio:place<http://dbpedia.org/resource/Ulm>  # or event:place
>>      .
>> and bio:Death[2], e.g.
>> _:e a bio:Death
>>      ; dc:date "1955-04-18"
>>      ; bio:place<http://dbpedia.org/resource/Princeton,_New_Jersey>  #
>> or event:place
>>      .
> There is no problem per se, I'm just looking for a way to model that without reification.

Well, it's sometimes useful to have for every relationship a "shortcut 
relation" available. However, I think, when two or more properties are 
related to one event (which is the case here), then it might be good to 
use a first class event concept to model it a bit more elegant, or?

What are the real benefits of using the proposed "shortcut relations" 
instead of a better extendable event concept (okay, everything can 
always be optional, but that shouldn't really matter here, or?)?

The disadvantage of using two or more properties that should associate 
to one event is, that you do not really associate the properties 
explicitly to each other? How should a machine know that birthDate and 
birthPlace belong together to the event birth?
If one use a first class event concept instead, this might then be 
possible, or?



More information about the foaf-dev mailing list