Re: the necessity of describing responses in-band

>> As for custom extensions, we had to cover (in short):
>> - C# dictionary / Java map data structures (formally it's key-value pairs
>> collection, but key is unique) - this is actually not covered natively by
>> RDF itself, we hade our own structure here
>What did this custom structure look like? How did you express it and
>consequently map it to C# and Java? Do you have code examples? I feel
>like this is something that would be useful to have in a public
>repository on https://github.com/HydraCG/.
The structure was quite simple - each key-value pair is mapped to a blank 
with two predicates, one for key, one for value. All blanks were values of 
same relation. As for the mapping, we used RomanticWeb 
(http://romanticweb.net/) in C# which allows to map strongly typed data 
contracts to RDF and enabling developers to read/write/query RDF without 
need to know lot of the details in this turf.

>> - multi-values for grid based views
>> - single-values for key-value pair views
>> - named individuals (i.e. enumerated values) for dropdowns
>Examples on how each of these looks like in both your custom Hydra
>extensions and how it maps to C# and Java would be very valuable.
We had separate relations on supported property pointing to that. I might 
not be the best way. From the time perspective I'm more into extending the 
expected/returned constructs.

>> - other than RDF expected/returned values (i.e. API allowed to have an 
>> URI
>> for resource's label accepting ... string - this doesn't fit to hydra's
>> class expectation)
>So Hydra needs to support simple types, then, yes?
I hope Hydra to support both RDF and non-RDF payloads and will sustain a 
balance between hypermedia controls emited within the body and API 
documentation.

>> - property value change event (we had to know whether the value changed 
>> to
>> send back a CQRS command to the server).
>This was pushed from the server? If so, how? And if not, could you
>please elaborate?
Yes, everything was created on the server side. With the RomanticWeb we hade 
much easier task as server could use this framework and reflection to 
generate everything that was necessary, including automatic SPARQL Construct 
queries that transformed read model structures into write model commands. In 
most cases commands required a subset of properties of the read model thus 
it was conceptually easy (implementation indeed required some advanced 
coding).

>> From all of these sorting was the easiest - this required rdf lists which
>> are the simplest to identify as there is a separate class for that!
>Great. I hope you can provide more detail. :)
RDF list could be exposed as operation's expected/returned value, this we 
knew that the result is a sortable list. It is also possible to use few 
simple OWL constructs to mimic C#/Java generic list saying that given RDF 
list contains values only of a given type. We actually didn't need that but 
I use this approach in my latest creation devoted to Hydra 
(https://github.com/alien-mcl/URSA)

Hope it helps

Regards

Karol

-- 
Asbjørn Ulsberg           -=|=-        asbjorn@ulsberg.no
«He's a loathsome offensive brute, yet I can't look away»

Received on Thursday, 8 October 2015 18:11:30 UTC