![]() ![]() Jacob, I think the answer is no, that is not what I heard So eliminate section 5 of the existing doc? lets solve other issues first then revisit multiplicity construct Ivan: multiplicity construct may become alternative to what we have now (?) role on choice not on bodies within choice, role should be consistentĪzaroth: not making it more complex given that multiplicity is already complex TimCole: yes need to think about them, e.g. TimCole: come back to it with concrete serializations in mindįjh: +1 to option 2 now, given reminder from Ivan and TimĪzaroth: do we need examples of multiplicity constructs complex in abstract, so suggest we make examples example role on composite, could have role on specficResources within as well? hence limiting to specificResource might not help ![]() because SpecificResources can appear in multiplicity class need to handle that for embedded text, also for composite bodies Ivan: do not want to be forced to say this more complicated one Ivan: repeat that need to have simple text with role, do not want that to be more complexĪzaroth: keep motivation on annotation as well as roles on body/text Looking ahead, it seems like ultimately adopting option 1 will require a larger reworking of section 5 of the spec. Straw Poll : Option 2 (Compact, Flexible, Less Structured) Straw Poll: Option 1 (Verbose, Consistent, Structured)Īzaroth: lets start with options since it informs individual points ditto the relationship between specific resources and multiplicity nodesįjh: should we review the individual points in 3.2 for which there was a straw poll on the list as well as option 1 and option 2 motivation on multiplicity classes not thoroughly discussed in current document Ivan: are there other consequences apart from what you listed in response to DougĪzaroth: haven't worked through all examples basically everything that could be the object of a hasBody/hasTarget predicate but excluding the annotation node itself. fjh, you wanted to ask for specific response re option 1 vs option 2 key question is whether on annotation as well as bodies and targets. TimCole: looking at option 1 vs option 2, limitied where role can be put, small number ok image with id, bad to put role on that image, for example might impact interoperability, need to be careful azaroth, you wanted to note profiles are like micro specificationsĪzaroth: responding to Tim, have seen such patterns, like micro specs, overall spec needs to be constrained example is where can put text re role, came up in email, definitely support simple way Ivan: prefer to make life for users easier even if harder for application developers this trade off allows keeping simple cases simple but if wider interoperability can lose optimizations, but if local can get optimizations TimCole: re optimization, local application can use profile of interoperability standard, allowing optimizations second is more compact and easier to follow but more flexible and possibly inconsistentĪzaroth: concern is need for code to test structure when it is not consistent first is more verbose but more consistent Īzaroth: two options outlined, see link, each with tradeoffs Created ACTION-27 - Update editors draft to reflect changes per 3.1. ![]() ACTION: azaroth to update editors draft to reflect changes per 3.1 RESOLUTION: changes in section 3.1 agreed see per CfC conclusion Proposed RESOLUTION: changes in section 3.1 agreed see per CfC conclusion Proposed RESOLUTION: changes in section 3.1 of adopted via CfC RESOLUTION: Minutes from 19 August approved, Data Model Changes for Roles, 3.1įjh: we had support to resolve CfC with one concern expressed by Bill Hunt who said they did not want to hold up workĪzaroth: Bill Hunt not a member of group, Chris Birk an Invited Expert of the same organization did not object, representing same org, so okįjh: I suggest we can go ahead and make progress here, especially given the discussion following Benjamin's brainstorm on the list Proposed RESOLUTION: Minutes from 19 August approved, minor issues like typo can be fixed by editor and acknowleded others require discussion and CfC, managed by chairs issues should include proposal for resolution, and possibly test cases Agenda: Agenda Review, Scribe Selection, Announcementsįjh: updated wiki with how to handle issues, see Meeting: Web Annotation Working Group Teleconference ![]()
0 Comments
Leave a Reply. |