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

[Ali SH <asaegyn+out@xxxxxxxxx>]

Hi Kingsley,

I think you've fundamentally misinterpreted what I wrote.

I certainly wouldn't and certainly didn't claim that these problems that I've encountered are universal. Conversely, they actually are problems, since real people and real companies have encountered them! I didn't think I'd have to write something as basic as this, but obviously, I acknowledge that the experiences are anecdotal, though it seems it's one that David Price ran into as well.

Anyway, as Amanda noted in her response, appropriate tooling would mitigate many of these concerns, but such toold don't always exist, aren't necessarily readily available, and the pointed-haired bosses at various companies might not want to deploy them... The context in which this arose for me was working with a large multinational that had developed its own ontology and triple store, and I was working with their developers to deploy SPARQL queries via Java. From my point of view, their toolset was inappropriate, their workflows were inadequate, but I was not in a position to effect change on these fronts. Sometimes you have to work with the lemons you have, not the ones you want.

And I really didn't expect that I'd need to write this, but since it appears that these somehow didn't come through in my message, let me be embarassingly obvious: I thought I was very clear that I don't think human readable ids are necessarily the answer, but I can sympathize with their use. Obviously a URI which uses an English NL shortcut isn't as accessible to someone who doesn't speak the language... The analogy is to writing software and using somewhat suggestive function, variable or class or object names. It should go without saying, but I'll be extra pedantic, yes obviously, there are serious drawbacks... Such names are limited by being language specific, can invoke unintended semantics and can consequently be misused. And yes, in an ideal world with appropriate tooling and developer time, they're not even needed.

In a world where a company will not devote time to develop (or even deploy) tools outside of their existing toolset, it seems like a pragmatic compromise at times to use semi-human readable names as appropriate for the given culture. To be painfully clear again, this is not ideal, and has a whole slew of problems, but it is an understandable development and points more than anything to the lack of well developed tools and integration of ontology based software engineering practices.

To deny the above is to deny the painful reality that many (though obviously not all!) people experience in this imperfect world of ours. I don't see how we benefit by pretending that these problems don't exist.

Best,
Ali

On Sun, Feb 2, 2014 at 4:34 PM, Kingsley Idehen <kidehen@xxxxxxxxxxxxxx> wrote:

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

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