Re: A view from outside

Hi Lars,

I believe it is important to separate the discussion about syntax from 
the underlying semantics or "model". Yes, your specific example can be 
nicely represented in a very compact textual form. But your example only 
talks about cardinality, and there is obviously much more that people 
want to specify when they publish data models. For example you may want 
to say that the values of foo:email are syntactically well-formed email 
addresses. Simple languages quickly reach limits and then need to be 
overloaded with all kinds of escape mechanisms. RDF is designed to be 
extensible - anyone can add their own classes and properties to 
represent any kind of extra information. Therefore a model that talks 
about other data models should also be represented in RDF, and that's 
where Shapes come into the picture. For certain common shapes (such as 
cardinality) a short-hand syntax could be added, but still the 
underlying semantics need to be more flexible.


On 7/25/14, 6:24 PM, Lars Marius Garshol 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.

Received on Saturday, 26 July 2014 04:22:48 UTC