Hans, (01)
Yes. It is one of my dissertations, born of increasing dissatisfaction with
the 15926 effort. And no, I won't fight tooth and nail. It solves nothing.
And finally, you are right that this is probably the wrong forum. (02)
What I read, not so much between the lines, is that the purpose of ISO 15926,
as you see it, is to define the RDF schema for a giant triple-store of all
plant lifecycle data, because someone somewhere will want to implement that,
and SPARQL will make a wonderful query language to fit his needs. So, this is
not only about knowledge engineering; this is about database engineering using
triple stores. (If integrating RDBs with triple stores and SPARQL is your
goal, you should look at the stuff Kingsley Idehen is doing.) (03)
What EPCs already have is a giant relational database with several smart
front-ends that actually understand and were built to support specific aspects
of plant design and construction. What plant design software already has is a
giant hybrid database with smart interfaces for capturing and integrating
geometric design elements, and various kinds of design views, requirements,
components and sources, etc. The large firms involved have somewhere between
20 and 50 years' experience each in plant design and construction, and they are
on their second- or third-generation software toolset to support those
activities, and they have many megabucks/megaeuros/gigayen invested in that
software. The problem is that these people have different viewpoints and
different schemas, and a lack of standard exchange forms that cover more than
bits and pieces of the data. What does your would-be triple store have to
offer them? (04)
The concern is: can we develop an integrating ontology that can be used for
semantic mediation between the existing schemas, and provide a useful exchange
form based on the integrating ontology? You can think of that ontology as the
schema for your giant triple store, if you must, but the concern of the
commercial firms is to export from their existing stores in a standard form and
import into their existing stores in a standard form. And it is not clear at
all that a triple store schema is the best form of integrating ontology for
that purpose. (05)
There is little motive for anyone to rewrite the kinds of power tools that work
with the existing databases so that they can work with the ultimate integrating
triple store. The exchange form is a way station on the road between smart
information sources and smart information consumers. Some subset of the
ontology may be populated directly to create new applications at the 'handover'
points. That is the kind of development that firms like ThomasNet, for
example, are already engaged in (they will find you suppliers for products that
match the design specs, using some kind of inferencing technology). But taking
another view, their work and that of their competitors is just generating
another set of incompatible schemas that work for their particular
applications, in part because their software will be influenced by
industry-specific standards for descriptions of products of each kind (what the
data they can get will look like). (06)
There is some synergy between your goals and those of the major firms involved,
but your triple store is not on their critical path -- the common reference
ontology is the joint concern. The Big Data problem here is more of a Big
Ontology problem. There are lots of specialized pieces to a process plant.
But their critical path also involves a viable exchange form; and a clumsy
form, born of obsession with triples and upper ontologies, will interfere with
wide adoption. (07)
I would just like the crew to focus on getting clean ontologies with industry
support, stop talking about methodologies and mappings between unimportant
formalisms, and let the toolsmith gang argue about the physical exchange form
for the modeled information. (08)
-Ed (09)
--
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 (010)
(Note: my usual disclaimer is lacking here, because this has been discussed at
NIST and it is our position.) (011)
> -----Original Message-----
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
> summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Hans Teijgeler
> Sent: Thursday, January 23, 2014 6:29 PM
> To: 'Ontology Summit 2014 discussion'; doug@xxxxxxxxxx
> Subject: Re: [ontology-summit] The tools are not the problem (yet)
>
> Hi Ed,
>
> One of your "dissertations" :-)
>
> Twelve years ago I started Part 7 with XML Schema, but that didn't work for
> me.
>
> I read between your lines that in your mind ISO 15926 is for application
> interfacing only. But that's not so. It happens, but it's not the ultimate
>goal.
> The title of the standard is "Industrial automation systems and integration
> - Integration of life-cycle data for process plants including oil and gas
> production facilities".
> How do you integrate all the diverse historical information about a plant from
> concept to demolition over a period of decades? Not with XML.
>
> Add to that that during a large EPC project a multitude of parties, spread
> around the globe, not always knowing English well enough, work on the
> same plant and need to share data over the internet.
>
> We still have much work to do on the reference data library, which for the
> most is a taxonomy-only now, but by adding templates over the years must
> grow to a workable ontology.
> When one defines requirements he/she can use specializations of such
> templates. Our target is what we have seen passing by on this forum for the
> last couple of days, and so eloquently worded by you:
> "You have to determine that the definition is unambiguous, in terms of the
> definitions of the English words used and the syntactic (and pragmatic)
> context of their use. Then you have to determine whether that is exactly
> what you mean for your particular purposes."
>
> For the mapping of application data, from their proprietary format to ISO
> 15926 format, Ian Glendinning came with the concept of "patterns". These
> are words/concepts that software folks and engineers use in their software
> and reports. In the US the IIP folks are working on that and they have come
> up with a large list already. These are mapped to one or more interrelated
> templates with some fill-in-the-blanks fields. I expect that hat list will
>evolve
> in a kind of engineering dictionnary (with standard mappings).
>
> Finally this: the reason for chosing RDF and OWL was not reasoning or
> inferencing. No manager (in our business) in his right senses will accept the
> outcome of that as the basis for engineering. Besides, our world is that of
>the
> plant owners who will certainly not agree with any "open world"
> scenario. This is his lifecycle information, and no one shall get to that
>other
> than on a need-to-know basis with all due secrecy agreements. Very closed.
>
> So it will boil down to fairly straight forward data storage and retrieval in
>triple
> stores, be it with the semantic rigour and possibilities of ISO 15926. No
>fixed
> data model. And because of the mapping at the source, before storage, any
> data mining will be much easier than that requiring the usual "cleansing".
>
> Regards,
> Hans
>
> PS Before you start fighting the above tooth-and-nail, consider whether this
> is the right forum for that. I don't know, quite honestly.
>
> -----Original Message-----
> From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
> Barkmeyer, Edward J
> Sent: donderdag 23 januari 2014 23:05
> To: Ontology Summit 2014 discussion; doug@xxxxxxxxxx
> Subject: Re: [ontology-summit] The tools are not the problem (yet)
>
> Hans,
>
> Why don't we try the kind of thing that 15926 is supposed to address, e.g.:
>
> The discharge pressure of the Pump that is designated P-101A in the design
> specification (Dow-A47-2013-rev2) must be at least 5000 kPa.
>
> We can say that there is a PossibleIndividual PI-1 that fulfills this
> requirement.
> PI-1 is a Pump.
> PI-1 instantiates the class C-1.
> C-1 is a DesignElement
> C-1 has designation "P101A"
> C-1 is a part of PS-1.
> PS-1 is a PlantDesign ...
> PI-1 has a required property RP-101.
> RP-101 is a discharge-pressure
> RP-101 is greater-or-equal to Q-101.
> Q-101 has unit KPa
> Q-101 has ratio 5000.
>
> This is a simplification of the RDF form of the specification.
>
> By comparison, in XML this could be phrased:
>
> <rdl:PlantDesign id="PS-1" name="Dow-A47-2013-rev2">
> ...
> <rdl:DesignElement id="C-1" designation="P-101A" type="Pump">
> ...
> <HI50.7:minimumDischargePressure unit="KPa" value="5000" />
> ...
> </rdl:DesignElement>
> ...
> </rdl:SystemSpecification>
>
> Note that the content of these two forms is the same, and the degree of
> formal definition in the two is approximately the same as well! Further, it
> doesn't take much in the line of a transformation tool to convert the second
> form to the first, if that is what is wanted, but the reverse is more
> complex: it involves matching a pattern that doesn't have a formally defined
> structure. And the second form can be much more readily transformed into
> whatever the internal form is in the software system being used to manage
> the plant construction.
>
> And what are we expecting to be the value of the RDF? Well, if a Pump
> manufacturer exports a similar description of his Pump designs (Pump
> classes), then some engine could infer that PI-1 "is an instance of" one or
> more of those Pump classes, which is to say, "P-101A could be satisfied by"
> such a Pump. Does anyone seriously think that that inference would be a
> great deal more difficult if the data were exchanged in the XML form? And
> more importantly, did the plant construction firms and the eventual plant
> owners express a desire to import the design specification into such an
> inference engine, as distinct from their SAP system, for example?
>
> As an identifier for a concept: HI50.7:minimumDischargePressure with the
> appropriate xmlns assignment has exactly the same IRI properties as
> http://HydraulicInstitute.org/HI50.7#minimumDischargePressure, and the
> same is true of the rdl: entries. And OBTW, they both have the same formal
> definition, in English. Further, both of these approaches -- the RDF ontology
> and the XML schema -- provide similar "context" for the use of the term. But
> the XML schema directly associates that term with certain other required
> information units with data types, while the RDF form does not.
>
> For LinkedOpenData, the RDF form may be preferable, in that it doesn't
> prejudice what kinds of information can be attached to that symbol. But for
> exchanging plant construction requirements, we very much want to
> prejudice the kinds of information that MUST BE attached to that symbol.
>
> The problem here is that the RDF syntax was chosen because it is au courant
> among some knowledge engineers, not necessarily because it was
> appropriate to the problem. Other knowledge engineers have made do with
> XML inputs, mapped them to a reference ontology, e.g. in OWL, and made
> whatever inferences they needed using that ontology and whatever
> inference engine was appropriate to their task.
>
> The concern of many ISO 15926 folk is that such an XML Schema is tied to a
> specific point in the lifecycle, whereas some of the conceptual elements in it
> can be reused at other points in the lifecycle, in which the corresponding
> information exchanges will have different forms. And that is where the
> reuse issue becomes interesting. It is important to be able to reuse the
> symbol in a different context, knowing that the meaning of the symbol is the
> same. But surely that is about defining the information element properly,
> and importing it, using whatever capability your chosen language allows, into
> the ontology/schema for the lifecycle phase of interest. The property is the
> same, regardless of what item has it. At the same time, there is a difference
> between a design requirement, a product characterization, and an in-
> operation measurement, all of which are USES of the property, and the
> context of use does condition the meaning of the utterance. So, it is
> important to be abl e to define the data element independently, but to
> formally contextualize it in a usage, and I don't see RDF having a clear
> advantage over XML in that regard.
>
> The value of using an au courant software technology is that you can find
> programmers who know how to use it. But you have to choose a technology
> that is consistent with what the user wants to do, and thus be aware of what
> the programmers are going to be asked to use it for. I don't see that RDF is
> particularly well-suited to the problem of plant information exchange among
> the major software tools used to design, build and manage a plant.
> The idea that reasoning tools will somehow be a part of that process in the
> near future is worth investigating, but it is not what the users need now.
> And the RDF forms being proposed may not be ideal for commercial
> inference tools in that area when they appear (which was David Price's
> point).
>
> What is most wanted from the 15926 academic efforts is a solid reference
> ontology for process plant components and their properties, expressed in a
> language that suits that purpose reasonably well, like OWL. Doing that
> properly requires the participation of many experts in various component
> domains and a standardized approach to making OWL models. It is a no-
> brainer to agree that 'FittingType' is a 'class of classes of inanimate
>physical
> object', and saying that has nearly no value. The interesting coordination
> problem is whether the OWL form is a set of subclasses or a set of individuals
> (so that two working groups will produce similar structures) and whether the
> concept is the same for Pump fittings and Valve fittings (whether the two
> working groups can use a common ontology module).
>
> I have gotten really tired of activities whose primary interest is in
>developing
> new tools and philosophical upper level ontologies and development
> methodologies. If you want to produce something of value to industry,
> formalize the concepts in a real application domain. As the late Selden
> Stewart once observed, "By definition all information technology is meta-
> work. It follows that standards for information technology is meta-meta-
> work, and methodologies for the development of standards for information
> technology is meta-meta-meta-work. The more 'metas', the further from
> any practical value to anyone."
>
> -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."
>
>
>
>
> > -----Original Message-----
> > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
> > summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Hans Teijgeler
> > Sent: Thursday, January 23, 2014 4:41 AM
> > To: doug@xxxxxxxxxx; 'Ontology Summit 2014 discussion'
> > Subject: Re: [ontology-summit] The tools are not the problem (yet)
> >
> > Doug,
> >
> > I have a question to you, and I am in doubt whether it is appropriate
> > to
> put
> > that forward in this forum. If inappropriate, please reply in private.
> >
> > You wrote: "Other computer scientists do not limit methods/routines to
> > having exactly two arguments. Of course, they see this box RDFers put
> > themselves in as counterproductive."
> >
> > Implementers of ISO 15926 are in that box, they struggle with the
> > seeming incompatibility of that standard and RDF, because ISO 15926
> > has the
> concept
> > of Relationship:
> > QUOTE
> > A relationship is something that one thing has to do with another (see
> > 5.2.11 and Figure 187). In this part of ISO 15926, a relationship is
> defined as
> > the classification of an ordered pair. The pair is repeated to record
> another
> > relationship. No two relationships of the same classification have the
> same
> > pair in the same order. The order enables roles to be assigned to the
> related
> > things.
> > UNQUOTE
> >
> > Examples:
> > * Classification with roles classified (shall be a Thing) and
> > classifier
> (shall be a
> > Class)
> > * RelativeLocation with roles located (PossibleIndividual) and locator
> > (PossibleIndividual)
> > * Composition with roles part (PossibleIndividual) and whole
> > (PossibleIndividual)
> > etc.
> >
> > We also have ClassOfRelationship, one meta level up, and even
> > ClassOfClassOfRelationship one more up.
> >
> > Relationship instances can be addressed by other instances of
> Relationship,
> > such as: "this marriage (relationship) is a same-sex marriage
> (classification),
> > and it is not approved (relationship) by John Doe"
> >
> > In the jargon of RDF these Relationships are a kind of 'reified'
> properties.
> > In pure RDF, for information storage, we have made a workaround, but
> > when we want to use OWL for reasoning we seem to have a problem,
> > because this does not fit in the OWL mould (so some experts claim).
> > Yet to us, representatives of parties involved in the process
> > industries, the
> addition
> > of the ISO 15926 meta model to OWL is adding semantic precision.
> >
> > My question to you is whether or not ISO 15926 Relationships can be
> treated
> > as owl:Class, be it that these owl:Classes have two predefined
> rdf:Properties.
> > Does that make reasoning impossible?
> >
> > Regards,
> > Hans
> > www.15926.org
> >
> > PS Oh BTW, we also have MultidimensionalObject, which is an entity
> > type with a list of 2 - many predicates, but I didn't want to boil the
> > ocean :)
> >
> >
> __________________________________________________________
> > __________________
> > ______________________________________________
> >
> > -----Original Message-----
> > From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
> > [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of doug
> > foxvog
> > Sent: donderdag 23 januari 2014 7:35
> > To: Ontology Summit 2014 discussion
> > Subject: Re: [ontology-summit] The tools are not the problem (yet)
> >
> > On Tue, January 21, 2014 17:28, John McClure wrote:
> > [text below; commented on parts here]
> >
> > > There are two competing notions of the *predicate* in theories of
> > > grammar
> >
> > I.e., there are two meanings, and the same word is used for each.
> >
> > People should realize that such cases are not competing notions of
> > some thing, but multiple notions, with the unfortunate use of the same
> > label
> for
> > the different things.
> >
> > > The first concerns traditional grammar, which tends to view a
> > > predicate as one of two main parts of a sentence, the
> > > other part being the subject;
> > > the purpose of the predicate is to modify the subject.
> >
> > I would disagree with this "purpose" claim. That isn't what
> > traditional grammar claims about this notion of "predicate".
> >
> > > The second derives from work in predicate calculus (predicate logic,
> > > first order logic)
> > > and is prominent in modern theories of syntax and grammar. In this
> > > approach, the predicate of a sentence corresponds mainly to the main
> > > verb and any auxiliaries that accompany the main verb, whereas the
> > > arguments of that predicate (e.g. the subject and object noun
> phrases
> > > are outside the predicate. [wikipedia
> >
> > This second meaning is that which we are using in ontologies. Note
> > that
> in
> > this meaning, the predicate "corresponds mainly" to verbs -- is
> > different
> from
> > saying that the predicate is a verb. Here we have gotten away from
> natural
> > language and need not be concerned with verbs. If we choose to
> > express a statement in a natural language, we can choose to map the
> > predicate to a (set of) verb(s).
> >
> > Note also that this definition does not require there to be exactly
> > two arguments. There may be one, two, or more.
> > * S V
> > * S V O
> > * S V DO IDO
> >
> > > If (1) rdf:Statement = rdf:subject + rdf:predicate + rdf:object,
> > > then to which of these "competing notions" does rdf:predicate refer?
> >
> > It is a subset of the second meaning, with exactly two arguments.
> >
> > > If you say
> > > the former, then I maintain the formulation should be (2)
> > > rdf:Statement = rdf:subject + rdf:predicate.
> >
> > So this is not the meaning.
> >
> > > If you say the latter, then WHERE ARE THE VERBS
> >
> > As mentioned above, definition 2 predicates *correspond* to verbs --
> > they don't need to be verbs. Therefore i will take your "VERBS" to
> > mean predicates.
> >
> > Thus, the VERBS are the binary predicates used in each embedded
> sentence.
> > * rdf:about
> > * rdf:Property
> > * xml:lang
> > * rdfs:label
> > * rdfs:comment
> > * rdf:resource
> > * rdfs:domain
> > * rdfs:range
> > * rdfs:subPropertyOf
> >
> > > - why do we see predicates defined like
> > > <rdf:Property rdf:about="&p3p;purposeOptIn">
> >
> > Because of the syntax used.
> >
> > >why on earth is this thing called a "Statement"?
> >
> > It is a "Statement" because it is a set of statements that are
> interconnected,
> > some being used as arguments to others and some being implicitly
> > anded. A sentence diagram for this statement is quite possible, though
> complex.
> >
> > It is a single sentence because the predicate rdf:about relates
> > "&p3p;purposeOptIn" to a single property which happens to be a set of
> > properties.
> >
> > > In short, the entire body of predicates defined by the [RDF]
> > > "ontologist community" to-date are fundamentally flawed.
> >
> > Flawed as a body, yes. But i suggest this does not mean that each
> individual
> > predicate is flawed. The requirement to use only binary predicates is
> > the flaw -- it is the hammer that is the chosen tool to solve every problem.
> >
> > > It's small wonder SMEs look
> > > askance at ontologists and their gee-whiz ideas; in their gut, they
> > > know something is amiss.
> >
> > Other computer scientists do not limit methods/routines to having
> > exactly two arguments. Of course, they see this box RDFers put
> > themselves in as counterproductive.
> >
> > > (Note: this perspective is completely scoped within the RDF, where
> > > many of us 'practitioners' must wallow, so replies of 'use CycL'
> > > are simply unresponsive to the needs of what, 95% of the people in
> > > this forum.)
> >
> > I suggest removing the "must". One might use RDF as a communication
> > standard, but that does not mean that an processing must be done using
> > it (other than converting between it and a more accessible form).
> >
> > Why wallow?
> >
> > -- doug
> >
> > > =============================
> > On Tue, January 21, 2014 17:28, John McClure wrote:
> > > John Sowa et al,
> > > <rant>I do agree SMEs' stakeholdership in an ontology is key to what
> > > ails us. But the problem is with the way we create ontologies; until
> > > we grapple with that, "better tools are the answer" is merely
> > > lipstick on a pig. SMEs certainly /should/ recoil at stuff like:
> > >
> > > <rdf:Property rdf:about="&p3p;purposeOptIn">
> > > <rdfs:label xml:lang="en">purpose(opt in)</rdfs:label>
> > > <rdfs:comment>
> > > Data may be used for this purpose only when the user
> > > affirmatively requests this use.
> > > </rdfs:comment>
> > > <rdfs:domain rdf:resource="&p3p;Statement"/>
> > > <rdfs:range rdf:resource="&p3p;PurposeClass"/>
> > > <rdfs:subPropertyOf rdf:resource="&p3p;purpose"/>
> > > </rdf:Property>
> > >
> > > No amount of tools, in my humble opinion, will /ever/ hide this
> > > odiferous _crap_. I strongly suspect that I could pull equally
> > > useless
> > > *properties* from whatever ontology is being hoisted on a pedestal,
> > > and effortlessly mock it too. IOW the way we use the RDF is
> > > thoroughly corrupt. Why/how? Here's the nub.
> > >
> > > There are two competing notions of the *predicate* in theories of
> > > grammar <https://en.wikipedia.org/wiki/Grammar>.^[1]
> > >
> > > <https://en.wikipedia.org/wiki/Predicate_%28grammar%29#cite_note-
> > 1>
> > > The first concerns traditional grammar, which tends to view a
> > > predicate as one of two main parts of a sentence
> > > <https://en.wikipedia.org/wiki/Sentence_%28linguistics%29>, the
> > > other part being the subject
> > > <https://en.wikipedia.org/wiki/Subject_%28grammar%29>; the
> purpose
> > > of the predicate is to modify the subject. The second derives from
> > > work in predicate calculus (predicate logic
> > > <https://en.wikipedia.org/wiki/Predicate_logic>, first order logic)
> > > and is prominent in modern theories of syntax and grammar. In this
> > > approach, the predicate of a sentence corresponds mainly to the main
> > > verb and any auxiliaries that accompany the main verb, whereas the
> > > arguments <https://en.wikipedia.org/wiki/Verb_argument> of that
> > > predicate (e.g. the subject and object noun phrases
> > > <https://en.wikipedia.org/wiki/Noun_phrase>) are outside the
> > > predicate. [wikipedia
> > > <https://en.wikipedia.org/wiki/Predicate_%28grammar%29>]
> > >
> > > If (1) rdf:Statement = rdf:subject + rdf:predicate + rdf:object,
> > > then to which of these "competing notions" does rdf:predicate refer?
> > > If you say the former, then I maintain the formulation should be (2)
> > > rdf:Statement = rdf:subject + rdf:predicate. If you say the latter,
> > > then WHERE ARE THE VERBS - why do we see predicates defined like
> > >
> > > <rdf:Property rdf:about="&p3p;purposeOptIn">
> > >
> > > And if you were to say neither, then I ask why on earth is this
> > > thing called a "Statement"? Can we not stop making words up that
> > > suit arbitrary purposes?
> > >
> > > In short, the entire body of predicates defined by the "ontologist
> > > community" to-date are fundamentally flawed. It's small wonder SMEs
> > > look askance at ontologists and their gee-whiz ideas; in their gut,
> > > they know something is amiss. (Note: this perspective is completely
> > > scoped within the RDF, where many of us 'practitioners' must wallow,
> > > so replies of 'use CycL' are simply unresponsive to the needs of
> > > what, 95% of the people in this forum.)
> > >
> > > </rant>
> > >
> > >
> > >
> >
> __________________________________________________________
> > _______
> > > 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/OntologySummit2014/
> > > Community Wiki:
> > > http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
> > > 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/OntologySummit2014/
> > Community Wiki: http://ontolog.cim3.net/cgi-
> > bin/wiki.pl?OntologySummit2014
> > Community Portal: http://ontolog.cim3.net/wiki/
> >
> >
> > -----
> > Geen virus gevonden in dit bericht.
> > Gecontroleerd door AVG - www.avg.com
> > Versie: 2014.0.4259 / Virusdatabase: 3681/7024 - datum van uitgifte:
> > 01/22/14
> >
> >
> >
> __________________________________________________________
> > _______
> > 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/OntologySummit2014/
> > Community Wiki: http://ontolog.cim3.net/cgi-
> > bin/wiki.pl?OntologySummit2014
> > 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/OntologySummit2014/
> Community Wiki: http://ontolog.cim3.net/cgi-
> bin/wiki.pl?OntologySummit2014
> Community Portal: http://ontolog.cim3.net/wiki/
>
>
> -----
> Geen virus gevonden in dit bericht.
> Gecontroleerd door AVG - www.avg.com
> Versie: 2014.0.4259 / Virusdatabase: 3681/7027 - datum van uitgifte:
> 01/23/14
>
>
> __________________________________________________________
> _______
> 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/OntologySummit2014/
> Community Wiki: http://ontolog.cim3.net/cgi-
> bin/wiki.pl?OntologySummit2014
> Community Portal: http://ontolog.cim3.net/wiki/ (012)
_________________________________________________________________
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/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
Community Portal: http://ontolog.cim3.net/wiki/ (013)
|