Re: CFC: Basic Roles Proposal

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
>
>

Received on Monday, 24 August 2015 14:56:47 UTC