Semantic MediaWiki

On Tue, Mar 18, 2008 at 7:04 PM, Mov GP 0 <movgp0@...> wrote:
> Hallo,
>  because the "n-ary relations" as described in
>    http://semantic-mediawiki.org/wiki/N-ary_relations
>  are not n-ary relations at all, I request to rename them.
>
>  Better names include "complex type", "compound type", or "structure"
>  ("struct").

Whether or not they're N-ary relations, the name is overly technical,
and needlessly offputting.  Let me second Mov GP 0's request, and
propose the term "structured property" as an alternative.  In
addition, I suggest using the term "fields" for the properties
contained within a structured property.

Other questions that ought to be answered: should structured
properties be allowed to be nested?  How do you search for fields?
What URI does a query return when it finds one?

-- 
Jonathan "Dataweaver" Lang

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. 
However, I just want to express my graditute 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.

Gu

Quoting Jon Lang <dataweaver@...>:

> On Tue, Mar 18, 2008 at 7:04 PM, Mov GP 0 <movgp0@...> wrote:
> > Hallo,
> >  because the "n-ary relations" as described in
> >    http://semantic-mediawiki.org/wiki/N-ary_relations
> >  are not n-ary relations at all, I request to rename them.
> >
> >  Better names include "complex type", "compound type", or "structure"
> >  ("struct").
> 
> Whether or not they're N-ary relations, the name is overly technical,
> and needlessly offputting.  Let me second Mov GP 0's request, and
> propose the term "structured property" as an alternative.  In
> addition, I suggest using the term "fields" for the properties
> contained within a structured property.
> 
> Other questions that ought to be answered: should structured
> properties be allowed to be nested?  How do you search for fields?
> What URI does a query return when it finds one?
> 
> -- 
> Jonathan "Dataweaver" Lang
> 
> -------------------------------------------------------------------------
> 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@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>

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".

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.

-- 
Jonathan "Dataweaver" Lang

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
mak@...          www  http://korrekt.org

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 <mak@...>
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
> mak@...          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@...
> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
>
>

On Mittwoch, 19. März 2008, Jeff Thompson wrote:
> What are the plans for exporting compound value types to RDF?
> You may be getting into "blank nodes".

We currently export them with an auxilliary node that is indeed blank. We 
could, however, also give it some arbitrary name without loosing the intended 
semantics (in fact, that is what many OWL DL tools will silently do to treat 
the blank node, it is called "skolemisation").

-- Markus

>
> Markus Krötzsch wrote:
>  > 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 ;-)



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

Markus Krötzsch wrote:
> Re naming: we really used the term only as a technical reference during 
> development (at a time when SMW still had "relations").  ...
> One could also call them "many-valued properties".

Done. 
<http://semantic-mediawiki.org/wiki/Help:Properties_and_types#Properties_with_multiple_types> 
, http://semantic-mediawiki.org/wiki/Help:Many-valued_properties

By the way, http://ontoworld.org/wiki/N-ary_relations and its talk page 
have much discussion of fancier named sub-properties and nested 
annotation that people have suggested or requested in recent threads.

--
=S