[foaf-dev] Birth/death dates and places in the Bio vocab
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  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, e.g.
>> _:e a bio:Birth
>> ; dc:date "1879-03-14"
>> ; bio:place<http://dbpedia.org/resource/Ulm> # or event:place
>> and bio:Death, 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
More information about the foaf-dev