search

graybeal / ont

org.mmisw.ont
0 stars 0 forks source link

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

Open graybeal opened 9 years ago

graybeal commented 9 years ago

From caru...@gmail.com on November 19, 2008 08:57:38

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: http://code.google.com/p/mmisw/issues/detail?id=79

graybeal commented 9 years ago

From caru...@gmail.com on November 19, 2008 08:59:29

not ISO 19135, but OASIS EBRIM

graybeal commented 9 years ago

From caru...@gmail.com on November 19, 2008 10:03:29

Labels: vine

graybeal commented 9 years ago

From caru...@gmail.com on August 31, 2009 15:30:13

(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: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!

Status: NeedMoreInfo
Cc: bermud grayb...@marinemetadata.org
Labels: -Priority-Medium Priority-High

graybeal commented 9 years ago

From jbgrayb...@mindspring.com on August 22, 2014 10:26:40

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.