ToolConsumer Profile in the ToolProxy is just string about basiclti-util-java HOT 7 CLOSED

Would you mind providing context on what you're trying to do and what problem it's causing?

from basiclti-util-java.

If I understand the specification right, LTI v2.0 (http://www.imsglobal.org/lti/ltiv2p0/uml/purl.imsglobal.org/vocab/lti/v2/lti/index.html#ToolProxy)
The ToolProxy is an aggregation of several objects ToolConsumerProfile is one of them. I think it would be useful to provide that as an object that i can get from the ToolProxy if I need to look up capability_offered and service_offered in the ToolConsumerProfile (http://www.imsglobal.org/lti/ltiv2p0/uml/purl.imsglobal.org/vocab/lti/v2/lti/index.html#ToolConsumerProfile)

from basiclti-util-java.

Hello @petabyte, and thank you for your interest!
The LTI2 objects package was very rushed & could definitely be more thought-out.
As far as ToolProxy.java is concerned, I've only considered using the default context provided by IMS which is hosted here. If you look at that definition of the ToolProxy context, the lti_consumer_profile type is declared as a json-ld @id, which correlates to a Java String. This will instruct anyone serializing a ToolProxy using the default ToolProxy context to do so as:

{
  "@context":"http://purl.imsglobal.org/ctx/lti/v2/ToolProxy/",
  ...
  "tool_consumer_profile":"{iri_of_tool_consumer}",
  ...
}

If the tool_consumer_profile field were the Java type ToolConsumer, de-serialization would fail for anyone using the default context.

from basiclti-util-java.

Ok got that, but will this be change to the right type?

from basiclti-util-java.

I'm not sure I understand what you want to be changed, for people using the default context, the tool_consumer_profile field will be marshaled as a JSON String, which corresponds to the Java String type, not a ToolConsumer

from basiclti-util-java.

So if i want to do a look up on any properties of the ToolConsumerProfile, I will need to follow the IRI via the link then parse the json to the ToolConsumerProfile object ?
I was a little bit confused that it was of type JsonNode (not String) in ToolProxy and without looking in to the json-ld context I was expecting that it was ToolConsumerProfile not an IRI of the tool consumer. (Maybe because this how it was generated)
Just want to make it easier to get ToolConsumerProfile properties from the ToolProxy if needed like capability_offered and service_offered in the ToolProvider side.

from basiclti-util-java.

I'm not sure why the default context provided by IMS has the tool_profile as a full ToolProfile, and the tool_consumer_profile is just an id, but that's just how it's defined:

...
tool_consumer_profile: {
  @id: "lti:tool_consumer_profile",
  @type: "@id"
},
tool_profile: "lti:tool_profile",
...

As a tool provider, you'll only create and register a tool proxy after retrieving a tool consumer's profile. How you store the consumer profile for later retrieval is an application-specific problem, and I imagine it will be different for every implementer. The point of the lti2 objects package is simply to provide the means for clients to serialize/deserialize these objects into JSON for people using the default context.

from basiclti-util-java.