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

Re: name of the group

From: Dave Reynolds <dave.e.reynolds@gmail.com>
Date: Tue, 22 Jul 2014 15:02:29 +0100
Message-ID: <53CE6EF5.6080907@gmail.com>
To: public-rdf-shapes@w3.org
On 22/07/14 13:54, Sandro Hawke wrote:
> 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.


The requirement I've personally heard most strongly expressed by those 
I've worked with in UK Gov circles is that given by Paul Davidson in his 
presentation at the workshop.

He called for some simple, easy to understand and deploy means to 
declare and discover the "shape" (for what of a better term) of data.

For a data producer to be able say "our data stitches together some bits 
of foaf, org, dct, skos etc *this* way, so here's what you should expect 
to see in our data (though there might be other properties we haven't 

For a data consumer to say "we'd like your data to include at least 
these types and properties or we won't know what to do with it, if you 
are going to express concept X then please use property p for it (though 
p is optional), you may also use other properties we don't know about 
but that's fine."

Formally checking that data matches this "shape" is a useful but not 
primary requirement for those users. They are not looking for really 
complex data validation, data quality is typically validated elsewhere 
in the chain by rather powerful existing data tools.

We have tried wteo "actually you can say (most) of that in OWL but you 
have to apply the semantics a little differently and find some way to 
associate the OWL 'constraints' with your data". That didn't fly for 
these particular users - they find the specifications and narrative 
around OWL too complex and alien to meet the "simple to understand" and 
"simple to deploy" requirement. Though personally it largely works for me.

Similarly "why not just express it in SPARQL" didn't fly, fine for 
implementation under the hood but not as a way to comprehend what the 
shape specification is saying (whether by human or machine).

Probably the IBM resource shapes proposal is the closest in spirit to 
this requirement so the name "RDF Data Shapes" seems like a pretty 
accurate name to me.

An alternative would be profile. That's the term we used in the GLD 
vocabulary Recommendations and it does seem to be closely related to the 
Dublin Core notion of application profiles.

[Note: This is my interpretation of what people like Paul were saying 
but I don't formally represent him or any other W3C member so any 
misunderstanding is mine. The chances of my being able join the WG, if 
it actually got off the ground, are very low so I'll mostly try to keep 
out of the discussion.]

Received on Tuesday, 22 July 2014 14:03:04 UTC

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