ontology-summit
[Top] [All Lists]

Re: [ontology-summit] [ReusableContent] Partitioning the problem

To: Ontology Summit 2014 discussion <ontology-summit@xxxxxxxxxxxxxxxx>
From: David Price <dprice@xxxxxxxxxxxxxxx>
Date: Fri, 31 Jan 2014 18:02:17 +0000
Message-id: <40A86754-9D14-4A5F-8964-449C4653759E@xxxxxxxxxxxxxxx>
On 31 Jan 2014, at 17:21, Simon Spero wrote:

[On the cognitive aspects, yes and no. See e.g. James et al (2005) for an fMRI based study that covers some of these issues following the Dehane/Cohen VWFA assumption.]

Using some portion of the URI as a human readable identifier is not ideal. For display purposes, there are annotation properties, such as label, as well as the per-language SKOS prefLabel.

Tools like protege have supported annotation properties for display for years.

Display is not the issue.

No special support is needed for SPARQL (e.g. ?bt prefLabel "broader term"@en) .

In enterprise apps, we don't depend on string searches to identify classes and properties - adds performance hit, fragile, no namespace support, doesn't support property paths, etc.

There may be useful syntactic sugar that could be added in the query generator, and some query optimizers may require minor tuning, but the functionality is there.

SKOS ConceptSchemes should provide the same disambiguation for prefLabel that namespaces do for URIs. (Note that the extension of an entity interpreted as a SKOS Concept is distinct from its extension as a class or property).



Nobody I know would introduce SKOS ConceptSchemes into an enterprise app for this purpose. 

Other label values  need not be unambiguous; collisions can be detected at query formulation time.


Hmmm ... make the property and class URIs human-readable and all of the artifice described above is completely redundant.  I'm going to stop talking now and get back to my day job.

Cheers,
David

Simon

James, K. H., James, T. W., Jobard, G., Wong, A. C., & Gauthier, I. (2005). Letter processing in the visual system: Different activation patterns for single letters and strings. Cognitive, Affective, & Behavioral Neuroscience5(4), 452-466.

On Jan 31, 2014 11:12 AM, "Barkmeyer, Edward J" <edward.barkmeyer@xxxxxxxx> wrote:

David Price wrote:

 

 

Hi Hans,

 

For data, artificial URIs are fine.  For classes and properties in an ontology they are not. Even a non-English speaker will have better luck distinguishing PersonOrOrganization vs Organization rather than RDL94950595 vs RDL9459869 when reviewing an ontology or writing SPARQL. Adding properties as labels useful for presentation in a user interface does nothing wrt the issue I raise.

 

 

 

+1!  The function of the ontology is to capture the knowledge of domain experts in a formal language.  It is not useful, even to the knowledge engineer, to use a formal vocabulary of “terms” that suggest nothing to ANY reader.  It is true that members of the Indo-European language community would have a difficult time working with an ontology in which all the terms are in Kanji or Arabic, but that is only equally difficult to working with terms written entirely in Arabic numerals, and in the Kanji or Arabic case at least some knowledge engineers would find it much easier.

 

[I think part of our facility with recognition of terms, even in a foreign language, is a result of a common intellectual/bio-mechanical process of learning to read.  Whether the underlying system is phonetic or ideographic, the text forms have elements that invoke a combination of intellectual processes in recognizing words.  The components of purely numeric symbols have associated intellectual processes that are more distantly related to language.  So the recognition process for digit strings is not intrinsically more difficult; it is just foreign to everyone’s reading experience.

 

(I must admit, the above is utter amateur guesswork.  I have no real knowledge of cognitive science.)]

 

-Ed

 

--

Edward J. Barkmeyer                     Email: edbark@xxxxxxxx

National Institute of Standards & Technology

Systems Integration Division

100 Bureau Drive, Stop 8263             Work:   +1 301-975-3528

Gaithersburg, MD 20899-8263             Mobile: +1 240-672-5800

 

"The opinions expressed above do not reflect consensus of NIST,

 and have not been reviewed by any Government authority."

 

 



_________________________________________________________________
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/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
Community Portal: http://ontolog.cim3.net/wiki/


_________________________________________________________________
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/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014  
Community Portal: http://ontolog.cim3.net/wiki/


_________________________________________________________________
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/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014  
Community Portal: http://ontolog.cim3.net/wiki/     (01)
<Prev in Thread] Current Thread [Next in Thread>