search

Letractively / mmisw

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

want to come up with set of properties that VINE supports to facilitate desired searches #79

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What capability do you want added or improved?

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)?

Other details of your desired capability?
Look at ISO 19135 (relationships between registry entries)

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, IE, etc.), screenshot, etc.)

Original issue reported on code.google.com by caru...@gmail.com on 19 Nov 2008 at 4:57

GoogleCodeExporter commented 9 years ago 
not ISO 19135, but OASIS EBRIM

Original comment by caru...@gmail.com on 19 Nov 2008 at 4:59

GoogleCodeExporter commented 9 years ago

Original comment by caru...@gmail.com on 19 Nov 2008 at 6:03

GoogleCodeExporter commented 9 years ago 
(I'm not sure what the original intend was with this entry. But here is one 
aspect
related with searches.)

Currently, (MMI Portal 1.5.0.alpha14 (20090831104811)), the  search in the Web 
VINE
interface *only* considers individuals (for example, those created as vocabulary
terms by voc2rdf).  Enabling the search for classes and properties is rather
straightforward. However, it is not very clear how the corresponding relations 
are
going to be handled/verified/exploited. For example, given two device 
ontologies,
each having a class for Device, what would be the meaning of the following 
mapping?

  ont1:Device  skos:<some>Match  ont2:Device

As a real example, http://mmisw.org/portal/#http://mmisw.org/ont/ecs/device_map
contains various skos:broadMatch mappings intended to capture the fact that 
certain
specific types of sensors have Sensor (in the second ontology) as a broader 
concept.
Perhaps a better modeling approach would be to make the former subclasses of 
the latter.

General discussion for a consensus is required.  Feedback welcome!

Original comment by caru...@gmail.com on 31 Aug 2009 at 10:30

GoogleCodeExporter commented 9 years ago 
I think the new SKOS concept matches are good enough for most basic uses; and 
any specific relationships needed for particular kinds of searches can and 
should be created (for now) by the particular user community who plan to build 
tools around those searches. (In other words, let the community use the 
semantic relations to do this job, don't build it into our code.)  

This will be especially effective when issue 100/issue 285 get implemented.  

A general ability to adapt a mapping interface to any kind of properties (not 
just SKOS properties) would be pretty slick. But is a different topic then 
we've initially addressed.  (Actually, I think this may have been driven 
originally by the desire to easily add mapping relations to the VINE interface. 
 But this request deserves a separate issue.)

So I recommend closing this as WontFix.

Original comment by jbgrayb...@mindspring.com on 22 Aug 2014 at 5:26