Re: CFC: Basic Roles Proposal

On Tue, Sep 1, 2015 at 9:11 PM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
> Summary of the CfC on Section 3.1 as of 9pm W3C time on 2015-09-01
>
> Rob Sanderson: +1
> Frederick Hirsch: +1
> Ivan Herman: +1
> Ben De Meester: +1
> Raphael Troncy: +1
> Davis Salisbury: +1
> Jacob Jett: +1  (actually "+0.75" after clarification that it only applies
> to 3.1)
>
> Kyrce Swenson: "For the purposes of edit/copy-edit; this makes sense, and
> I would agree that it appears to be the simplest viable solution."
>  -- I think this is a +1 with some reservations?
>
> Stian Soiland-Reyes:  "I am unable to comment on 3.1 in isolation without
> knowing what is the (implied or specified) type of the object that has
> oa:role."
>  -- I think this is abstention?
>
> Other WG participants who have contributed to the discussion but not
> registered a position:
>
> Doug Schepers (But from the same organization as Ivan Herman)
> Tim Cole (But from the same organization as Jacob Jett)
> Benjamin Young
>

Woops...so busy discussing it, I forgot to vote. :)

+1

My more recent alternatives can be tabled until someone else cares enough
about a shift toward that format to make it a reality.

The Roles document creates a much clearer way forward for various use cases
than we've had yet.

Thank you everyone for the discussions. :)


> Ray Denenberg
>
> Other non-WG participants who have contributed to the discussion:
>
> Bill Hunt: "we're happy to step out of the way if that helps the rest of
> the group reach an amicable solution."
>  -- Although non WG members do not actually count towards a CfC, Chris
> Birk is an Invited Expert from the same organization, so I'm counting this.
>  -- And I think is a -0 (don't like it but could live with it if nothing
> better can be agreed on)
>
> Rob
>
>
> On Tue, Sep 1, 2015 at 4:26 PM, Frederick Hirsch <w3c@fjhirsch.com> wrote:
>
>> [not as chair]
>>
>> I agree with this; in addition 'source' is just as intuitive as
>> 'content', if not more so, for precisely the reasons Jacob gives.
>>
>>
>> regards, frederick
>>
>> > On Aug 24, 2015, at 10:32 AM, Jacob Jett <jjett2@illinois.edu> wrote:
>> >
>> > -1 so long as it contains 3.2.4
>> >
>> > If 3.2.4 can be removed to a separate issue, then +0.75.
>> >
>> > I feel like someone has added some tax appropriations for their highway
>> to an EPA funding bill. If an issue is not directly related (like the
>> proposed hasSource name change) then we should discuss it separately.
>> >
>> > Some folks are of the opinion that changing to hasContent has no real
>> impact on the model but once you start using multiplicity constructs and
>> selectors it is no longer clear what was intended to be meant by saying
>> hasConstruct. For instance compare:
>> >
>> > <http://example.org/anno1> a oa:Annotation ;
>> >      oa:hasTarget [ oa:hasSelector <http://example.org/selector1> ;
>> >                              oa:hasSource <http://example.org/target1>
>> ] ;
>> >      oa:hasBody [ oa:hasSource <http://example.org/tag1> ] .
>> >
>> > to
>> >
>> > <http://example.org/anno1> a oa:Annotation ;
>> >      oa:hasTarget [ oa:hasSelector <http://example.org/selector1> ;
>> >                              oa:hasContent <http://example.org/target1>
>> ] ;
>> >      oa:hasBody [ oa:hasContent <http://example.org/tag1> ] .
>> >
>> >
>> > The intended meaning of hasContent is only clear in the simple cases
>> when selectors are not being employed (i.e., when the SpecificResource is
>> simply a b-node interposed between the annotation node and that actual body
>> / target content). This is not the case as soon as we employ Selectors.
>> >
>> > This will be similarly true for non-trivial multiplicity cases.
>> Consider the pattern.
>> >
>> > <http://example.org/anno1> a oa:Annotation ;
>> >     oa:hasTarget <http://example.org/target1> ;
>> >     oa:hasBody [
>> >         a oa:Choice ;
>> >         oa:member [ <http://example.org/body1> ;
>> >                              <http://example.org/body2> ] ;
>> >     ] .
>> >
>> > Assuming that oa:Choice is a sub-class of oa:SpecificResource then
>> under the suggested regime of 3.2.1 and 3.2.2 it must become
>> >
>> > <http://example.org/anno1> a oa:Annotation ;
>> >     oa:hasTarget <http://example.org/target1> ;
>> >     oa:hasBody [
>> >         a oa:Choice ;
>> >         oa:member [ <http://example.org/body1> ;
>> >                              <http://example.org/body2> ] ;
>> >        oa:hasSource <???>
>> >     ] .
>> >
>> > I'm not even sure what we'd use for the object of the hasSource /
>> hasContent predicate but we have to have one because it's a MUST in the
>> draft. The CFC seems a bit premature as it failed to consider all of the
>> implications and, this proposal has some very serious implications for
>> important portions of the model. While fixing some issues it introduces
>> others. An easy solution is to either keep the multiplicity constructs as
>> separate (sibling) specific resource types that don't require a hasSource /
>> hasContent predicate or to relax the MUST to a MAY or to adopt some rather
>> complicated language explaining when hasSource / hasContent SHOULD be used.
>> >
>> > And of course the objects of oa:member could be Specific Resources
>> themselves making an infinite recursion possible...
>> >
>> > Regards,
>> >
>> > Jacob
>> >
>> >
>> >
>> >
>> > _____________________________________________________
>> > Jacob Jett
>> > Research Assistant
>> > Center for Informatics Research in Science and Scholarship
>> > The Graduate School of Library and Information Science
>> > University of Illinois at Urbana-Champaign
>> > 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
>> > (217) 244-2164
>> > jjett2@illinois.edu
>> >
>> > On Sun, Aug 23, 2015 at 5:37 PM, Robert Sanderson <azaroth42@gmail.com>
>> wrote:
>> >
>> > Dear all,
>> >
>> > This is a Call for Consensus (CfC) to update the working group's
>> Annotation Model deliverable according to the changes specified in section
>> 3.1 of this document:
>> >     http://w3c.github.io/web-annotation/model/wd/roles.html
>> >
>> > Please respond to this CfC by the 1st of September 2015.  Any response
>> is valuable, even just a simple +1.  Silence will be considered as
>> agreement.  This CfC will complete the process discussed in last week's
>> teleconference.
>> >
>> > Thanks in advance,
>> >
>> > Rob
>> >
>> > --
>> > Rob Sanderson
>> > Information Standards Advocate
>> > Digital Library Systems and Services
>> > Stanford, CA 94305
>> >
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
>