- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 21 Jul 2014 20:49:55 +0200
- To: <public-hydra@w3.org>
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 @markuslanthaler
Received on Monday, 21 July 2014 18:50:37 UTC