Letractively / mmisw

Automatically exported from code.google.com/p/mmisw
0 stars 0 forks source link

strange case when mapping to http://mmisw.org/ont/cf #311

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Map a vocabulary to CF vocabulary at http://mmisw.org/ont/cf
2. Register (close) mapping
3. Re-open mapping ontology and go to Content section

What is the expected output/behavior?
List of vocabularies to map should include original and CF as A and B.

What do you see instead?
 Instead, program went off and opened http://mmisw.org/ont/cf/parameter as vocabulary C.  Clicking on vocabulary B and searching for all produces "Nothing found" (see attached ending '14'); clicking on vocabulary C and searching for all produces the list of terms expected for CF, but they are associated with vocabulary B in the UI (see attached#2 ending '51')

What version of the product are you using? (You can see the version in the
lower left corner of the ORR page.)

ORR Portal 2.0.42.beta (201302221022)  (it's in the lower *middle* of the page 
now)

If relevant, please attach the file you were working on (for
submission of new ontology, text for import in the vocabulary interface,
etc.).

If possible and relevant, please provide a screen shot showing the problem.

Please provide information about your browser and version (Firefox, Safari,
Chrome, IE, etc.), operating system, etc.

Original issue reported on code.google.com by grayb...@marinemetadata.org on 1 Apr 2013 at 12:22

Attachments:

GoogleCodeExporter commented 9 years ago
I think I know what might have happened in this case:

The ontology itself , that is, the uri "http://mmisw.org/ont/cf/parameter" 
shows up in the list of candidate terms to be mapped, and so the tool is 
allowing to map against it.  But this is the *ontology* itself, not the URI for 
the "parameter" concept, which is "http://mmisw.org/ont/cf/parameter/parameter" 
 as can be seen in the attached screenshot (the "A:/parameter" entry).  The 
screenshot also shows the ontology URI as the first entry in the list.

Will have to look more carefully but I think the solution is to not include the 
ontology itself in the list of terms that can be mapped (or have some 
additional handling if that's really needed).

Original comment by caru...@gmail.com on 2 Apr 2013 at 3:55

GoogleCodeExporter commented 9 years ago
forgot screenshot

Original comment by caru...@gmail.com on 2 Apr 2013 at 3:57

Attachments:

GoogleCodeExporter commented 9 years ago
A few thoughts.

I'm not sure this is exactly right. "The ontology itself" is not really 
../ont/cf, that is the authority. Something may have defined that as the 
ontology, but that would be wrong, it seems to me. (Because I could have 
another ontology called ../ont/cf/relations, and then where would we be if we 
called ../ont/cf the ontology itself in that case?)  I would have said the 
ontology itself is ../ont/cf/parameter.

On the other hand, there is also a class by that name, right?  So that is a bit 
of a faux pas -- when we resolve ../ont/cf/parameter, we resolve to the 
ontology, not to the class.  Awkward.

I note there is an advantage to having the ontology available in the way it is 
available in the list of terms -- by clicking on the drop-down, you can see all 
the attributes, which is helpful. 

Original comment by john.gra...@marinexplore.com on 2 Apr 2013 at 7:16

GoogleCodeExporter commented 9 years ago
My initial observations were not comprehensively explained but it seems you 
misread part of what I said.

I said: 
  - "The ontology itself , that is, the uri "http://mmisw.org/ont/cf/parameter" ...

You say:
    - "The ontology itself" is not really ../ont/cf, that is the authority

Nowhere I said that  ../ont/cf is "The ontology itself."   Surely the confusion 
comes from the way the list of mapped ontologies appear *after* the mapping 
ontology has been registered. Note that my screenshot is captured right after 
the CF ontology is selected for mappings (with no mappings at all entered yet). 
I didn't make clear that my observations were mainly based on my attempt to 
reproduce the problem and in reference to my attached screenshot. In you test 
case, the fact that ../ont/cf  appears as a mapped ontology (which is not) is 
because, at the time of entering the mappings, the entry 
http://mmisw.org/ont/cf/parameter was made available for mappings and then it 
was mapped. The current logic in the code when rendering a registered mapping 
ontology is to extract the common prefixes of the mapped terms to compose the 
list of mapping ontologies. My initial diagnostics was that making the ontology 
itself available as a mappable term seems to have caused the whole strange case.

You also say:
   - I would have said the ontology itself is ../ont/cf/parameter.

this is correct and that's what I said from the beginning.

You also say:
  - On the other hand, there is also a class by that name, right?

Incorrect. No class is created with the http://mmisw.org/ont/cf/parameter URI.  
This URI is only used for the ontology itself. 

Now, I think you are referring to a related concept captured in the ontology. 
As I said:
  - ... the URI for the "parameter" concept, which is "http://mmisw.org/ont/cf/parameter/parameter"  as can be seen in the attached screenshot (the "A:/parameter" entry).   
This A:/parameter is an instance of 
http://mmisw.org/ont/cf/parameter/Standard_Name, which is a subclass of 
http://www.w3.org/2004/02/skos/core#Concept

As a summary, having the ontology itself appear as available for mappings is 
the piece that needs examination. A simple solution (but I haven't yet reviewed 
the actual impact on the code) would be to filter it out so no mappings can be 
created against the ontology itself using the Vine interface. The advantage 
that you mention can be got by just opening the ontology in a separate window, 
but if it really needs to be part of the Vine interface, then it could be made 
available outside of the mapping area.

Original comment by caru...@gmail.com on 9 Apr 2013 at 1:47