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

Re: A view from outside

From: john.walker <john.walker@semaku.com>
Date: Fri, 25 Jul 2014 11:38:54 +0200 (CEST)
To: public-rdf-shapes@w3.org, Lars Marius Garshol <larsga@garshol.priv.no>
Message-ID: <813785206.1025334.1406281134903.open-xchange@oxweb03.eigbox.net>
Hi Lars,

Based on what you describe about web services, it might be worthwhile to take a
look at Hydra:
http://www.hydra-cg.com/

Hydra doesn't cover the validation, but does allow to describe the API in a
machine-readable way.

Regards,

John Walker


> On July 25, 2014 at 10:24 AM Lars Marius Garshol <larsga@garshol.priv.no>
> wrote:
>
>
> Hi all,
>
> I'd kind of promised myself not to get involved in standardization again, but
> unfortunately my employer really needs an RDF constraint language, and the
> direction of this group looks really worrying. At first glance, anyway.
>
> First of all: I'm glad there seems to be rough consensus that the use cases
> and requirements are going to be written first. The initial list in the
> charter looks like a good start to me.
>
> There is one thing that confuses me, though. If I want to make a schema for my
> web service, wherein I declare that all resources submitted to it must be of
> type foaf:Person, must have a foaf:name and a foo:email, and possibly one or
> more foo:phone ... then shouldn't the spec allow me to simply say that?
>
> That is, something like
>
> foaf:Person class,
> foaf:name 1 1,
> foo:email 1 1,
> foo:phone 0 * .
>
> (Please don't get hung up on the syntax of this example. I just invented it
> off the top of my head in 2 seconds to ask this question. It's *not* a
> proposal.)
>
> I'm confused as to why people seem to prefer solutions that are vastly more
> complicated. Could someone explain? Are the proposals less complicated than
> they seem, or is there something else going on?
>
> Best,
> --Lars M.
> http://www.garshol.priv.no/tmphoto/
> http://www.garshol.priv.no/blog/
>
>
Received on Friday, 25 July 2014 09:39:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:39 UTC