W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > April 2015

Re: vote for supporting "closed shapes"

From: Arthur Ryman <arthur.ryman@gmail.com>
Date: Wed, 29 Apr 2015 00:50:55 -0400
Message-ID: <CAApBiO=OEY22KJH+f2oC6hW6b3nsu_z3CrNpaH46Y4QPj0VhMw@mail.gmail.com>
To: "Eric Prud'hommeaux" <eric@w3.org>
Cc: Karen Coyle <kcoyle@kcoyle.net>, W3C Public RDF Shapes <public-rdf-shapes@w3.org>
Eric,
 Small tweak. It's not that the server necessarily accepts the
unexpected triples. Rather, it may simply drop them but report that
fact in the response.

a server accepts only the expected triples and returns a list of the
ignored, unexpected triples to the client.


-- Arthur

On Tue, Apr 28, 2015 at 4:43 PM, Eric Prud'hommeaux <eric@w3.org> wrote:
> * Karen Coyle <kcoyle@kcoyle.net> [2015-04-28 13:15-0700]
>> Thanks, Arnaud. I was looking in the list of approved requirements
>> -- this one is "under consideration." Do you have it on your list of
>> requirements to be discussed, or is an issue needed?
>
> I took an action to add some text to make it more concrete for Ted:
> [[
> A few uses of closed shapes: a client tests that every triple being
> sent to a server will be accepted/processed; a server rejects any
> document with unexpected triples; a server accepts unexpected triples
> but returns a list of expected triples to the client.
> ]]
> Arthur, do you accept that text?
>
> Note that this requirement is more general than was described in
>   http://www.w3.org/2015/ShExpressivity
>
>
>> kc
>>
>> On 4/28/15 11:47 AM, Arnaud Le Hors wrote:
>> >Hi Karen,
>> >
>> >This actually does refer to a proposed requirement:
>> >2.6.11 expressivity: closed shapes
>> >https://www.w3.org/2014/data-shapes/wiki/Requirements#Expressivity:_Closed_Shapes
>> >--
>> >Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies -
>> >IBM Software Group
>> >
>> >
>> >Karen Coyle <kcoyle@kcoyle.net> wrote on 04/28/2015 11:21:54 AM:
>> >
>> > > From: Karen Coyle <kcoyle@kcoyle.net>
>> > > To: public-rdf-shapes@w3.org
>> > > Date: 04/28/2015 11:22 AM
>> > > Subject: Re: vote for supporting "closed shapes"
>> > >
>> > > I did find this:
>> > >
>> > > http://www.w3.org/2014/data-shapes/track/actions/20
>> > >
>> > > ACTION-20: Update description of 2.6.11 expressivity: closed shapes to
>> > > address concerns expressed to date
>> > >
>> > > However, that has not resulted in an issue or a requirement. I believe
>> > > it refers to one version of the ShEx specification. If so, that does not
>> > > promulgate it to the working group activities as a whole. I'm still
>> > > looking to create an issue for this, but looking for help on wording.
>> > >
>> > > kc
>> > >
>> > > On 4/25/15 9:31 AM, Karen Coyle wrote:
>> > > > Erik, I think I captured some of your requirements in a use case that
>> > > > comes from the Dublin Core community:
>> > > >
>> > > > https://www.w3.org/2014/data-shapes/wiki/
>> > > User_Stories#S37_Defining_allowed.2Frequired_values
>> > > >
>> > > >
>> > > > In particular:
>> > > >
>> > > > 2) must be an IRI matching this pattern (e.g.
>> > > > http://id.loc.gov/authorities/names/)
>> > > >
>> > > > There is a need within the closed environment where validation will
>> >take
>> > > > place to limit the "anyone can say anything about anything" to a
>> >  set of
>> > > > known namespaces. The user story only speaks of values (objects) but
>> > > > this could also be the case for subjects and predicates.
>> > > >
>> > > > kc
>> > > >
>> > > >
>> > > >
>> > > > On 4/22/15 3:50 PM, Erik Wilde wrote:
>> > > >> hello.
>> > > >>
>> > > >> i am not a member of the RDF shapes WG. but i have been encouraged to
>> > > >> voice my opinion on the public mailing list, so here i go.
>> > > >>
>> > > >> it seems that the "closed shapes" feature so far is not a required
>> > > >> feature for the envisioned language. i want to support this
>> >feature, and
>> > > >> claim that having or not having this will make a huge difference in
>> > > >> terms of how business-ready the language is.
>> > > >>
>> > > >> being able to exactly say what is or isn't allowed is a critical
>> >feature
>> > > >> in business processes. very often, there even are validation
>> >pipelines,
>> > > >> with various levels of openness and increasing levels of strictness,
>> > > >> after cleanup and consolidation stages.
>> > > >>
>> > > >> not being able to "strict" validation (borrowing XSD's terminology of
>> > > >> "lax" and "strict" and bending it a little bit here) would mean
>> >that the
>> > > >> new language would only be useful for some validation tasks, but that
>> > > >> others would still need to be hand-coded.
>> > > >>
>> > > >> having well-defined language features similar to the "wildcards"
>> >in XSD
>> > > >> is critical in terms of getting RDF closer to be business-ready. in my
>> > > >> work with XML, JSON, and RDF, one typical criticism of RDF is that it
>> > > >> assumes well-meaning peers, and has little support for scenarios
>> >beyond
>> > > >> that. supporting "closed shapes" could be one step in this direction,
>> > > >> and i would like to consider the WG to make this a mandatory
>> >feature and
>> > > >> provide fine-grained controls for how open/closed a model should be.
>> > > >>
>> > > >> thanks and kind regards,
>> > > >>
>> > > >> dret.
>> > > >>
>> > > >
>> > >
>> > > --
>> > > Karen Coyle
>> > > kcoyle@kcoyle.net http://kcoyle.net <http://kcoyle.net/>
>> > > m: 1-510-435-8234
>> > > skype: kcoylenet/+1-510-984-3600
>> > >
>>
>> --
>> Karen Coyle
>> kcoyle@kcoyle.net http://kcoyle.net
>> m: 1-510-435-8234
>> skype: kcoylenet/+1-510-984-3600
>>
>
> --
> -ericP
>
> office: +1.617.599.3509
> mobile: +33.6.80.80.35.59
>
> (eric@w3.org)
> Feel free to forward this message to any list for any purpose other than
> email address distribution.
>
> There are subtle nuances encoded in font variation and clever layout
> which can only be seen by printing this message on high-clay paper.
Received on Wednesday, 29 April 2015 04:51:23 UTC

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