On Fri, October 12, 2012 07:04, Michael Brunnbauer wrote: (01)
> BTW: There is a performance/design tradeoff with n-tuples. Look at your
> example: (02)
> {{#set_internal:Is president of|Has name=James Madison
> |Has start year=1801|Has end year=1809|Has vice
> president#list=George Clinton, Elbridge Gerry}} (03)
> The binary has_name property stands on its own and should clearly not be
> part of another relation with higher arity but doing it so makes things
> faster.
> (04)
In what way does the has_name property stand on its own more
than any of the other properties? This N-tuple does not describe a person.
It describes a Presidency. If anything, the is_president_of, has_start_year,
and has_end_year stand on their own describing properties of the
presidency, while the properties has_name and has_vice_president
describe the names of other entities that bear a relation to the presidency. (05)
Some of the names of the properties suggest that they are properties of
a person, not a presidency, but the date properties obviously do not. (06)
This set appears to be a set of triples. If we reify this as USPresidency4,
then the triples are: (07)
<USPresidency4 is_president_of UnitedStates>
<USPresidency4 has_name "James Madison">
<USPresidency4 has_start_year 1801>
<USPresidency4 has_end_year 1809>
<USPresidency4 has_vice_president
<theList "George Clinton" "Elbridge Gerry">> (08)
Since "James Madison" is referred to as a name, i'm guessing that
"George Clinton" and "Elbridge Gerry" also are names, not reified
instances of HumanBeing. (09)
-- doug foxvog (010)
> Regards,
>
> Michael Brunnbauer
>
> On Fri, Oct 12, 2012 at 12:25:28PM +0200, Michael Brunnbauer wrote:
>>
>> Hello John,
>>
>> I have thought some more about this. I think every n-tuple alternative
>> to RDF
>> that is not exactly like a RDB system:
>>
>> -will be computationally more efficient than triples because tuple
>> elements
>> can be stored together
>>
>> -cannot be as computationally efficient as a RDB as long as you have
>> indices
>> with mixed datatypes
>>
>> -may not have a query language as simple as SQL as long as the tuple
>> elements
>> do not have fixed names.
>>
>> You want n-tuples with a distinguished predicate position, perhaps also
>> with
>> a distinguished subject position ?
>>
>> Should the tuple elements have names or are they referenced by a
>> position
>> number ? Should the tuple elements have fixed datatypes so that a tuple
>> with
>> an element of wrong datatype is rejected ?
>>
>> Both of these restrictions require a fixed schema that is known in
>> advance or
>> looked up from the predicate URI. I don't know if that would be a good
>> idea.
>>
>> Regards,
>>
>> Michael Brunnbauer
>>
>> --
>> ++ Michael Brunnbauer
>> ++ netEstate GmbH
>> ++ Geisenhausener Straße 11a
>> ++ 81379 München
>> ++ Tel +49 89 32 19 77 80
>> ++ Fax +49 89 32 19 77 89
>> ++ E-Mail brunni@xxxxxxxxxxxx
>> ++ http://www.netestate.de/
>> ++
>> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
>> ++ USt-IdNr. DE221033342
>> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
>> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>>
>> _________________________________________________________________
>> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>> Shared Files: http://ontolog.cim3.net/file/
>> Community Wiki: http://ontolog.cim3.net/wiki/
>> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>>
>
> --
> ++ Michael Brunnbauer
> ++ netEstate GmbH
> ++ Geisenhausener Straße 11a
> ++ 81379 München
> ++ Tel +49 89 32 19 77 80
> ++ Fax +49 89 32 19 77 89
> ++ E-Mail brunni@xxxxxxxxxxxx
> ++ http://www.netestate.de/
> ++
> ++ Sitz: München, HRB Nr.142452 (Handelsregister B München)
> ++ USt-IdNr. DE221033342
> ++ Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
> ++ Prokurist: Dipl. Kfm. (Univ.) Markus Hendel
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>
> (011)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (012)
|