W3C home > Mailing lists > Public > public-annotation@w3.org > August 2015

Re: CFC: Basic Roles Proposal

From: Jacob Jett <jjett2@illinois.edu>
Date: Mon, 24 Aug 2015 09:32:02 -0500
Message-ID: <CABzPtB+JGcBruLNvfWaOw0+0jqsQpNoG75Wzw8TqpRegHk1NcA@mail.gmail.com>
To: Web Annotation <public-annotation@w3.org>
-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> ] .


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



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

On Sun, Aug 23, 2015 at 5:37 PM, Robert Sanderson <azaroth42@gmail.com>

> 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 Monday, 24 August 2015 14:33:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC