Re: Few concepts

>Why? That purely depends on how you define the properties. Following your 
>line of thought, couldn't you make the same argument about 
>rdfs:range/domain?
Yes, you're right. I didn't think of it. But alternative solution with 
creating subclasses with something special added only for documentation 
purposes is ugly (see later)

>> - it is possible to provide various
>> criterias, i.e.: ofClass for complete RDF statements, ofDataType for
>> single literals or ofMediaType for non-RDF resources
>The former two are expressible today, the latter is indeed tricky at the 
>moment.
How? If I put i.e. xsd:string as a value of the hydra:expects I'll 
automatically implicitely state 'xsd:string a hydra:Class'. I think this was 
legal only in OWL Full, which I assume it's not what we want.

>> - it is possible to
>> provide additional contextual description of the expected/returned
>> funcional meaning i.e. api documentation can provide a textual human
>> readable description of what is expected/returned without binding that
>> description to the actual class or resource itself
>You can do that today as well by creating a dedicated subclass to which you 
>associate those additional descriptions.
But how ugly is that. You could end up with instances of type 
my:ProductApiDescriptionFake instead of my:Product as clieant was told to do 
so. I don't think that from business logic point of view this data pollution 
is what you want in your data set.

>> an ontology can provide cardinality
>> constraints and ignoring them in the hypermedia controls or api
>> documentation will cause the client to fail when sending incorrect data
>> by design; from UI point of view it is also crucial to have these
>> details to generate a valid view - it is possible to provide additional
>> logical constrains; while RDF lists are pretty well supported, C#
>> dictionary/Java map data structures are somehow ignored while still
>> quite heavily used - it is possible to provide list of allowed values
>> for enumeration scenarios
>You mentioned dictionaries/maps a few times by now (also in other threads).
>How do you see them to be expressed in RDF? Wouldn't they simply be a
>resource (subject) with multiple property/object pairs?
Well, I'm a practicioner - we use these data structures everyday when 
developing software thus I'd love to see some support for them.
Expressing it in the RDF is not that difficult (other thing would be on how 
to express such a constrain in OWL). Indeed it could end up with something 
like this:
some:resource has:mapEntry [ has:key "key"; has:value "value" ], [ has:key 
"key2"; has:valye "value" ].
Other thing is on how to tell the client that sending something that could 
violate has:key uniquness will end up with failure.

>> 2. Collections - while discussion about these is still unfinished, let me
>> share my point of view on this subject.
>>> From data processing point of view, I don't really care whether it is a
>> collection or other data structure - I do care on what I can do with it. 
>> I
>> believe that templated links and few hydra:freetextQuery like predicates
>> could completely describe basic operations on data structures (i.e.
>> imaginary hydra:take for limit, hydra:offset for offset, hydra:orderBy 
>> for
>> ordering - this one will need some more attention). Additional details 
>> like
>> first/last page could come in handy for the client, but I think it's more
>> important to know how and what to do than what am I actually working on.
>> This approach could also cover dictionaries.
>> Also with this approach I don't have to expose to the outside world my
>> internal implementation - I don't have to say that given resource is
>> actually a collection. Otherwise client could imply on something I 
>> wouldn't
>> like it to imply.
>Please don't confuse hydra:Collection with a Java Collection or something 
>similar. A Hydra Collection is not tied to those implementations in any 
>way... but obviously they are >similar.
I know that. And it was not my intent to confuse them. I was thinking about 
use cases of a collection and a collection that is allowed to be paged, but 
I forgot about hydra:Collection and hydra:PagedCollection exist. Still I'm 
not sure on how to express these hypermedia controls in the API 
documentation?

>> 3. HTTP - while the HTTP spec allows client to discover stuff on-the-fly, 
>> I
>> think that it could be nice to have some more details in API 
>> documentation
>> in advance. I don't want client application with UI controlled by human 
>> to
>> wait ages for the background tasks to discover that given request is 
>> allowed
>> with these headers or that method or whatever HTTP constraints we can
>> imagine. I'd prefer to have these details downloaded in the 
>> initialization
>> stage, setup an application and limit the UI and user himself from doing
>> something that won't work by design. Application will have to poke
>> exceptional situations, indeed and additional HTTP/Hydra details 
>> discoverd
>> later will help recovering from such situations, but developing an UI
>> application without precomputational stage won't work.
>I agree with all but the last sentence. That's also the reason why 
>hydra:ApiDocumentation has been part of the vocabulary from the very 
>beginning.
But hydra:ApiDocumentation is less expressive than several hypemedia 
constructs. Collections mentioned above are an example. Or I just dont know 
how to do this :)

>> 4. Reasoners - I don't expect the client (i.e. browser with JavaScript on
>> board) to have a reasoner.
>Agreed - depending on what exactly you classify as a reasoner.
Something that can infer types or detect conflicts/violations.

>> Phew - I think I covered everything for now that was a salt in my eye.
>> Please feel free to elaborate on these thoughts.
>Thanks a lot for writing this down. I think we are mostly on the same page.
>I look forward to your input in the discussions we will have about each of
>those points while fleshing out the design of the vocabulary.

I look forward to the discussion as well.

Best,

Karol

Received on Thursday, 8 October 2015 21:14:40 UTC