[#72] added service for single entity

[jnguyenx]

I'm not sure about the expected output, can you please have a look at the unit test?

[julesjacobsen]

This is a common pattern using the CurieUtil - might be worth providing a toIriString() method?

[julesjacobsen]

But you're passing the entity into the ClassMatcher via the matchEntity() method so you have the curieUtil accessible from you in there and don't need to do it here.

[jnguyenx]

You mean passing the CurieUtil as a parameter of matchEntity()?

I'm wondering if the ClassMatcher should have a CurieUtil in the constructor, what do you think?

[julesjacobsen]

Ahh, no sorry - I'm mistaken. The curieUtil is used internally within the BMKnowledgebase, but is not accessible from it. Providing the ClassMatcher with the curieUtil and bmKnowledgeBase in the constructor would solve this. Then you can move

String resolveEntity = curieUtil.getIri(entity).orElse(entity); 

into the ClassMatcher.

I just wonder to what extent we need to hide the CurieUtil inside the BMKnowledgeBase - presumably we're always going to use the OWLAPI and the CurieUtil in the BMKnowledgeBase? If that's the case and these are going to be required externally to query the BMKnowledgeBase, then it should expose them so they can be used, or provide methods like:

public String resolveIri(String entity)
    return curieUtil.getIri(entity).orElse(entity); 

[jnguyenx]

Yep I was also leaning towards that solution, I'll make that change in my PR!

Thanks!

[julesjacobsen]

I meant to add the resolveIri() method to the BMKnowledgeBase interface, in case I wasn't clear - which I wasn't!

[cmungall]

My intent was to use the curieUtil when constructing the KB, and to use curies internally, obviating the need for multiple classes to know about it. Exposing via services is a good idea, for clients that speak URIs

[jnguyenx]

Okay modified!

[jnguyenx]

@julesjacobsen @cmungall when you have time, can you have a look?