David,
(01)
I think that with this clarification, we are in agreement. That is, I agree
that a point that is defined by a set of property values in a manifold space
that is defined by the corresponding set of property types can be considered a
class of 4D state-things. And conventionally, we use the term 'state' (without
'of') to refer to such a class, i.e., the set of properties (values of specific
property types), without regard to which TemporalParts of WholeLifeIndividuals
(the 4D state-things) possess those properties. So, each
multidimensional_property_space might be considered a class of such 'states',
and the concept multidimensional_property_space itself is then a class of
classes of states. That is your position, as I understand it.
(02)
So, each multidimensional_property_space is a class that has an extension -- a
set of these abstract states. The idea that that set forms a
geometric/topological space, however, imposes a mathematical model on the class
that is a set of purely mathematical relationships among the property values,
independent of the property types. We can certainly talk about the states
being related in this way, but we need to explain how that model relates to the
TemporalParts of WholeLifeIndividuals, which is the purpose of the exercise.
In that space, there is a set of points such that each point is defined by a
set of measurements of a TemporalPart of a WholeLifeIndividual. We then
interpolate in the mathematical space to produce a curve that theoretically
describes the behavior of some (aggregated) TemporalPart of that individual --
a performance curve for the individual, e.g., in operation. The mathematical
curve is still a set of 'states', yes, but we only know that the measured ones
actually have an instance related to that individual.
(03)
Our scientific theory about states of this kind tells us to expect that other
actual states of the individual will be "close" (using some mathematical
measure) to the set of states on the curve. The relationship between the
mathematical model states and the states of the individual is now
"approximately equal". Satisfying one of these mathematical classes is defined
by a range of property values in combination, some 'neighborhood' in the
topological/geometric space. The original states were points in the
mathematical space. These classes are neighborhoods in the mathematical space.
These 'approximate states' are still classes of temporal parts of individuals,
but the property values are nominal and the ranges of values for a given class
are defined by interrelationships among the property types. And when we then
aggregate such measurements over a sample population of individuals to produce
the expected performance curve for a given catalog item, we have a purely
mathematical model. We still have 'states' defined by ranges of properties,
but they are only *related to* observable states of individuals. There is
nothing wrong with generalizing the term 'state' to refer to these classes; it
is what we mean. In science and engineering we do this kind of thing all the
time. These 'states' are still classes of observable states of individuals,
but they are not points in the mathematical space. So, to be a class of these
states, a multidimensional property space must be a set of neighborhoods, not
points.
(04)
Note also that the predicted states are a consequence of scientific and
mathematical reasoning that produced the mathematical predictions. So the 'set
of states' ontology has been explicitly bound to a powerful scientific and
mathematical ontology to produce this model.
(05)
The question is whether we are going to claim in our ontology that the
geometric/topological space IS the class of states OR has some well-defined
relationship to it. In my head, mathematical models and ontological
classifiers are different kinds of abstractions, and I don't feel comfortable
conflating them. I want to distinguish between a class and a mathematical
model of the class. And in that, David and I seem to disagree.
(06)
-Ed
(07)
> -----Original Message-----
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
> summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Leal
> Sent: Thursday, March 14, 2013 6:03 AM
> To: Ontology Summit 2013 discussion; Ontology Summit 2013 discussion
> Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
>
> Dear Ed,
>
> I also agree with you in part. :)
>
> The first issue is the meaning of "state". For actual states it is
>straightforward.
> For example a test specimen goes through a sequence of actual states during
> a test. Each state has a time, and since time is more or less a one 1D
>manifold,
> so is the sequence of actual states. There are no choices of properties
> involved here. A state in the sequence can be identified by time, but we do
> not have to use time to identify the states. An arbitrary parameterisation
> may be useful, because
> (1) time might not be one of the properties recorded for a state, and (2)
> things may change much more rapidly at some times than others, and so a
> parameterisation which recognises this may be convenient.
>
> I raised this issue, because in a tensile test of a material specimen, the
>time,
> extension and force are recorded for a set of states within the 1D manifold.
> Unfortunately, many people say that the result of the test is a stress-strain
>or
> load-extension curve. Mmmm - not at first - these things are at the end of a
> long chain of derivations.
>
> For classes of state it is much less
> straightforward, because (as you say) you have to choose the criteria for
> membership of a class of state - i.e. the properties that characterise a
>class of
> state. My next sentence was about to be:
> "Therefore the dimensionality of the space of classes of state is a choice.",
> but this jumps the gun. If the properties that we choose to define the space
> of classes of state have ranges that are manifolds, then the space of classes
> of state is a manifold, and has a dimensionality that depends upon the
> choice. (I don't think dimensionality is defined for things that are not
> manifold - I may be wrong and would like to hear of any other definition.)
>
> I am reluctant to say that some things are mathematical artefacts, and that
> others are not.
> The statement that "the space of classes of state defined by the choice of
> stress, strain and temperature as criteria is a 2D manifold" may be
>incorrect,
> but it is a useful assumption. I make lots of incorrect statements but useful
> statements about things which I do not dismiss as mathematical artefacts.
>
> Best regards,
> David
>
> At 21:50 13/03/2013, Barkmeyer, Edward J wrote:
> >David,
> >
> >Upon reflection, I see what you mean, and I agree in part. The
> >theoretical model of a space of states is elegant, and it is probably
> >better than the simple idea of a curve. BUT from a philosophical
> >ontology point of view, 'states of WHAT?'. The problem is that we only
> >model some properties of the thing, when in its changes of state many
> >other properties may also change. So each of these measured points in
> >the space is a partial characterization of a
> >state: specifically, the state projected onto exactly those property
> >axes. That is importantly different from the IDEAS notion of a
> >thing-state in 4D. Further, these projections only show correlations.
> >We don't know how many actual states are projected onto the same point.
> >We only know that some measurements of a thing in some state produced
> >these values (ignoring the possibility of Heisenberg effects).
> >Finally, whereas the idea of using a mathematical algorithm to
> >interpolate and flesh out a curve in a measure space is mathematically
> >clear, it is not clear what interpolation might mean with respect to
> >states of a thing. The interpolation you describe simply produces new
> >points in the mathematical space -- there is no way to know whether
> >there are or could be any real states of objects that are projected
> >onto these theoretical points.
> >
> >We should also note that while the (geometrical) projection space has a
> >topology, as you point out, there is no real way to know what the
> >topology of the actual thing-state space might be like. As engineers,
> >we presume that many such functions are continuous and we draw curves,
> >but the reality might be discontinuous, in the sense that some
> >theoretical states necessary to the mathematical continuity might not
> >actually "occur in nature". Most importantly, we don't really care
> >that the actual state space is continuous. We only use the
> >mathematical model to predict the approximate properties of whatever
> >actual states are projected into that neighborhood.
> >
> >So, I can agree that the theoretical model you present is more elegant,
> >but the points in your model of the property space are also "not the
> >fundamental objects, but instead artefacts created to present data."
> >They are just somewhat different mathematical artefacts.
> >
> >-Ed
> >
> >
> > > -----Original Message-----
> > > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
> > > summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Leal
> > > Sent: Tuesday, March 12, 2013 6:36 PM
> > > To: Ontology Summit 2013 discussion; Ontology Summit 2013 discussion
> > > Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> > >
> > > Dear Matthew and Ed,
> > >
> > > I believe that you are both wrong. The curves in a n-dimensional
> > > property space, or the functions between property spaces, are not
> > > the fundamental objects, but instead artefacts created to present data.
> > >
> > > The key object is a space of states, where each state within the
> > > space has many measurable properties. Examples of such spaces of
> > > states are states of a pump (with different Q, h values) or states
> > > of a material test specimen (with different times, loads and extensions).
> > >
> > > It can be convenient to present the way that
> > the properties vary with respect
> > > to a space of states as a curve or surface in
> > an n-dimensional property space
> > > or as a function between property spaces.
> > >
> > > It can also be convenient to identify each
> > state within a space by a number,
> > > or tuple of numbers, (i.e. by a parameter
> > space) and to present the variation
> > > of each property separately with respect to the parameter space.
> > >
> > > I have referred to a "space of states" rather
> > than a "set of states", because
> > > although there is a set of states, there is also a topology for the set.
> > >
> > > In an instrumentation system, the properties are recorded for only
> > > some states within the space.
> > > It may be convenient to define an interpolation rule, which predicts
> > > the properties at others.
> > >
> > > Best regards,
> > > David
> > >
> > > At 22:00 12/03/2013, Barkmeyer, Edward J wrote:
> > > >Matthew,
> > > >
> > > >I wrote:
> > > >
> > > > > Humans often exchange these curves as graphs,
> > > > but software isn̢۪t good at turning PNG NG images into
> > > > quantitative performance estimations.
> > > > > I know for a fact that this last problem is not solved in 15926,
> > > >
> > > >
> > > >Matthew wrote:
> > > >
> > > > > MW: There is something called
> > > > multidimensional_property_space which was intended to handle
> > > > things like pump curves.
> > > > Were you aware of that, or have you tried it and found it wanting?
> > > > I̢۪d be interested in in your experience. The idea would be to
> > > > specify sufficient points from the curve that you were happy to
> > > > interpolate between them.
> > > >
> > > >I understand this thing to be a sequence of points in n-space,
> > > >where each dimension is a property. The ontological problem is
> > > >that that is not a curve -- it is a sequence of points. In the
> > > >STEP models, for example, there are B-spline curves that are
> > > >defined by a series of inflection points, and that series defines a
> > > >unique curve. The series is defined to be the representation of a
> > > >B-spline, with that interpretation of the points. If I specify a
> > > >set of points and require a particular fit algorithm for a
> > > >particular kind of parametrized function, that is the definition of
> > > >a curve. I suppose there should be specializations of the general
> > > >multidimensional_property that would clarify this, but the idea
> > > >that it is a sequence of points in n-space doesn̢۪t mean much bh
> > > >by itself. (I would say this is an ontology of a representation
> > > >and not of the concept.)
> > > >
> > > >That said, the sad fact is that a pump curve really is just
> > > >someone's fit to a set of actually measured values for particular
> > > >inputs, and the real data is just the pairs (input, measured
> > > >behavior). The fit is indeed in the eye of the sender, and if the
> > > >receiver uses a different algorithm and gets a different curve,
> > > >neither of them is necessarily "right" (they are just the products
> > > >of different engineering intuitions or skills), and the proof of the
> pudding will come in the pump test.
> > > >That is, the multidimensional_property really is just a set of
> > > >observations. The pump curve is not the same kind of thing as a
> > > >spline curve specification for an airfoil, where that shape is what
> > > >will have the desired aerodynamic properties.
> > > >
> > > >-Ed
> > > >
> > > >--
> > > >Edward J. Barkmeyer Email: edbark@xxxxxxxx
> > > >National Institute of Standards & Technology Systems Integration
> > > >Division
> > > >100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
> > > >Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800
> > > >
> > > >"The opinions expressed above do not reflect consensus of NIST,
> > > > and have not been reviewed by any Government authority."
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > > >[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> > > Matthew
> > > >West
> > > >Sent: Tuesday, March 12, 2013 4:12 PM
> > > >To: 'Ontology Summit 2013 discussion'
> > > >Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> > > >
> > > >Dear Ed,
> > > >
> > > >I have to disagree. Only some measurement data is easy to
> > > >exchange, and even then one must be careful that both the sender
> > > >and the receiver have a common understanding of the nature and
> > > >purpose of the measurement. This includes simple common sense
> > > >ideas like agreeing on (and
> > > >documenting) the units to be used, or explicitly exchanging units
> > > >with the numeric measurements. It also includes agreement on
> > > >rounding values or stating uncertainties.
> > > >
> > > >MW: I agree. I meant to say “basic measurement dataâ€Â.
>The
> > > >rest of
> > > >w> >what you say is precisely why I said:
> > “By the way, m measurements look
> > > >easy from the outside, but once you lift the lid, you find all
> > > >kinds of interesting things there you can easily get tripped up
> > > >by.â€Â
> > > >
> > > >But there is a lot more to the context of a measurement than just
> > > the
> > > >units and the uncertainty. There are standard sizes that have the
> > > >same name but temporal differences in tolerances, and there are
> > > >considerations like operational state and ambient temperature and
> > > >pressure that affect values of the same measurement of the same
> thing.
> > > >And finally, like parametrics, there are measurement values that
> > > >are plugged into functions and equations to produce other
> > > >measurement values, and it is very important to agree on what those
> > > >mathematical formulae are. In the particular case of chemical
> > > >processes, semiconductor fabrication, and plastic and metal
> > > >molding, for example, a group of reference measurements is used to
> > > >specify an observed performance curve, while the actual process
> > > >depends on accurate depiction of performance at other points on
> > > >that curves. Humans often exchange these curves as graphs, but
> > > >software isn̢۪t good at turning PNG images into quanuantitative
> performance estimations.
> > > >
> > > >I know for a fact that this last problem is not solved in 15926,
> > > >
> > > >MW: There is something called
> > > >multidimensional_property_space which was intended to handle things
> > > >like pump curves. Were you aware of that, or have you tried it and
> > > >found it wanting? I̢۪d be interested in yo your experience. The
> > > >idea would be to specify sufficient points from the curve that you
> > > >were happy to interpolate between them.
> > > >Regards
> > > >Matthew
> > > >
> > > >and you don̢۪t want to open the Pandora̢۪s box th box
>that is
> > > >the relationship between control parameters and performance
> parameters.
> > > >This is not, in general, a solved problem. There are known
> > > >standard solutions to specific known problems. The best guidance
> > > >is to characterize the measurement information you want to exchange
> > > >in the context of use and look to see whether that problem has
> > > >already been acceptably solved in industry.
> > > >
> > > >The important ideas in the VIM are (a) that every quantity (in a
> > > >use) has a ‘quantity kindÃd’ that identifies what
>quantities
> > > >it can be comcompared with, (b) that no quantity can be known
> > > >exactly, measurements are comparisons against reference quantities
> > > >of the same kind,
> > > >(c) that units are associated with quantity kinds and are reference
> > > >quantities for comparisons. The rest is about what measurement you
> > > >made, how you made it, and how accurate you know your technique to
> > > >be in that situation.
> > > >
> > > >There are many cases in which most of these details don̢۪t
> > > >matterter, because both parties to the exchange understand the
> > > >intent and typical quality of the measurement. But there are also
> > > >many cases in which some of these details do matter, because the
> > > >parties to the exchange have different backgrounds and mental
> > > >models of the situation. The designer of an airflow system and the
> > > >designer of the fans do not have the same model of the problem
> > > >space. They do have models that can be aligned for the purpose of
> > > >their interaction, but they have to be cognizant of the need for that
> alignment in their exchanges.
> > > >
> > > >-Ed
> > > >
> > > >
> > > >--
> > > >Edward J. Barkmeyer Email: edbark@xxxxxxxx
> > > >National Institute of Standards & Technology Systems Integration
> > > >Division
> > > >100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
> > > >Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800
> > > >
> > > >"The opinions expressed above do not reflect consensus of NIST,
> > > > and have not been reviewed by any Government authority."
> > > >
> > > >
> > > >
> > > >From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > > >[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> > > Matthew
> > > >West
> > > >Sent: Tuesday, March 12, 2013 7:11 AM
> > > >To: 'Ontology Summit 2013 discussion'
> > > >Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> > > >
> > > >Dear Deborah,
> > > >Well if you are trying to exchange measurement data, that is
> > > >relatively easy, and pointing to parametric design examples as
> > > >having problems for standards based exchange, therefore meaning
> > > >that standards based exchange of measurement data is difficult is
> > > >just plain misleading. You can easily exchange measurement data
> > > >using ISO
> > > >15926 for example, or a number of other standards, usually labelled
> > > >SCADA (supervisory control and data acquisition). What is not
> > > >needed is another standard for doing this, there are already too many.
> > > >By the way, measurements look easy from the outside, but once you
> > > >lift the lid, you find all kinds of interesting things there you
> > > >can easily get tripped up by  anothher reason for not reinventing.
> > > >
> > > >Regards
> > > >
> > > >Matthew West
> > > >Information Junction
> > > >Tel: +44 1489 880185
> > > >Mobile: +44 750 3385279
> > > >Skype: dr.matthew.west
> > > >matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > >http://www.informationjunction.co.uk/
> > > >http://www.matthew-west.org.uk/
> > > >
> > > >This email originates from Information Junction Ltd. Registered in
> > > >England and Wales No. 6632177.
> > > >Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
> > > >Hertfordshire, SG6 3JE.
> > > >
> > > >
> > > >
> > > >From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > > >[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx]
> > > > On Behalf Of Deborah MacPherson
> > > >Sent: 12 March 2013 10:11
> > > >To: Ontology Summit 2013 discussion
> > > >Cc: Ontology Summit 2013 discussion
> > > >Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> > > >
> > > >Thanks for the response Matthew. You are probably right on target.
> > > >The thing is some problems and opportunities should not wait.
> > > >Creating modular solutions to keep some information in sets as its
> > > >transferred would help.
> > > >
> > > >Toby and I have been talking about "lighter"
> > > >versions of our standards that are made for heavy monolithic
> > > >models. What I like about BACnet as an angle on this is the
> > > >transactional nature of collecting and reporting temperatures,
> > > >tasking sensors and so forth that are only one small set of
> > > >information at a time.
> > > >
> > > >Deborah
> > > >
> > > >Sent from my iPhone
> > > >
> > > >On Mar 12, 2013, at 4:46 AM, "Matthew West"
> > > <dr.matthew.west@xxxxxxxxx> wrote:
> > > >Dear Deborah,
> > > >I think the problem, in this case at least, is not quite as you
>describe.
> > > >My understanding is that the issue here was around parametrically
> > > >defined objects, where different CAD systems use different
> > > >parametric functions to generate objects from their parametric
> > > >definition. Because of the different functions, to round trip you
> > > >would have to wrap the parametric description so it can be sent to
> > > >the receiving system, and sent back later.
> > > >Actually, I think it would be smarter just to send an identifier
> > > >that told you the original object when it came back, but even that
> > > >does not help you with changes that have been made to the object in
> > > >the receiving system with an incompatible parametric system. The
> > > >problems are just harder than you would think at a surface level.
> > > >Now this is just an inevitable stage of development. In the early
> > > >stages, a thousand flowers bloom, but the vast majority fade.
> > > >Eventually a few remain, and it becomes more important (now these
> > > >are the survivors) that they can interoperate, than that they
> > > >retain competitive advantage, so interoperation is achieved, or a
> > > >standard developed that customers require them to conform
> > > to.
> > > >You can see that the state you are pointing to is in the middle of
> > > >this process. Eventual completion of the process is pretty much
> > > >inevitable. The bad news is that from what I have seen and
> > > >experienced there is relatively little you can do to speed the
> > > >process up (or slow it down) significantly and the time-scale for
> > > >the process is decades (or more in some cases), not months or years.
> > > >So the smart thing to do is to recognise where you are, try to
> > > >encourage progress through the process, and adopt strategies that
> > > >recognise the reality of where you are in the process.
> > > >
> > > >Regards
> > > >
> > > >Matthew West
> > > >Information Junction
> > > >Tel: +44 1489 880185
> > > >Mobile: +44 750 3385279
> > > >Skype: dr.matthew.west
> > > >matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > >http://www.informationjunction.co.uk/
> > > >http://www.matthew-west.org.uk/
> > > >
> > > >This email originates from Information Junction Ltd. Registered in
> > > >England and Wales No. 6632177.
> > > >Registered office: 2 Brookside, Meadow Way, Letchworth Garden City,
> > > >Hertfordshire, SG6 3JE.
> > > >
> > > >
> > > >
> > > >From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > > >[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx]
> > > > On Behalf Of MacPherson, Deborah
> > > >Sent: 11 March 2013 21:56
> > > >To: Ontology Summit 2013 discussion
> > > >Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> > > >
> > > >Somewhere in this discussion is a problem that is the essence of
> > > >what has been holding up
> > progress in the facilities domain.
> > > >
> > > >There are ways to publish technical requirements or test for
> > > >conformance online for free, and pay (even substantially) to
> > > >participate in the working groups or have voting privileges. For
> > > >example OGC, W3C.
> > > >
> > > >I can even see being able to own a part name or number within a
> > > >larger communication machine that could be mapped to a generic form
> > > >for broader exchange purposes. For example “13-57
> > > >13 1 15 Dining and Drinking Spacesâ€Â
> > versus “The San Sand Bar and Grilleâ€Â
> > > >
> > > >Depending on the domain,, or need for cross disciplinary
> > > >discussion, many on the IP-protected side have no interest in
> > > >supporting, or will even actively stops progress, on a common
> > > >model. There is also the problem of failed common models that do
> > > >not work, will not accommodate different object definitions - from
> > > >software to software or industry model to industry model - without
> > > >loss of data or functionality. Bentley systems has stepped forward
> > > >in this white paper on the IFC model to say actually  the emperor
> > > >has no clothes on. See pages 6 and 7 “Round Trippingâ€Â
> > > >
> > > >For some rea reason I think ontologies might be a way these
> > > >IP-With-Open problems might be fixed but maybe I am wrong or
> > > >wishing for too much.
> > > >
> > > >DEBORAH MACPHERSON
> > > >Specifications and Research
> > > >
> > > >Cannon Design
> > > >3030 Clarendon Blvd.
> > > >Suite 500
> > > >Arlington, VA 22201
> > > >
> > > >Phone: 703.907.2353
> > > >Direct Dial: 2353
> > > >
> > > >dmacpherson@xxxxxxxxxxxxxxxx
> > > >Cannondesign.com
> > > >Skype debmacp
> > > >
> > > >From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > > >[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> > > >Simon
> > > Spero
> > > >Sent: Monday, March 11, 2013 5:25 PM
> > > >To: Ontology Summit 2013 discussion
> > > >Subject: Re: [ontology-summit] Hackathon: BACnet Ontology
> > > >
> > > >On Mon, Mar 11, 2013 at 11:53 AM, Peter R.
> > > >Benson <Peter.Benson@xxxxxxxxx> wrote:
> > > >Deborah, IP is a real issue. We designed the
> > eOTD to try to resolve some of
> > > >these issues. In a dictionary the IP resides
> > in the representation but also
> > > >in the identifiers or codes as these are always copyright.
> > > >
> > > >That is not entirely clear; see e.g. SOUTHCO, INC v. KANEBRIDGE
> > > >CORPORATION (
> > > >
> > > >http://www.ca3.uscourts.gov/opinarch/021243pe.pdf
> > > > ), where part numbers were found to be not protected (but see
> > > >also how Alito takes care to distinguish Delta Dental )
> > > >
> > > >Simon
> > > >
> > >
> >_________________________________________________________
> > > ________
> > > >Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> > > >Subscribe/Config:
> > > >http://ontolog.cim3.net/mailman/listinfo/ontology-
> > > summit/
> > > >Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> > > >Community Files:
> > > >http://ontolog.cim3.net/file/work/OntologySummit2013/
> > > >Community Wiki: http://ontolog.cim3.net/cgi-
> > > bin/wiki.pl?OntologySummit2013
> > > >Community Portal: http://ontolog.cim3.net/wiki/
> > > >
> > >
> >_________________________________________________________
> > > ________
> > > >Msg Archives:
> > > >http://ontolog.cim3.net/forum/ontology-summit/
> > > >Subscribe/Config:
> > > >http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
> > > >Unsubscribe:
> > > >mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> > > >Community Files:
> > > >http://ontolog.cim3.net/file/work/OntologySummit2013/
> > > >Community Wiki:
> > > >http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
> > > >Community Portal: http://ontolog.cim3.net/wiki/
> > >
> > >
> > >
> ==========================================================
> > > ==
> > > David Leal
> > > CAESAR Systems Limited
> > > registered office: 31 Shell Road, Lewisham, London SE13 7DF
> > > registered in England no. 2422371
> > > mob: +44 (0)77 0702 6926
> > > landline: +44 (0)20 8469 9206
> > > e-mail: david.leal@xxxxxxxxxxxxxxxxxxx
> > > web site: http://www.caesarsystems.co.uk
> > >
> ==========================================================
> > > ==
> > >
> > >
> > >
> __________________________________________________________
> > > _______
> > > Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> > > Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> > > summit/
> > > Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> > > Community Files:
> > > http://ontolog.cim3.net/file/work/OntologySummit2013/
> > > Community Wiki: http://ontolog.cim3.net/cgi-
> > > bin/wiki.pl?OntologySummit2013
> > > Community Portal: http://ontolog.cim3.net/wiki/
> >
> >_________________________________________________________
> ________
> >Msg Archives:
> >http://ontolog.cim3.net/forum/ontology-summit/
> >Subscribe/Config:
> >http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
> >Unsubscribe:
> >mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> >Community Files:
> >http://ontolog.cim3.net/file/work/OntologySummit2013/
> >Community Wiki:
> >http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
> >Community Portal: http://ontolog.cim3.net/wiki/
>
>
> ==========================================================
> ==
> David Leal
> CAESAR Systems Limited
> registered office: 31 Shell Road, Lewisham, London SE13 7DF registered in
> England no. 2422371
> mob: +44 (0)77 0702 6926
> landline: +44 (0)20 8469 9206
> e-mail: david.leal@xxxxxxxxxxxxxxxxxxx
> web site: http://www.caesarsystems.co.uk
> ==========================================================
> ==
>
>
> __________________________________________________________
> _______
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
> Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-
> summit/
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
> Community Wiki: http://ontolog.cim3.net/cgi-
> bin/wiki.pl?OntologySummit2013
> Community Portal: http://ontolog.cim3.net/wiki/
(08)
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/ (09)
|