Web Annotation Working Group Teleconference

<fjh> ScribeNick: TimCole

Agenda Review, Scribe Selection, Announcements

<fjh> Linked Data Platform is Recommendation, https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0171.html

<fjh> Next week Time Zone warning if not in US: https://lists.w3.org/Archives/Public/public-annotation/2015Mar/0003.html (thanks Ivan)

<RayD> cannot call in. Get the greeting but never asks for the code

fjh: Linked Data Platform is a recommendation; we will talk about f2f later.

<RayD> anyone else?

fjh: Please be aware of time zone issue next week (see Ivan's email)

Minutes Approval

fjh: any concerns about minutes?

<fjh> proposed RESOLUTION: 25 February 2015 minutes approved, http://www.w3.org/2015/02/25-annotation-minutes.html

RESOLUTION: 25 February 2015 minutes approved, http://www.w3.org/2015/02/25-annotation-minutes.html

F2F Updates

<fjh> Web Annotation 22 April in conjunction with iAnnotate 23-24 April

<fjh> fjh: need to set up F2F page w logistics page etc

Rob: current wiki page about f2f short, need to add info.

<fjh> LDP is having open meeting 21 April SF, see https://www.w3.org/wiki/Main_Page/Linked_Data_2015

fjh: if able to attend LDP f2f please let both WGs know.

azaroth: add yourself into to wiki if you plan to attend LDP f2f
... can also let Rob know and provide suggestions about topic to cover

<fjh> azaroth: meeting is open, not required to be W3C member to attend

<fjh> Social Web F2F Cambridge MA, see https://lists.w3.org/Archives/Public/public-annotation/2015Feb/0176.html

<azaroth> Annotation WG F2F wiki page: https://www.w3.org/annotation/wiki/Meetings/f2f/SF_Q1_2015

<azaroth> (that needs work, please)

fjh: Social f2f will be in Cambridge, fjh may attend on day 1.

<paoloC> I might stop by for a bit as well

<azaroth> Oh and thank you to Dan for helping with the logistics for the LDP meeting to make sure they're back to back with us

fjh: Randall may also attend parts

<fjh> 17–18 March

<azaroth> Greatly appreciated, and definitely above and beyond :)

Use Cases

paoloC: the 3 use cases I've been looking at (newish) are: filtering reviews, annotation of CSV data

<azaroth> +1 to discussion :)

<Zakim> azaroth, you wanted to request protocol "use case" status update

azaroth: should also add on the protocol use cases
... domeo, lorestore, annotator.

<tilgovi> (Randall)

<bigbluehat> Filtering of annotations: https://www.w3.org/annotation/wiki/Filtering_of_annotations

<paoloC> https://www.w3.org/annotation/wiki/Filtering_of_annotations

paoloC: 3 examples of filtering
... user only wants to see notes from a particular individual
... user wants to exclude notes from an individual
... user wants to find annotations from another person

<fjh> first is my annotations, third is some specific person’s annotations

paoloC: would also add groups rather than individuals.
... this use cases impacts model and protocol
... current data model should handle these use cases.
... in terms of protocol, will need features that include and exclude.

Bill_Kasdorf: another case -- time filtering

paoloC: another case is filtering by location
... for example the way Instagram adds location

fjh: this sounds a lot like search - and, or, not

ivan: a little concerned about that

<fjh> impacts model, protocol etc

ivan: we might have to build into the protocol a filtering language, this can get complex quickly
... this complicates the job of the servers
... another option is to rely on the clients to filter
... not which one is better, but we should be wary of feature creep

<Zakim> azaroth, you wanted to note harvesting as UC for time filtering

azaroth: note harvesting of annotations between systems (server to server) is a potential way to approach time based annotations
... also agree that any sort of query language complicates the protocol dramatically.

<fjh> ISSUE: clarify extent of filtering, client local vs search and server side, system impacts

<trackbot> Created ISSUE-19 - Clarify extent of filtering, client local vs search and server side, system impacts. Please complete additional details at <http://www.w3.org/annotation/track/issues/19/edit>.

