Re: CFC: Basic Roles Proposal

And my apologies that it wasn't clear.  I wondered about making two
documents, but as there's so much overlap in the content, it didn't make
sense, compared to two sections in the one document.

I'll make a thread regarding Multiplicity and roles, as you (and Stian) are
very much on target with your comments in that space.

Rob



On Mon, Aug 24, 2015 at 10:44 AM, Jacob Jett <jjett2@illinois.edu> wrote:

> Hi Rob,
>
> Sorry. That the CFC is only for section 3.1 was not clear to me at all. I
> am then +0.75 for just the 3.1 portion. How roles affect constructs like
> Choice and Composite, among others, is not discussed at all. So I
> necessarily have some reservations.
>
> We seem to be focused on simplifying the simple cases rather than
> simplifying the complex cases, which is a bit worrisome because all the
> "gotcha's" are going to pop up with the latter cases rather than the former
> ones.
>
> 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:37 AM, Robert Sanderson <azaroth42@gmail.com>
> wrote:
>
>>
>> Jacob,
>>
>> The CFC is *only* for section 3.1 -- are there any features in 3.1 that
>> mean you're -1 ?
>>
>> Rob
>>
>> On Mon, 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
>>
>
>


-- 
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305