RE: name of the group


Admittedly, I don't know the history that led to the name. If I understand
the few first introductory paragraphs in the working group charter
correctly, it seems to be mainly about data validation. Reading through the
very active discussions that happened on the mailing list this month, they
also seem to be overwhelmingly concerned with data validation.

One could make an argument that if the charter is broader than a recognized
industry concept and requires creating new terminology to express it,
perhaps, it is too broad. Knowing that the standard name can be different
from the working group name makes it more palatable. 

However, I believe that psychologically the name of the working group must
in many ways influence the name of the standard. Such is the human nature. I
don't know to what extend WebOnt and DAWG are good examples of meaningful
differences between the name of the working group and the name of the
standard. WebOnt is an abbreviation for the 'web ontology' which corresponds
very closely with what OWL is an abbreviation for. DAWG stands for the Data
Access Working Group. Data Access is a commonly understood general term. It
was clear that the name of the data access mechanism still needed to be
'invented'. In both cases, there was no need to create new terminology in
order to name the group.  


-----Original Message-----
From: Sandro Hawke [] 
Sent: Tuesday, July 22, 2014 8:55 AM
To: Irene Polikoff; Antoine Isaac
Cc: <>
Subject: name of the group

On 07/22/2014 08:20 AM, Irene Polikoff wrote:
> +1 for renaming the group.
> Not only does the name pre-impose the outcome, even more importantly, it
introduces a brand new terminology where none is required.
> There are already widely understood and used ways to talk about this topic
such as constraint and data validation.

The workshop was called "RDF Validation Workshop" and people pushed back
that this was about more than validation, so the name should be broader.

I hear "constraints" meaning a lot of different things, even within RDF.

I think consensus at the Validation Workshop was that the core notion was
about what we usually call graph patterns, but with additional things like
constraining the types and values of literals, and making 
these patterns recursive/reusable.    So the name "pattern" no longer 
really applied either.

IBM had proposed "resource shapes", and so "shapes" ended up being the word
that stuck, and after some recent discussion, we migrated to "data shapes"
for the broader context, to help avoid confusion for people who think it
might be about visual or physical stuff.

There's nothing about that name that pre-supposes the technology. 
SPARQL, SPIN, OWL, ICV, ...  are perfectly reasonable technologies for
declaring data shapes, give or take some tweaks that have been mentioned.

>   One can't underestimate the negative impact any new terminology has on
the marketplace adoption. Where are times when the new terminology is
necessary and there is no way to avoid doing so. This is not one of them.

As I seem to be saying a lot: I don't agree, but I'd honestly be happy 
to be proven wrong.    What term is better than "data shapes" for the 
use cases in the motivation section of the charter, or some other set of
uses cases you're confident the group will approve?

Also, just to be clear, the name of the Working Group and the name of the
Technology/Standards are often different:

WebOnt produced OWL
DAWG produced SPARQL

At some point in the life of the group, the group decides what to name the
thing it's Recommending.

         -- Sandro

> Regards,
> Irene Polikoff
> Sent from my iPhone
>> On Jul 22, 2014, at 4:12 AM, Antoine Isaac <> wrote:
>> Dear all,
>> The discussion is really interesting, but I'm afraid grounded on sand and
quite a waste of time now. As long as the cases for which we want RDF
validation / shape checking are not further documented/formalized, firing
examples by email will be a very stimulating game, but we won't be able to
use them to disqualify either ShEx or SPIN or any other. Or to convince
their creators to update them, if that's the best strategy.
>> I imagine things will be quite different once there appears in a formal
Group Note some requirements that are super-hard to tackle for ShEx or
>> I found Holger's last contrib to be especially interesting in fact. If
someone like him thinks that an answer to the current draft charter [1] is:
"oh, we could also make a group around SPIN", then it is indeed that there
is something fishy with the current charter. We should create a
technology-agnostic WG here. If the discussion demonstrates there's not
enough consensus for a specific technology, consensus needs to be built.
>> Personally I thought the current charter was neutral enough, and its
focus on use case and requirements strong enough to warrant bias towards a
given technology. Especially the word 'shapes' was not ShEx-binding, as it
not used only by ShEx.
>> But well, the group could also be titled with "constraints" instead of
"shapes". And let the notion of shapes re-emerge through requirements, if
it's indeed a relevant one (I believe it is, but well...).
>> By the way I believe the charter could be a bit stronger on the OWL side.
If there's a new standard for constraint checking, the group should have
identified when users should use OWL, and when they should use the new
standard. It might be just a matter of pointing to some existing papers on
the topic.
>> Best,
>> Antoine
>> [1]
>>> On 7/22/14 9:13 AM, Paul wrote:
>>> Hi,
>>> As a SPIN and ICV user myself, I have no objections in standardising nor
SPIN nor a closed world semantics OWL.
>>> I have no opinions yet on ShEx since not studied.
>>> But what we as implementation partner encounter doing jobs (mainly
linked data in the government domain) is that both SPIN and ICV are very
difficult to sell.
>>> The reasons might be different (perceived as difficult, overloading the
system, OWL being already closed in the minds of people).
>>> So if there would come along a constraint language death simple (with
escape route to SPARQL) that would get my vote also.
>>> Paul
>>> Kind Regards,
>>> Paul Hermans

Received on Tuesday, 22 July 2014 13:21:16 UTC