paoloC: in talking about protocol used by Annotopia, you can ask for annotations about a certain object
... what is difference between search and what is filtering
... what needs to be included in the get annotations function in the protocol

fjh: the answer may revolve about locale of your search.

azaroth: filtering by the server (rather than client) is search
... you need some way to say here are the properties you want to search on

<fjh> surmise search is probably related to discovery versus filtering locally accessable annotations (client or server)

azaroth: what also comes up is the issue of lists of annotation, here is list of annotations about ebooks (available for purchase).

<fjh> but azaroth answer makes sense

azaroth: gets us one step closer to having dynamic lists of annotations

paoloC: one way of looking at it, e.g., ebook, is sending / selling list of annotations, but there are other reasons for sets of annotations.
... you might be interested in relations, for example.
... this means that what we normally record for sets of annotations will be affected, e.g., by adding additional tags to show membership of annotation in set.
... another might be a user creating annotations in a span of time, but more often they are creating different buckets of annotations, time not as important.
... sets could be related to filtering as well as for shipping in connection with a particular document.

<azaroth> +1 to moving on

azaroth: +1, sets for shipping not the only use case to consider, but as an easier starting point might give us useful information about annotation sets.

<paoloC> https://www.w3.org/annotation/wiki/Reviews_as_Annotation

paoloC: we need to develop plans for how we attack use cases.
... Second use case: Reviews

<fjh> need to take use case and constrain on user stories, e.g how sets, filtering, search etc relate, what are the limitations and so on

paoloC: brought up by multiple people

<Jacob> isn't this just filtering by motivation?

paoloC: I have a product or whatever on the Web and I want to retrieve reviews for it.
... I should have a motivation for creating these annotations
... people also refer to other reviews and reviewers
... so I have responses to reviews that also need to be included
... this creates complicated mixtures of annotations.

<Jacob> right, this looks like one of the discourse use cases that came out of digital emblematicA

<ivan> +1 to Ray

RayD: if someone creates a review then someone reviews my review, the next user needs to be able to just retrieve reviews of the book and leave off the reviews of reviews.

<Jacob> I think it depends on the specifics of the case

<Bill_Kasdorf> +1

paoloC: there are 2 ways of doing, one way is to forget about the original target for the response

<fjh> agree, depends on specific content

paoloC: however this is related to the discussion use case
... a lot of reviews - response - response etc. become discussions.

<Bill_Kasdorf> That is +1 to reply is an annotation on the annotation, you need to traverse a chain to get to the original annotation's target

<Jacob> is it possible to yoke the hasScope property to capture the context of these chains of intertwining replies?

paoloC: if you have a powerful client that can model discussions, you want to see the chain of targets

<Jacob> through best practices?

paoloC: do you give different values to targets in the chain when filtering.

azaroth: agrees with Jacob that reply targets both original product and review
... but we don't need to bake a decision on this into the specification

<fjh> +1 annotation is on both, previous comment and original target

<Bill_Kasdorf> we are talking about a web, after all ;-)

azaroth: we should allow communities to make decision most appropriate to their use case.

<Jacob> +1 to allowing the best practice to emerge from the community

<azaroth> :)

fjh: agree, it should be up to you whether you want the reply to target both the review and the product

<fjh> +1 community decision, model supports choices

paoloC: want to clarify what Rob said, we allow multiple targets, so you can decide to use or not.

azaroth: this comes under the issue of whether you can specify the role of a body or target (issue 11 in GitHub)
... if we resolve issue 11 it will resolve this question.

<azaroth> Issue: https://github.com/w3c/web-annotation/issues/11

<trackbot> Created ISSUE-20 - Https://github.com/w3c/web-annotation/issues/11. Please complete additional details at <http://www.w3.org/annotation/track/issues/20/edit>.

azaroth: community could make a sub-property of hasTarget, but would be best if we understand why and see if we can accommodate in the model without having to create sub-property.

<azaroth> Link to the issue: https://github.com/w3c/web-annotation/issues/11

fjh: extensibility is part of this question, but we should defer for now.

<fjh> 3rd case, CSV

