RE: [regrep-semantic] [UDEF]

["Jeff Pollock" <jeff.pollock@networkinference.com>]

Actually, the notion that UDEF has an 'enforced' semantic structure is not
true in my humble opinion.  When I first started looking into UDEF back in
2000/2001 the approach was primarily a 'naming convention standard' for
tags.  (that if everyone would just name tags the same way then all of our
interoperability problems would disappear).  Despite some of the recent
changes to adopt GUID-like patterns for atomic concepts, it is still a
convention that is almost wholly in the hands of the modeler and/or tag
namer person.  Any 'semantic pattern' that is based on the notion that
modelers will model things with the same approach (or concepts, for that
matter) is bound to fail.  There is plenty of evidence for this in the ER,
OO and XML worlds.  In short, I don't think that the UDEF 'structure and
meaning' is relevant (or enforced) in a machine-processable way (unlike
other true , but admittedly more complex, knowledge representation formats).

-Jeff-

-----Original Message-----
From: John Gillerman [mailto:john.gillerman@sisconet.com]
Sent: Thursday, February 12, 2004 8:42 AM
To: regrep-semantic@lists.oasis-open.org
Subject: RE: [regrep-semantic] [UDEF]


Yes, I agree that URI's and GUID's don't have a semantic structure, and so
are not strictly equivalent to UDEF ID's.  However, I would suggest that
this is a good thing for our purposes - even if it might not have been what
Joe was asking about.

-----Original Message-----
From: David RR Webber [mailto:david@drrw.info]
Sent: Thursday, February 12, 2004 11:35 AM
To: John Gillerman; regrep-semantic@lists.oasis-open.org
Subject: Re: [regrep-semantic] [UDEF]


John,

Actually not!  GUID and URI have no enforced structure and meaning
in a semantic way.  There's an exact way to construct a UDEF code
based on the domain model - you just cannot pick what you think
might be OK to use for the code.

DW.
----- Original Message -----
From: "John Gillerman" <john.gillerman@sisconet.com>
To: <regrep-semantic@lists.oasis-open.org>
Sent: Thursday, February 12, 2004 10:01 AM
Subject: RE: [regrep-semantic] [UDEF]


> URI's (with namespaces) or GUID's.  Neither tries to enforce a tree.
>
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: Thursday, February 12, 2004 9:33 AM
> To: carlmattocks@checkmi.com
> Cc: John Gillerman; regrep-semantic@lists.oasis-open.org
> Subject: Re: [regrep-semantic] [UDEF]
>
>
> Can anyone please tell me if they are aware of a UDEF "equivalent" (or
> rough equivalent) anywhere? IOW, what would UDEF "compete" with?
>
> Thanks,
> Joe
>
> Carl Mattocks wrote:
> >
> > Given the ebXMLRegistry can store all types of relationships - I think
we
> > should have a more formal discussion on lattice support. Particulary,
> > since the UDEF structure is a 'community-of-interest specific taxonomy'
.
> >
> > Zach:
> > Please create a 'Use Case' for UDEF taxonomy support.
> >
> > <quote who="John Gillerman">
> > > I very much agree with Evan's analysis.  It is very hard to express an
> > > ontology with single tree that let along one that doesn't have typed
> > > relationships.  It becomes even more difficult when one tries to take
> the
> > > tree cross industry and international.
> > >
> > > -----Original Message-----
> > > From: ewallace@cme.nist.gov [mailto:ewallace@cme.nist.gov]
> > > Sent: Friday, February 06, 2004 5:59 PM
> > > To: carlmattocks@checkmi.com
> > > Cc: regrep-semantic@lists.oasis-open.org
> > > Subject: Re: [regrep-semantic] [UDEF]
> > >
> > >
> > >
> > >
> > > "Carl Mattocks" <carlmattocks@checkmi.com> wrote:
> > >
> > >>This is interesting. I want to now more..
> > >>
> > >>Zach:
> > >>
> > >>Please expand on the notion of 'UDEF semantic identifiers'.
> > >>
> > >>Evan:
> > >>
> > >>Please elaborate on 'lattices of these relationships '.
> > >>
> > >
> > > I meant networks rather than strict trees.  A simple example network
> > > is a class with multiple inheritance.
> > >
> > > There are also horizontal relationships like
> > > synonyms and properties.  Think about a design model of a racecar
which
> > > describes different component systems.  All of these components have
> > > a partOf relation to the car.  Something like a transmission often
> > > plays at least two different roles in a hierarchy of component systems
> > > in a racecar.  It is partOf the drivetrain and may be partOf the load
> > > bearing structural system.   Twisting all these properties and
> > > relationships into a strict hierarchy leads to awkward models such as
> > > the UDEF Object tree.
> > >
> > > I didn't mean to imply that supporting lattices was unusual for
modeling
> > > languages.  It isn't.  I was arguing that such expressiveness is
> necessary
> > > for useful semantic models.
> > >
> > >>Everyone :
> > >>
> > >>Please consider if the Semantic Web could leverage "concepts ...
denoted
> > >>by the paths from these nodes to the root rather than the node itself"
> > >
> > > To a certain extent they already do.  I was trying to simplify a finer
> > > distinction.  The path back to the root through subtype relations in
an
> > > RDFS or OWL model of course has implications on a class and instances
> > > (individuals) of that class.  Just the implications you would expect
if
> > > you have programmed in an Object Orient programming language.  If
> > > Racecar is a subtypeOf Car is a subtypeOf Vehicle, then any Racecar
> > > instance is also a Car and a Vehicle instance and inherits the
> > > characteristics of those supertypes.
> > >
> > > By constrast, the relations in the UDEF Object tree do not have any
> > > explicitly defined implications.  It's only when you have followed the
> > > path that you might be able to infer what the relations might have
been
> > > along each connection in the path.  This makes the tree hard to
navigate
> > > when looking for a specific concept.  It also can lead to related or
> > > similar concepts being located quite far apart in the tree.
> > >
> > > -Evan
> > >
> > >
> >
> > --
> > Carl Mattocks
> >
> > co-Chair OASIS ebXMLRegistry Semantic Content SC
> > CEO CHECKMi
> > v/f (usa) 908 322 8715
> > www.CHECKMi.com
> > Semantically Smart Compendiums
> > (AOL) IM CarlCHECKMi
>
>