W3C home > Mailing lists > Public > public-hydra@w3.org > July 2014

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

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Mon, 21 Jul 2014 20:49:55 +0200
To: <public-hydra@w3.org>
Message-ID: <01a801cfa514$998c2020$cca46060$@gmx.net>
On 17 Jul 2014 at 10:23, Tomasz Pluskiewicz wrote:
> On Thu, Jul 17, 2014 at 9:54 AM, Ruben Verborgh wrote:
>>> Additionally, we will add a flag, i.e., a property whose value is a boolean,
>>> hydra:expandedRepresentation to IriTemplateMapping
>> Instead of the flag, I would propose an extensible attribute:
>>     _: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.

>> This allows to define other types if necessary for other use cases;
>> right now, with the boolean attribute, we'd really enforce very specific
>> interfaces.

Right. This helps to reduce variability and thus implementation complexity. 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? What sort of other hydra:expandedRepresentations do you have in mind? Right now, I can't think of any.

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

>>>  - datatypes are added using ^ (just one) and then the URL without
>>>    enclosing it in <>
>> I strongly suggested, as Gregg has said, to stick to two of then: ^^.
>> Just because of convention in Turtle (They're the ones
>> that should have decided to only use one.)

Yep, that ship unfortunately has already sailed a long time ago. I don't have a strong opinion about this but we have to make it very clear that this serialization is *not* Turtle.

>>> Regarding encoding of values I think we should be as strict and simple
>>> as possible and reuse standards:
>>> 1. Accept only absolute URIs (no angle brackets)

Yep, that's the idea. RDF, the data model, doesn't support relative URLs.

>>> 2. Take any value as-is and apply standard encoding
>> That doesn't allow us to differentiate when necessary.
>> Note that there might be several ways to encode values;
>> one might be simple as you say, the other might be more complex.

I think with "standard encoding" Tomasz meant URL encoding the expanded value. Right?

>>> And I'm not sure that language tags and typed literals are even
>>> necessary here.

In most cases they aren't, you are right. That's why we only include them if the server requests them by setting the hydra:expandedRepresentation to true.

>>> I would personally be using an operation with some RDF
>>> body if I wanted to transmit such payload.
>> Then you exclude GET requests.
> I feel like these decisions are a little bit out of scope for Hydra
> itself. Is there no such proposal elsewhere? Assuming there is no
> established way for URL encoding RDF values I would agree with what has
> been decided. Use Turtle as it's the most text friendly format. If we
> decide to keep language tags and typed literals that's fine. The value
> could then simply be a turtle-formatted RDF object. Even with the angle
> brackets to be consistent. Though I would not allow prefixed URIs.

Ruben answered all of this in a separate mail already so I'm not going to repeat it hee.

> However your initial question was more about how Hydra should define
> what is the parameter and not how to put it there. I think this should
> be the focus. Please see my other email [1].

Of course we also need to specify that. It is, however, an orthogonal aspect which can be dealt with separately. Let's try to focus on a single issue at a time.

> [1] http://lists.w3.org/Archives/Public/public-hydra/2014Jul/0094.html

Markus Lanthaler
Received on Monday, 21 July 2014 18:50:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:42 UTC