Doug,
Thanks for your comments. I concur with most of it, although binary
relations do not imply triples, whereas I see big advantages of expressing
facts as collections of binary relations. (01)
The expression of higher order relations as collections of binary relations,
does not imply that those binary relations have to be expressed as triples
(such as in RDF). Each binary relation requires a number of 'auxiliary
facts', such as the classification of the relation (the reification), but
also the intention, validity context, its language, terms, dates, time,
author, etc. In my opinion it is inefficient to express that all as
different triples.
Therefore a Gellish Data Table defines a standard n-tuple that enables to
specify a large number of such 'auxiliary facts' in a single tuple in
addition to the main binary fact. (although there are people who implemented
Gellish in a triple store)
A big advantage of this standard n-tuple is that all Gellish databases can
have basically a uniform data structure, so that any Gellish enabled
application can read (and interpret) any Gellish compliant data store!
Furthermore, various data stores can be merged or combined without the need
to restructure the data because of the various N-tuples with different
argument definitions. (02)
Indeed, if we have two expressions of which one is the inverse of another,
then one of them might be redundant, although one may be a statement of one
person and the other a confirmation by another person. It is an advantage
when a formal language allows both and leaves the choice to its users. (03)
On completeness of an expression
The definition of the kinds of relations determine which roles are required
and which ones are optional, including cardinality constraints. With binary
relations it is even easier to specify those constraints and flexibilities
for each binary relation.
Thus a completeness verification is possible anyway. We don't need the
higher arity expression for that. (Note that the higher arity relation
itself is also explicitly present as one of the related things in a binary
representation) (04)
On reification
In both ways of expression of higher order relations there is (indeed) an
implicit or explicit individual relation that is classified by a kind of
relation (reified relation).
In Gellish each fact (the topic) is explicitly represented by a UID. An
expression of a fact (or topic) plus an intention (or illocutionary force)
makes it an expression of a statement, or a question, or a denial, or a
confirmation, etc. (05)
Binary representation enables that these auxiliary facts can be expressed on
a binary level, for each involvement relation. That would not be possible
when the fact is expressed by one higher order relation.
Furthermore, binary involvement relations may be added to (or terminated
from) the collection in the course of time, without the need to redundantly
respecify the other involved things. (06)
Below I inserted some additional comments between the lines. (07)
> -----Oorspronkelijk bericht-----
> Van: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] Namens doug foxvog
> Verzonden: woensdag 5 september 2012 23:01
> Aan: '[ontolog-forum] '
> Onderwerp: Re: [ontolog-forum] Accommodating legacy software
>
> On Wed, September 5, 2012 08:47, Andries van Renssen wrote:
>
> > In any relation (of any arity) the related things play roles of
different
> > kinds that are specific for the kind of relation.
> > The semantics of the kind of relation depends on the roles that the
> > related things play in the relation.
> > An explicit specification of roles is required to define the semantics.
> > This is independent of the sequence of arguments in an expression.
> > If you don't make those roles explicit, then you have find an
alternative,
> > such as the sequence of the arguments (as in <is between on path>).
> > Their sequence becomes a pseudo specification of the kinds of roles in
the
> > definition of the meaning of the relation.
>
> Well said. However, note that in a relation such as isBetweenOnPath,
> that multiple arguments are equivalent for a bidirectional path.
>
> > Furthermore, the inverse expression has a different sequence of
arguments,
> > and is also a valid expression of the same fact.
>
> Inverse relations are redundant information. Some languages like them
> because using them makes things easier for their reasoners. Other
> languages, e.g. Cyc, discourage them as being redundant. If inverse
> relations are defined in Cyc, Cyc makes one relation primary and converts
> all statements using one into statements using the other. Queries using
> the non-canonical form are converted to the canonical form, answers are
> computed, and converted back to the form of the query.
>
> > Therefore, semantically it is purer to explicitly specify the kinds of
> > roles.
>
> This requires reifying the statement of relation and ensuring that all
> necessary statements for encoding the relation are asserted. Using a
> higher-arity relation obviates the necessity for reification and
> guarantees that none of the roles are accidentally omitted. (08)
[AvR] A higher arity expression implies also a reification. The verification
of completeness should be a standard procedure in the semantic verification
of the expressions when they are created. (09)
>
> > Therefore, a basic semantic structure for the expressions of facts could
> > be:
> > * kind of relation - kind of role - related thing
>
> Actually, you need
> * reified relation - kind of role - related thing
[AvR] Indeed, the expression requires an explicit classification of the
relation.
>
> Without the reification you can not determine that the individual
> arguments have anything to do with each other.
[AvR] Agreed.
>
> > For an n-ary relation you need n such expressions.
>
> and an n+1st expression that the reified relation is an instance of
> kind of relation.
>
> Reification allows one to make additional statements, such the time
> period for which the statement is valid.
[AvR] Exactly, that is why it is valuable to be able to do so for every
binary component.
>
> > The form
> > * related thing - kind of relation - related thing
> > is just a short cut for a pair of such expressions,
>
> Actually, three. One has to identify the reified relation as being
> an instance of kind of relation.
[AvR] If we are precise there are also the classifications of the roles.
>
> > in which the kinds of
> > roles are assumed to be known from the definition of the kinds of
> > relation.
> > This short cut is only suitable for binary relations and needs a
> mechanism
> > to determine which role is played by the left hand thing and right hand
thing respectively.
>
> Agreed, provided that reification is included.
>
> > A semantic model of the definition of a kind of relation requires even
> > more detailed relations.
>
> More relations that are detailed; yes. Ones that are "more detailed";
> i don't see that.
[AvR] O.K.
>
> > Such a model requires the specification of which kinds of roles are
> > required by which kind of relation and
> > which kinds of things may play such a role.
> > This implies expressions such as:
> > * kind of relation - required played - kind of role
> > * kind of role - required player - kind of thing
>
> Of course, this can be done with n-ary relations, as Cyc has done for
> over 15 years.
>
> > Note that the individual relations and roles are not yet explicit in
these
> > expressions. The basic semantic structures that I developed includes
also
> > the individual roles and relations and allows for the short cut
> > expressions
> > (see http://www.gellish.net/topics/semantic-modelling.html).
>
> > Each of these triples requires the expression of auxiliary facts, such
as
> > their intention (illocutionary force), author, dates, context, etc.
> > In my view it is therefore not a question whether facts can be expressed
> > in triples, but whether triples are a suitable structure
> > when we in practice always model in collections of triples.
>
> Another question is whether triples are an efficient structure.
>
> > The Gellish Data Table is a universal structure for all these kinds of
> > expressions, including the expression of auxiliary facts. That table
> is an
> > alternative to RDF (with some creativity it can be converted into
> > collections of triples if you like). It is described in the document
> > "Definition of Universal Semantic Databases and Data Exchange
> Messages"
> > on http://www.gellish.net/downloads/category/2-english.html.
>
> > Andries
> >
> >
> > -----Oorspronkelijk bericht-----
> > Van: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
> > [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] Namens doug foxvog
> > Verzonden: woensdag 5 september 2012 6:02
> > Aan: [ontolog-forum]
> > Onderwerp: Re: [ontolog-forum] Accommodating legacy software
> >
> > On Tue, September 4, 2012 17:02, Kingsley Idehen wrote:
> >> On 9/4/12 3:41 PM, doug foxvog wrote:
> >>> On Tue, September 4, 2012 12:34, Kingsley Idehen wrote:
> > ...
> >
> >>>> I believe Data denotes Subject Observation.
> >>>> I believe all observations are comprised of:
> >>>> 1. a subject
> >>>> 2. subject attributes
> >>>> 3. subject attribute values.
> >
> > ...
> >>> One common type of observation is that A is between B and C.
> >>> How would you express this with a single triple? 8)#
> >
> >> I would state that A is between B. A is Between C. Then I would
> define
> >> the semantics of the 'Between' predicate .
> >
> > !??
> > Let's explore this:
> > (and
> > (between 10 5 11)
> > (between 10 4 11)
> > (between 10 6 11)
> > (between 10 7 11))
> > Using the KI translator this becomes:
> > AND
> > 10 is between 5
> > 10 is between 11
> > 10 is between 4
> > 10 is between 11
> > 10 is between 6
> > 10 is between 11
> > 10 is between 7
> > 10 is between 11.
> >
> > What semantics does the between predicate have?
> >
> > How about the quaternary predicate, isBetweenOnPath?
> > Can you express the following with triples:
> >
> > (and
> > (isBetweenOnPath WashingtonDC Maryland Virginia I95)
> > (not (isBetweenOnPath WashingtonDC Maryland Virginia I495)))
> >
> >
> > -- doug foxvog
> > ...
> >>
> >> Kingsley
> >>>
> >>> -- doug foxvog
> >
> >
> >
> > _________________________________________________________________
> > 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
> >
> >
> >
>
>
>
> _________________________________________________________________
> 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
> (010)
_________________________________________________________________
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)
|