I too support the renaming to something like "compound type" in the documentation, if nothing else so that there'll be a place to describe true n-ary relations when they're implemented one day (fingers crossed). :)

By the way, "n-ary relation" is an established mathematical term; see, for example, http://www.w3.org/TR/swbp-n-aryRelations/ .


On Wed, Mar 19, 2008 at 9:57 AM, Markus Krötzsch <mak@aifb.uni-karlsruhe.de> wrote:
On Mittwoch, 19. März 2008, Jon Lang wrote:
> Gu wrote:
> > I'm sure the present implementation of the "n-ary" property is only an
> > early stage of this vital feature but I agree that the present state
> > could be described more precisely by a different name.
> It's not a matter of the present state being incomplete.  Even in its
> present, incomplete state, it has gone beyond being called a relation
> since its component values can be properties of any type, not just
> relations.  "N-ary property" is more accurate than "N-ary relation".

Re naming: we really used the term only as a technical reference during
development (at a time when SMW still had "relations"). I am surprised that
it gained so much popularity already ;-) At least SMW AFAI recall does not
endorse the term anywhere in its user interfaces.

One could also call them "many-valued properties". "Composite"
and "structured" are also an improvement. "Composite type" or "compound type"
would both be fine. Any such name can of course be misunderstood, but at
least (in contrast to nary) it can be understood at all ;-)

Currently, the internal handling of the naries is of course more complicated
than for other types (essentially all DB operations need one additional
join). It is not planned right now to add support for further substructuring
of porperty values (which would further complicate the handling).



> But my complaint isn't that so much as it is the "N-ary" side, where
> it isn't so much a question of accuracy as it is technicality.
> Indeed, as things stand, "N-ary" is technically more accurate than
> "structured" or "composite", as the latter two carry the implication
> that the component values have their own names, the way that fields in
> a c-style struct do.  Calling it "structured" or "composite" instead
> of "N-ary" actually anticipates future functionality rather than the
> current state of its implementation.
> >  However, I just want to express my gratitute that it exists at all
> > because for my own purpose the whole SMW would be of little use without
> > it. So thanks to the developers.
> Oh, definitely.

Markus Krötzsch
Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362          fax +49 (0)721 608 5998
mak@aifb.uni-karlsruhe.de          www  http://korrekt.org

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Semediawiki-devel mailing list