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

On 4 Oct 2010, at 09:28, Bob Ferris wrote:

> Am 04.10.2010 09:50, schrieb Dan Brickley:
>> 
>> 
>> 
>> 
>> On 4 Oct 2010, at 09:43, Alexandre Passant<[email protected]>  wrote:
>> 
>>> 
>>> On 3 Oct 2010, at 16:03, Bob Ferris wrote:
>>> 
>>>> 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?
>>> 
>>> It's probably more elegant conceptually, indeed, and I'm not saying that these reification should not exist.
>>> 
>>>> 
>>>> 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?)?
>>> 
>>> Having a direct link, i.e. asking my triple store "where that guy was born" rather than "what is the date of the birth event of that guy"
>> 
> 
> What's the difference here? We try to design here primarily knowledge representation models, which should be understandable by (stupid) machines, which preprocess then that piece of information for human readability, or?
> 
>> Also consider the complexity, readibility and maintainability of RDFa markup.
>> 
> 
> Again, I and more or less every end user don't want to read RDFa markup, or? ;)
> 
>> Try adding semantics in long vs short form to 'Dan Brickley was born in Croydon, UK in 1972.'
>> 
>> (this also suggests birthYear etc might have value)
>> 
>> 
>>>> 
>>>> 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?
>>> 
>>> In that case, you should have only one Birth / Date associated to you.
>>> 
>> 
>> Yup, this makes a nice and easily missed difference
>> 
> 
> Well, but you asked for the date _and_ the place of birthday ;) (and probably you like to add/know at some day more knowledge re. a birthday)
> 
> The thing is really, that your are introducing with "birthday" a new concept, which has a specific meaning in it's own. A meaning, which you probably won't get clear out of the two separate properties.
> That means, for or separate "shortcut relations", birthDate and birthPlace, they should be somehow associable to the concept "birthday", or? So to describe this relationship, we need 4 entities:
> 
> - the subject/person (of the birthday)
> - the predicate/"auxiliary" (date and/or place, ...)
> - the object (of the birhday, data value and/or place value, ...)
> - the association (the concept "birthday")
> 
> Sometimes, introducing a "shortcut relation" for every relationship that seems to be needed in a direct way, is more like hacking for me, rather then an approach for good knowledge representation, or? Although, one should be able to that. However, at any cost?

I've never said that the shortcut was a good KR approach, and my goal here is not to discuss the reification vs shortcut approach (esp. as both are not exclusive and can be combined w/ simple rules).
I just said that I'd find useful to have them.

Alex.

> 
> Cheers,
> 
> Bob
> 
>> Dan
>> 
>>> Alex.
>>> 
>>>> If one use a first class event concept instead, this might then be possible, or?
>>>> 
>>>> Cheers,
>>>> 
>>>> 
>>>> Bob

--
Dr. Alexandre Passant
Digital Enterprise Research Institute
National University of Ireland, Galway
:me owl:sameAs <http://apassant.net/alex> .