- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Sat, 26 Jul 2014 13:51:43 +0200
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-hydra@w3.org
> Shall we use a flag (hydra:expandedRepresentation) to switch to "expanded > representation" or should this be an extensible attribute > (hydra:valueRepresentation)? +1 for valueRepresentation with non-boolean. I also just like the modeling better. By nature, it is not a boolean like "writeable"; it is rather a more complex thing for which many answers exist. The fact that we just chose two of those answers, doesn't mean the value suddenly becomes a boolean. > Shall we use two ^ when adding the type or like Turtle two ^ > ------------------------- > Markus: IMO one ^ is enough. Actually, I would prefer another character such > as $ as it makes it clearer that the serialization is *not* Turtle. +0.5 for two hats ^^ In any case, if one hat ^ is chosen, my servers will always support one ^ and two hats ^^ (but that doesn't mean it needs to be part of the spec, just that it's possible for a server to be more flexible). I understand the reasoning behind the $ though; not a bad idea either (but I'd still support ^^ I guess). > Must the datatype xsd:string always be omitted? > ------------------------- > Markus: I'd would be fine making this a "the datatype xsd:string MAY be > omitted" +1, strongly > Must the datatype rdf:langString always be omitted/present? MUST be omitted for me; simply a language tag is enough. Like Turtle, I'd either add a type or either a language. > expanded by only using the lexical representation of the value or the IRI > (no quoting). Does anyone disagree with this? There also seem to be > consensus that we don't want to do any escaping of strings/IRIs, right? +1 for no IRI quoting +1 for no escaping Ruben
Received on Saturday, 26 July 2014 11:52:15 UTC