Re: CFC: Basic Roles Proposal

That last part should really be '...whose role vis-a-vis The Annotation
is...' so as not to confuse it with the Roles we've been discussing which
are Body(ies) vis-a-vis The Target(s).

_____________________________________________________
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 Mon, Aug 24, 2015 at 9:55 AM, Jacob Jett <jjett2@illinois.edu> wrote:

> Stian has articulated my thoughts exactly. The solution for roles is not
> SpecificResource in and of itself but rather a related and similar sibling
> class as too much of the specifiers portion of the model is pegged to the
> SpecificResource.
>
> I would probably be -1 like Stian except that I +0.5'd the straw man
> before I began digging into the effects on the multiplicity classes.
> Overall the proposal is shedding value for me, kinda like the stock market
> right now. :(
>
> It may be that bodies and targets will have to be their own
> SpecificResource-like entity (i.e., something generic like Content whose
> role in the annotation is expressed by the hasBody and hasTarget
> predicates) and that SpecificResources are one among several sub-classes.
>
> 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 Mon, Aug 24, 2015 at 9:42 AM, Stian Soiland-Reyes <
> soiland-reyes@cs.manchester.ac.uk> wrote:
>
>> -1 for the same reasons as Jacob.
>>
>> I would say -1 even without 3.2.4 until the meaning of oa:Choice etc.
>> has been clarified in this proposed requirement of SpecificResource.
>> It seems we are throwing out the baby with the wash water just to
>> prettify some JSON, and forget to consider how SpecificResource is to
>> be used for a specific resource with selectors.
>>
>> Perhaps it is an upper class of SpecificResource that is really in the
>> making? One that doesn't necessarily have selectors etc.   That would
>> make it easier to fit in the EmbeddedTextContent.
>>
>>
>>
>> On 24 August 2015 at 15:32, 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
>> >
>> >
>>
>>
>>
>> --
>> Stian Soiland-Reyes, eScience Lab
>> School of Computer Science
>> The University of Manchester
>> http://soiland-reyes.com/stian/work/
>> http://orcid.org/0000-0001-9842-9718
>>
>>
>