RE: Call for consensus on defining IRI template expansion (ISSUE-30)

On 21 Jul 2014 at 12:31, Ruben Verborgh wrote:
>>>>    _:x hydra:valueRepresentation hydra:ExpandedRepresentation.
>>>> with
>>>> 
>>>>    _:x hydra:valueRepresentation hydra:ValueRepresentation.
>>>> being the default.
>> 
>> I could live with that if we can justify that increased complexity.
>
> Note that it's not necessarily more complex; with a boolean flag,
> you have to check whether the argument is true or false. Here, you
> have to check whether it's ExpandedRepresentation or
> ValueRepresentation. Simple string matching in both cases.

If it's a boolean with a default value of false you just need to check for
true. You also know that there will only ever be two ways to do this, not
dozens of them.


>> IMO there are two classes of applications that we have to consider
>> here: RDF-based applications (triple store on the server side etc.)
>> and non-RDF-based (mostly applications that work in the realm of
>> JSON-LD instead of RDF). Is there anything in between which we need
>> to handle?
>
> I think that, as a prerequisite, Hydra should work with existing (REST)
> HTTP interfaces. That is, if a server has decided to encode values in a
> certain way, the description should reflect this; i.e., the application
> should not be updated to allow description.

While it certainly sounds like a sensible prerequisite, I think in practice
it isn't worth the effort. I don't consider being able to describe arbitrary
existing Web APIs with Hydra an important requirement anymore. As soon as
you start describing requests that involve payloads, you will run into lots
of issues that aren't worth the hassle and the required complexity to make
them work IMO.


> So anything in between: well, there's many kinds of RDF-based and
> non-RDF based; it's not just two categories that exactly map to two
> was of parameter handling.

That's exactly the problem. Interoperability is created my eliminating
variability as much as possible. I think this is a low-hanging fruit.


>>>>>  - the datatype xsd:string is always omitted
>>>> 
>>>> SHOULD be omitted, I'd say
>> 
>> Why not MUST? Just for the record, I could also live with MUST NOT.
>> What's a good reason to (not) include it despite a SHOULD (NOT) in
>> the spec?
> 
> It's just a datatype like any other. I would not disallow it for that
> reason.

You are probably right. But then even the SHOULD doesn't make much sense. In
that case, a MAY omit is probably better.



--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 23 July 2014 07:03:22 UTC