Re: Link relation type to link to discover LDP

On Jun 16, 2015, at 1:22 PM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> 
> But are there cases then when rdf:langString can be specified explicitly?
> I.e., doesn't it just have a @lang instead of a type?

I suppose, but that seems like it would be a weird corner case that no one should be touching.

> 
>> OK. So to simplify my thought experiment, let’s say that I create an API that’s identical to TPF except in requiring that variables use the ?var form instead of an empty string. That doesn’t seem to conflict with the BasicRepresentation/ExplicitRepresentation rules, but still makes the API differ from TPF.
> 
> Alright, that case is indeed underspecified.
> You would need to use a different hydra:variableRepresentation though,
> in the (currently unspecified) assumption that ExplicitRepresentation allows both empty and ?x notations.

But you still think that using a custom variable representation should be the one and only way that a client should identify the sort of API that is being described? Do you believe that no two APIs should ever share the same set of parameters and variable representation rules? Because this is exactly the sort of case that causes duck typing to fail.


>> Basically, it seems like you want tools to identify TPF APIs simply by their use of hydra and then by duck-typing based on the API parameters instead of just making it explicit.
> 
> Mmm not entirely.
> The interface is saying explicitly "you can search by triple pattern",
> and the syntax is communicated by hydra:variableRepresentation
> (if we fix the variable things, which I will).

But "you can search by triple pattern” doesn’t imply everything that TPF *is*. Otherwise you wouldn’t need a 3500 word spec to define it. If self-describing APIs are the point here, I see a lot of problems with using the current duck-typing approach, and all of them are addressed by adding explicit typing information.


>> Is there a reason to *not* add a type triple here? Simply to avoid having to iterate over all of the API parameter mappings to verify that it’s a TPF API, explicit typing would seem like a win.
> 
> I just think that self-descriptiveness is more important.
> I.e., the information "<#interface> rdf:type :TPF" requires clients to know and understand the TPF spec.
> The information "you can search by triple pattern" is much more generically expressed with Core.

I’m suggesting that clients will need to understand TPF anyway, if they intend to use the API successfully. Unless, as I questioned above, you are suggesting that no other API should ever use the same parameters and encoding rules as TPF. In that case, however, Hydra doesn’t seem like a very flexible system.


>> Nothing in the hydra:search example in the TPF spec indicates to me that a client would be able to know what data it should expect back.
> 
> Hmm, the spec is indeed vague about this.
> Discussions we had on the mailing list about search
> seemed to imply that hydra:search filters a collection by the given properties.
> 
>> Is the intent here that those are the only two options? The hydra spec says, "The serialization of an IriTemplate's variables can be described by setting the variableRepresentation property to BasicRepresentation or ExplicitRepresentation.”
> 
> It's supposed to be an extensible mechanism; both inherit from hydra:VariableRepresentation.
> We should probably rephrase this sentence.
> 
> 
> To summarize, I see the following action points:
> 
> 1) clarify variable syntax of ExplicitRepresentation
> 2) require TPF interfaces to use ExplicitRepresentation
> 3) better describe hydra:search (provided my understanding is correct)
> 4) clarify that other variable representations are possible
> 
> If there is consensus about these points, I'm willing to make pull requests somewhere next week.

That all sounds good, but I’m afraid those are all tangential to my main point which we still seem to disagree about.

thanks,
.greg

Received on Wednesday, 17 June 2015 08:48:56 UTC