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/ .
-Yaron
On Wed, Mar 19, 2008 at 9:57 AM, Markus Krötzsch <[EMAIL PROTECTED]>
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).
>
> Regards,
>
> Markus
>
>
> >
> > 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
> [EMAIL PROTECTED] www http://korrekt.org
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Semediawiki-devel mailing list
> Semediawiki-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