<paoloC> https://www.w3.org/annotation/wiki/Annotating_CSV_Data

<ivan> s/CSC/CSV/

bigbluehat: Annotating CSV on the Web
... we don't currently reference in our data model
... the CSV WG has registered a mime type with IANA
... fragment identifiers are pinned to media types
... selectors in our current data model are not tied to media types

<fjh> https://tools.ietf.org/html/rfc7111

ivan: CSV WG does allow for annotations, but don't currently define exact method.
... CSV WG might use rfc 7111 as way to identify target
... CSV files may allow comment lines
... 7111 refers to data without the comment line

<Zakim> azaroth, you wanted to note conformsTo

ivan: this is to keep row number references from being skewed by comment lines

<azaroth> http://www.w3.org/TR/annotation-model/#fragment-selector

azaroth: regarding reference to media type is allowed as part of fragment selector, if we add 7111 does that solve the issue?

<bigbluehat> <#annotation> dcterms:conformsTo <http://tools.ietf.org/rfc/rfc7111>

azaroth: i.e., using dcterms:conformsTo on the fragment selector

<azaroth> ISSUE: Add RFC 7111 to Fragment selector table ; and look for other specs

<trackbot> Created ISSUE-21 - Add rfc 7111 to fragment selector table ; and look for other specs. Please complete additional details at <http://www.w3.org/annotation/track/issues/21/edit>.

ivan: 7111 should be included in our table as one of the media types that can be associated with fragment selectors

paoloC: how do we handle the comment lines in practice

ivan: it depends on the parser. some parsers deal with comment lines one way, others another

paoloC: this has consequences for annotating scientific data

ivan: 7111 is silent on this
... its a mess, there are CSV files that have comments
... so the only advice is that CSV files should not have comments.

<fjh> could add note to document that comments should be filtered out first before processing…

paoloC: should we add a note of caution with regard to CSV fragment identifiers?

<azaroth> +1

<fjh> +1 to add warning note about comments

ivan: we should treat 7111 fragment identifiers as black boxes
... are the examples of media type fragment identifiers only examples?

<fjh> ISSUE: 4.2.1 clarify if fragment specification table is normative or non-normative

<trackbot> Created ISSUE-22 - 4.2.1 clarify if fragment specification table is normative or non-normative. Please complete additional details at <http://www.w3.org/annotation/track/issues/22/edit>.

azaroth: yes

<azaroth> +1

ivan: they are not marked as non-normative and we need to do that explicitly

bigbluehat: agree should be clear these are examples (non-normative)

<fjh> ISSUE-22: on data model

<trackbot> Notes added to ISSUE-22 4.2.1 clarify if fragment specification table is normative or non-normative.

bigbluehat: should we add advice that you shouldn't use 7111 fragment identifiers when annotating CSV files that have comments?
... knowing what you are annotating should help you decide what kind(s) of selectors to use -- i.e. which will work best.

<bigbluehat> +1

paoloC: another use case relating to text mining

<azaroth> +1

<Jacob> +1

paoloC: one big chunk of annotations I have created come from text mining
... sometimes when tagging the tag is an exact match other times it's a broader tag
... e.g., you can tag with exact name of cancer, or you can tag with cancer in general
... there are different reasons to do each
... so AO borrowed skos:exactMatch, etc.
... if I want to encode this distinction in current data model, how do I do so?
... what is our understanding of our use of skos?

azaroth: I agree that if we are using skos:related, or skos:closeMatch, we should also be able to use broader, narrower, etc.

<Jacob> +1 for social web discussion on list

<ivan> +1

azaroth: I think personally that this use of skos is fine, but not certain degree we should talk about hierarchical taxonomies in our specification.
... we could be clearer about how you might do exact match or close match, but we should be careful not to redefine skos.

paoloC: okay with that, but skos:related is not a super-property of broader or narrower. Could create issues.

<fjh> much thanks to TimCole for scribing and thanks Paolo for leading the use case discussion

<azaroth> +1 to Paolo's expertise there

paoloC: otherwise fine with idea of using skos more.