- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 22 Jul 2014 08:37:45 -0700
- To: public-rdf-shapes@w3.org
On 7/22/14, 7:25 AM, Kendall Clark wrote: > Can someone help me understand what the technical difference is between > these requirements about "shape" what is otherwise called constraint > validation? I'm genuinely confused if these aren't just synonyms. I'd say that it isn't a "technical difference" but a "human difference" - looking at cognitive psych work on concepts, most persons will more likely have a concept of a shape or profile or mental picture of their data than of "constraint validation". Constraint validation is the action you can develop based on shapes, but shapes are what the data means to the people who work with it. If our audience is only machines, then perhaps SPARQL + closed world OWL is sufficient (which we won't know until we have done a fairly intense set of case studies), but if your audience is the people who must think about their data and express what the boundaries and limitations they wish for their data, then you need a human-facing language that helps them both conceptualize the possibilities and to express those concepts in a way that can be translated to machine-functionality. Unless we're in the age of Skynet, humans are in the equation for providing the intellectual meaning to the data, and to the use of the data to create more knowledge. Some on this list seem to want to standardize the underlying code, assuming that there will be a nice interface imposed over it for people to use. Others want to standardize a simple language that can be converted to underlying code, that could be used directly or sit between a UI and the machine code. Personally, I have already found that without a deep understanding of the underlying code (which often is not documented), the UIs that I have encountered do not explain to me what transformations are happening between the UI and the underlying code. I cannot trust the results I get. (Is it a bug, or a feature?) The distance between the UI and the code is too far. An intermediate language, let's call it "python/ruby/perl/.../ for RDF" would make it possible for thousands of skilled developers to write their own code, and to have predictable results. That's my 3 cents. kc > > Cheers, > Kendall > > > On Tue, Jul 22, 2014 at 10:17 AM, Paul <paul@proxml.be > <mailto:paul@proxml.be>> wrote: > > Paul, Dave, > > That's very similar to experiences and expectations at the Flemish > and Dutch government. > > > Paul > > > > On 22 Jul 2014, at 16:10, Paul Davidson > <Paul.Davidson@Sedgemoor.gov.uk > <mailto:Paul.Davidson@Sedgemoor.gov.uk>> wrote: > > > Thanks Dave > > > > Yes - my requirement is about having some confidence about the > properties, classes etc that a data producer has used, and will > continue to use, and being able to encourage other data producers to > adopt the same 'shape'. As Local Authorities, there are hundreds of > councils, all providing similar services, and to be able to combine > data from each, we need some way of expressing a desired shape, and > to discover data that is in that shape. > > > > Paul Davidson > > Chief Information Officer > > Sedgemoor District Council > > UK > > > > -----Original Message----- > > From: Dave Reynolds [mailto:dave.e.reynolds@gmail.com > <mailto:dave.e.reynolds@gmail.com>] > > Sent: 22 July 2014 15:05 > > To: public-rdf-shapes@w3.org <mailto:public-rdf-shapes@w3.org> > > Subject: Re: name of the group > > > > 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. > > > > +1 > > > > 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 mentioned)". > > > > 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.] > > > > Dave > > > > > > > > > ________________________________________________________________________ > > This e-mail has been scanned for all viruses by Claranet. The > service is powered by MessageLabs. For more information on a > proactive anti-virus service working around the clock, around the > globe, visit: > > http://www.claranet.co.uk > > > ________________________________________________________________________ > > > > ________________________________ > > > > Follow Sedgemoor District Council on Twitter: > > http://twitter.com/#!/SedgemoorDC > > > > > > Disclaimer: > > > > Views: > > The views expressed in this electronic communication are those of > the writer and not, unless otherwise stated, the views of Sedgemoor > District Council. > > > > Confidentiality: > > The addressee(s) of this electronic communication shall treat its > content in confidence and take all reasonable steps to ensure it is > not accessed or made available to any third party. Sedgemoor > District Council will not be liable for any unauthorised access to > the contents during transit or whilst stored on electronic media > outside of its direct control. > > > > Viruses: > > Sedgemoor District Council take all reasonable steps to ensure > that this communication and any attachments are virus free, however, > the Council cannot accept liability in respect of any complaint > arising as a result of this message or its attachments. > > > > > > > > > Kind Regards, > Paul Hermans > > ------------------------- > ProXML bvba > Linked Data services > (w) www.proxml.be <http://www.proxml.be> > (e) paul@proxml.be <mailto:paul@proxml.be> > (tw) @PaulZH > (t) +32 15 23 00 76 <tel:%2B32%2015%2023%2000%2076> > (m) +32 473 66 03 20 <tel:%2B32%20473%2066%2003%2020> > > > > > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Received on Tuesday, 22 July 2014 15:38:17 UTC