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

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

From: Ruben Verborgh <ruben.verborgh@ugent.be>
Date: Sat, 26 Jul 2014 17:14:11 +0200
Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, "<public-hydra@w3.org>" <public-hydra@w3.org>
Message-Id: <9116ADDB-D0BF-4353-99CE-88CC44791493@ugent.be>
To: ryan.riley@panesofglass.org
Hi Ryan,

Cool stuff, I love functional languages!

>> With that context in mind, I'd like to point out that Ruben's point
>> of this as a string match holds in untyped or languages with weak
>> type systems.

Under the hood, it will always come down to string comparison.
Does this literal value equal the other literal value?
Does this IRI equal the other IRI?

While it's true that many languages do make useful abstractions,
this problem is always resolved with string comparison somewhere.
So my point is that booleans and IRIs don't make a difference.

> Sure. The point I was trying to make though was that if it is a boolean, you
> just need *one* check.

No, you need more: there are two ways to encode true and false [1].
Furthermore, how can you be sure the user actually used a boolean?
There's no static type checking. 

So you have to check:
- is it "true"?
- is it "1"
- is it "false"?
- is it "0"?
If non of the above, it's an invalid value.

> In case of IRIs you need *at least two*.

Just two, at most:
- is it "hydra:ExpandedRepresentation"?
- is it "hydra:ValueRepresentation"?
If non of the above, it's an invalid value.

You can do it with one check, too:
- is it "hydra:ExpandedRepresentation"?
and then assume ValueRepresentation otherwise
(nothing you can do in other cases).

(With booleans, you can also apply the above trick,
 but you have to check for "1" or "true".)

> A boolean also reduces errors (typos)

"flase"^^xsd:boolean ;-)

> and makes it clear that this is not an extension point.

No, it just says that, if you want another syntax,
you have to invent another property.
Thereby, it actually just defines a _different_ extension mechanism,
one that is more troublesome than the other.

For example:
    _:x hydra:expandedRepresentation false.
    _:x ex:myRepresentation true.
What can a client do with this?
It will silently fail without knowing why.

Whereas:
    _:x hydra:valueRepresentation ex:MyRepresentation.
the client knows it doesn't understand the representation;
but it does know that ex:MyRepresentation is a representation.
Hence, it can give an appropriate error message:
"representation ex:MyRepresentation not supported".
(Or dereference ex:MyRepresentation and learn more.)

Best,

Ruben

[1] http://www.w3.org/TR/xmlschema11-2/#boolean
Received on Saturday, 26 July 2014 15:14:46 UTC

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