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

Re: Moving forward with ISSUE-30 (IRI template expansion)

From: Ruben Verborgh <ruben.verborgh@ugent.be>
Date: Sat, 26 Jul 2014 13:51:43 +0200
Cc: public-hydra@w3.org
Message-Id: <ACCE6A3D-0017-42BE-B01B-AD4C87B6CF62@ugent.be>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
> 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

Received on Saturday, 26 July 2014 11:52:15 UTC

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