Re: Link relation type to link to discover LDP

Hi Greg,

> However, I don’t find any reference to hydra:variableRepresentation in the TPF spec. I thought that would mean that it uses the BasicRepresentation, but the description of the syntactic rules in the TPF spec sound more like the ExplicitRepresentation (it includes type and language information, for example). But the Hydra spec’s text regarding both BasicRepresentation  and ExplicitRepresentation is different from the TPF rules.

Yes, you're right. I forgot to update this after BasicRepresentation and ExplicitRepresentation were added to the Core.

> For example, the Hydra representation rules don't seem to talk at all about how to encode variables, while the TPF spec gives the option of an empty string, or a SPARQL-style value starting with “?”.

I wonder if we could add this to the Hydra Core Vocabulary's ExplicitRepresentation
(even though variables are not in RDF 1.1)?

> Also, as a separate issue, both specs might do well to discuss RDF 1.1 semantics where literals always have a datatype. If you want to continue supporting syntactic forms without the ^^ syntax for xsd:strings, that should be mentioned explicitly.

+1

> Similarly, the rules for literals with languages should explicitly ignore the rdf:langString datatype, as this will be implied by the @lang syntax.

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?

> 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.

> 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).

> 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.

> 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.

Best,

Ruben

Received on Tuesday, 16 June 2015 20:23:01 UTC