Re: [foaf-dev] Birth/death dates and places in the Bio vocab
Bob Ferris <zazi-o0kiOr3Ba/[email protected]>
| Newsgroups | gmane.comp.web.rdfweb |
|---|---|
| Message-ID | <[email protected]> |
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? Cheers, Bob