Excellent comments, and I'm sorry I missed this. I'd say a versioning
service is an important contribution to the requirements. (01)
Again, if folks who spoke on the panels can provide the OOR group with
a 2 slide summary of their presentations, that would be great. (02)
Mike Dean, Peter Yim, and I will use these to prepare an OOR
presentation on the 2nd day of the Summit. (03)
We're also looking for volunteers to present the OOR panel slides
(those 2 slides from each panelist from each session, plus the
continuity narrative) on that 2nd day OOR session. (04)
So far, Ravi Sharma and Ken Baclawski have volunteered. Any others? (05)
Thanks,
Leo (06)
_____________________________________________
Dr. Leo Obrst The MITRE Corporation, Information Semantics
lobrst@xxxxxxxxx Information Discovery & Understanding, Command and
Control Center
Voice: 703-983-6770 7515 Colshire Drive, M/S H305
Fax: 703-983-1379 McLean, VA 22102-7508, USA (07)
-----Original Message-----
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Evan
Wallace
Sent: Thursday, April 10, 2008 6:38 PM
To: Ontology Summit 2008
Subject: [ontology-summit] Richness of versioning support (08)
All, (09)
During today's session on Metadata for ontology repositories (see
http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2008_04_10)
there
was a
side discussion regarding configuration management and version labeling (010)
for ontologies
stored in an OOR. I think that it would be a good idea to repeat the
comments and
have follow-on discussion on the mailing list. To get this started I
will paste the
comments from today's chat session and include my own response below: (011)
** Comments from 10 April Ontology of Ontologies session related to
versioning: ** (012)
AnnWrightson: Following on from the response just now, and thinking
back
to the NASA
presentation on 20-3: though we shouldn't expect the OOR to provide or
perform
configuration management of ontologies, I guess there should be
guidance
concerning
provision of versioning information that will support users who want to (013)
reuse ontologies
within a strong configuration management or product line development
environment. (014)
Michelle Raymond: Ann Wrightson mentions that (paraphased) 'in product
line
development environments strong configuration management is required.' (015)
Currently,
there are industry product providers that very much MUST point to the
exact ontology
AND the associated metadata for that ontologies when providing a
product
release. To
do this now, sometimes the "real" standard can't be linked in, as there (016)
is concern that it
has remained static or at least a needed level of consistency. Thus,
the vendor includes
a copy of the ontology and associated metadata, files, documents and
the
like in there
product release and does not encourage customers to visit the "real"
source. This can
be a legal issue of "fair use" when a copy is made. It is also
disassociating the product
from the further value potentially available in the "real" ontology and (017)
the repository that
holds it. I believe we need to address this issue both in firm rules
that SHALL NOT allow
revision of a "status=final" ontology and that we must further consider (018)
requiring some
meta-data associated with an ontology as also being "status=final."
Comments about
my statements are very much desired as is turning this into a
conversational thread. (019)
** end chat comments ** (020)
The reference in the first comment is to the session described at
http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2008_03_20 I
would guess.
I missed that session and would like to hear more about what is meant
by
"we shouldn't expect the OOR to provide or perform configuration
management of
ontologies". It's fine to agree that the OOR won't perform the
configuration management
of its content, but it should provide the ability for ontology authors
or curators to
create and maintain separate, simultaneously maintained version
threads. Failing that
a useful OOR must at least provide the ability to save and persist
complete snapshots of
an ontology version with its associated metadata. (021)
I'm really not sure that "status=final"
applies to ontologies (since they may be updated to address problems
found with them,
changes in the language they were written in, or changes in what they
represent) but this
snapshotting capability plus a way to review to a shapshot, should give (022)
you a way to point
to an unchanging version. The big problem, as I see it, is how to know (023)
which versions to
reference (e.g., for import) as different components evolve. This
boils
down to determining
the effectivity parameters for each import. Chances are you don't know (024)
them at the time that
facts or ontology extensions are created. These parameters emerge as
related components are
revised in ways that are incompatible with the components that are
using
them. (025)
-Evan (026)
Evan K. Wallace
Manufacturing Systems Integration Division
NIST (027)
_________________________________________________________________
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/OntologySummit2008/
Community Wiki:
http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2008
Community Portal: http://ontolog.cim3.net/ (028)
_________________________________________________________________
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/OntologySummit2008/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2008
Community Portal: http://ontolog.cim3.net/ (029)
|