Re: CFC: Basic Roles Proposal

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

Received on Tuesday, 1 September 2015 23:26:59 UTC