ontology-summit
[Top] [All Lists]

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

To: ontology-summit@xxxxxxxxxxxxxxxx
From: Kingsley Idehen <kidehen@xxxxxxxxxxxxxx>
Date: Sun, 02 Feb 2014 16:34:00 -0500
Message-id: <52EEB9C8.7060905@xxxxxxxxxxxxxx>
On 2/1/14 6:01 PM, Ali SH wrote:
Dear Amanda, Kingsley and David,

On Sat, Feb 1, 2014 at 3:04 PM, Amanda Vizedom <amanda.vizedom@xxxxxxxxx> wrote:

Your proposed solution - as best I can tell, to choose one target set of humans and make the (meant for machine consumption) URIs (or even names!) understandable to them, while ignoring the polysemy-tolerant, built-for-natural-language labeling features of the ontology language, is inherently antithetical to reuse (including use over time). 

I don't believe David is saying this. I sympathize with his conundrum. He isn't saying that the human readable URI's are intended to exactly denote the semantics of what is represented in the ontology.

Yes, and those that disagree are saying: you don't use identifiers for that purpose. That isn't what denotation is supposed to address.

You describe what's denoted by an identifier which is how make the referent of said identifier meaningful.

Rather, that people who are using these URI's to build applications, in the form of code or queries riding on top of the ontologies have more difficulty if they are anchored in a completely opaque naming system.

That's because the industry has been doing it wrong for a very long time. The reason why its taken this long to detangle boils down to the proliferation of silos at every level in the computing stack from the host operating system to actual end-user applications. It's a mess, to put things mildly!


His example with the SPARQL queries is spot on, and something I've run into as well.

He example is utterly subjective.

I've sold a lot of SPARQL into enterprises that's being used on par with SQL and I can tell you for certain that a search on labels is where matters start, via full text patterns. The problem with SPARQL is that this aspect isn't standardized, that's all.

select distinct ?s
where {?s
           ?p ?o.
           ?o
          bif:contains "Some text pattern" } .

Is typical.

If not using SPARQL, then a lookup on labels is typical.

I am not speculating, I am telling you what happens in the enterprise or anywhere else.

When queries are written using completely opaque URI's, the task of maintaining, debugging and updating them is significantly complicated, leading to more opportunities for errors.

Subjectively inaccurate, sorry !


If I've understood David's point correctly -- the same way that software developers employ useful NL analogues for the variable / class names to make the code more readable, ontologists should consider using similarly somewhat accessible labels.

Programmers are part of the entire mess. This whole matter is too lob sided, and now we have programmers dominating discourse for which they are intrinsically ill equipped. This is akin to leaving the domains of civil engineering and architecture to bricklayers, so to speak, only in the computing industry has this form of dysfunctionality failed to raise the obvious concerns it deserves.

As someone who has had to debug SPARQL queries written using esoteric naming systems, the fact that those terms had "pref-labels" in a multitude of language did not help one iota.

What system are you using? Please don't treat the system you are using as being universal. One size doesn't fit all.

I had to constantly look up what the term referred, and it increased the debugging time by perhaps an order of magnitude.

See my comment above.


As I suggested in a previous email, there's a balance to be struck, since a pure linguistic ID can indeed lead to unintended or hopeful semantics. But something like:

human.n.05

Meaning what to a Chinese speaker? Would you like the same in Chinese?

is readable to a human,

Certain humans. Not all humans.

and also clearly not intended to be interpreted naiively.

See my comment above.

One can still use labels (a la SKOS) to display different terms (e.g. homme) when presenting such concepts to SME's or other targeted audiences, but when one is building applications using the ontology identifiers, having something like human.n.05 vs RD54383 is much easier to follow the logic and debug.

Sorry, simply wrong. Too subjective.


As Simon and Ed alluded to, our brains have developed ways for holding various referents in our heads.

Subject to where we come from and what languages we speak.

We detect and utilize name patterns based on the shape and length of words.

Yes, but that isn't the point you are making. You are deciding that this all starts from the point that works for you, and then everyone else coalesces around that. How about inverting that pattern? Will you still play ball?

When the naming system follows an esoteric style, we don't have the ability to use these facilities, leading to potential errors and slower work.

Subjective!


Kingsley


--


(•`'·.¸(`'·.¸(•)¸.·'´)¸.·'´•) .,.,


 
_________________________________________________________________
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/ 


-- 

Regards,

Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


_________________________________________________________________
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>