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

[John McClure <jmcclure@xxxxxxxxxxxxxx>]

+1 - your explanation is why I say the normative definition should be named in its author's native language, but there's much to argue for English as a practical necessity be the normative language.
/jmc

On 2/2/2014 5:30 AM, David Price wrote:

On 1 Feb 2014, at 23:59, Amanda Vizedom wrote:

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

In my experience, that just isn't true. 

In our experience, that is 100 percent true :-)  The model+SPARQL is so complex that we have enough trouble debugging even using human-readable URIs. No way we'd meet our delivery deadlines if we made it harder - so we don't, and won't. 

In this thread, there's lots of "the tool should do x" and "we can dereference" and "why don't you just add search of labels into your SPARQL", etc.

My response is that the entire point of this conversation was to discuss characteristics that make ontologies more reusable. Imposing expectations on how people will use the ontologies or imposing your own expectations on the tooling they must use is clearly a barrier to reuse.  So, if your goal is to create ontologies with the widest possible audience of potential re-users ... then use human-readable URIs. It's just that simple. People who don't care about them can ignore them and people who do can use them.

Ontology developers can, of course, decide if they want to remove an entire class of use cases/users/tools from their audience or not. For example, the15926 RDL URI strategy is one that makes none of those classes or properties directly usable in the kind of app we're development. We do, of course, relate our ontology under 15926 classes using seeReferenceData annotations so it's possible for software developers to see the relationship in case it's useful.

FWIW I was disappointed when the 15926 RDL decisions were being made 10+ years ago, but I was a standards maker then.  Matthew's explanation of how/why the 15926 community made those decisions is also what I remember ... but some of us did complain about that decision even back then because it was clear to me it would come back to bite someone eventually.  I just never expected that someone to be me :-)

Cheers,

David

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