Testing restrictions

[GoogleCodeExporter]

What capability do you want added or improved?
It seems that vocabularies with the authority abbreviation of "testing" or
"mmitest" should have restrictions placed upon them (e.g., not available
for mapping).  As one example, it seems problematic to have mapping
dependencies built on test ontologies that users may just be throwing on
the ORR to figure out how to use the portal and its tools.  These
ontologies may have no meaning whatsoever and false mappings would actually
diminish the capabilities that MMI is trying to provide through the ORR. 
Users may learn not to trust the ORR. Related to this, what happens when a
user edits their ontology and mappings have already been made using the
earlier version.  Do the mappings get updated, too?  Or, will those earlier
mappings become obsolete?  If the mappings become obsolete, how will users
know?

Where do you want this capability to be accessible?

What sort of input/command mechanism do you want?

What is the desired output (content, format, location)?
Restrictions placed on test ontologies.  
Revisions to mappings (maybe just an automated email to people who have
used mappings that have become obsolete or some automatic updates to the
mappings themselves employing reasoner capabilities)

Other details of your desired capability?

What version of the product are you using?

Please provide any additional information below (particular ontology/ies,
text contents of vocabulary (voc2rdf), operating system, browser/version
(Firefox, Safari, Chrome, IE, etc.), screenshot, etc.)

Original issue reported on code.google.com by steph_wa...@consolidated.net on 9 Apr 2010 at 8:14

[GoogleCodeExporter]

Good points!

A couple of comments.

Re dependent mappings: I agree. A restriction would be that the mapping 
ontology be
also 'testing' when any of the interlinked vocabularies is 'testing.'

(A note from a previous email: there is very little support for the "testing" 
status,
for example it does not apply for re-hosted entries.)

Re new versions of referred vocabularies in existing mappings: The mapper 
component
(VINE) only displays and allows to map the *unversioned* URIs of the 
corresponding
terms. In that sense, dependent mappings will continue to be (at least 
syntactically)
valid. Of course, there would remain the question of its semantic validity upon 
new
versions of the terms. Also there are other factors to consider regarding 
potential
invalidity. For example, what should be the precise effect of deprecating a
particular term (see issue #233)? Are the dependent mappings to be deprecated as
well? (The latter is particularly tricky as you may notice: we could 
automatically
deprecate the mappings *registered* at ORR; but what about the others out 
there?)

In general, I think the trustfulness of the ORR is going to rely on these and 
surely
many other factors, including aspects that perhaps we could not even capture in 
the
underlying semantic infrastructure. Let's keep in mind that, beyond the 
technical
capabilities per se, disagreements among human experts about particular pieces 
of
semantic content is likely to (continue to) happen (at least in the foreseeable
future, IMHO).

Again, very good points. I'm cc-ing some others to foster further discussion.

Original comment by caru...@gmail.com on 9 Apr 2010 at 10:32

• Changed state: Accepted
• Added labels: mmiorr