Annotation WG F2F, Sapporo, 2nd day

<azaroth> scribenick: csarven

ivan: Cleaned up the minutes

<azaroth> http://www.w3.org/2015/10/25-annotation-minutes.html

<azaroth> Minutes from yesterday ^^

ivan: URL refers to the 25th of October, but it was started in 26th in JP TZ
... err 27 here in JP

azaroth: Ann came up to reorganize the agenda.. to move the Social API discussion to the afternoon. To start with the non-social stuff in the morning. To collaborate with Social WG in the afternoon

Review Model Issues

azaroth: In the issues list...

<azaroth> Issues: https://github.com/w3c/web-annotation/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Atpac+label%3Amodel

azaroth: I have talked the outstanding issues for TPAC
... I propose to start at the bottom
... We don't have to dig down to the technical details. Mostly about if we are going to reach this or not

<bigbluehat> sorted by oldest https://github.com/w3c/web-annotation/issues?q=is%3Aissue+is%3Aopen+label%3Atpac+label%3Amodel+sort%3Acreated-asc

azaroth: Issue #8 first
... Came up long ago - early WG calls
... Some Annotations are generated for particular purpose or intended audience
... Annotation be able to express what that audience is

<ivan> issue 8

azaroth: This Annotation is intended for this audience... e.g.,students
... Audience in schema.org .. has been adopted by IDPF ... and some interest in other communities

Ira: Is there a provision to hide some of those?
... An obvious UC for this audience is.. hey, this is team-only comments

shepazu: We don't have an auth server for this

timbl: We were talking about earlier.. annotations being channels.
... subscribe and aggregate channels
... e.g., student, teacher channels

shepazu: I agree with all that
... There is another UC, where you want to be able to say that this thing is regardless of the channels... b/c it is your annotation, you might want to have a little thing that says.. who is this intended for
... that could be anybody, or any number of people

Iva: e.g., Goths

shepazu: I don't think we should put it in the model
... it is essentially metadata

Iva: generic metadata tag

ivan: I think that technically speaking, the only thing we have to do is have one single property... if it is audience or whatever, which is completely open ended for whatever the value is and let the implementation figure that out
... we shouldn't define what those possible values are

shepazu: I'm not sure if we are saying the same thing or not
... I'm suggesting we shouldn't have audience at all
... may be useful for some people
... basically this is the metadata area.. put whatever you want in there
... okay so (walks to the whiteboard)

ivan: You are saying like a hook
... I'm not saying it is required
... it is up to you if you want to use it or not

Iva: Instead of specifying what it is but having a generic property - that's what Doug is saying

timbl: So use like a hashtag?

shepazu: Some people are going to send a straight web annotation and others will supplement wiht extra things

timbl: If it is shipped in RDF, you can do/put whatever you like

azaroth: For example, DPUB community has a specific audience, but it is the same concept for intended audience for this annotation

shepazu: What about outside of the academic community e.g., Goths?

<tilgovi> What stops anyone from adding schema:audience to their annotations already? I asked this on the issue, too.

Iva: ..Then what other buckets do we have to consider... as soon as you add one, then you have to consider..

ivan: We can say we don't do anything and leave it as it is... it is open-ended, people can add properties.. and they can do that. The question is where do we draw the line? The audience is one of those things where it is widely used if it is worst to call it out or.. we need ot draw the line somewhere.
... We did something like motivations which is sort of like the same thing.
... But we feel that it is common that we defined it

bigbluehat: We also have roles
... motivation on the whole annotation will be on the comment for whatever is intended.

Iva: So, it is sort of like a type

azaroth: There SHOULD at least be one motivation
... includes things like bookmarking, commenting, reviewing, tagging..
... previous systems, we used classes. but class hierarchy..

ivan: In this case motivation is in the same category of things

shepazu: I think that we broke out roles are that they are functional things.
... based on role something has

ivan: Motivation and Role are not the same
... Motivation on the Annotation..

shepazu: I think that the point is , what behaviour do we expect from the UA towards that thing
... I would like to break version 1 of the data model down to what specific actions the UA going to take for this thing.
... the we think that that's a strong enough UC

bigbluehat: .. how much do we provide in SHOULDs and MAYs
... b/c of the UC we found
... It shouldn't be core, but this is what we suggest...
... You as a JSON coder and drop this here and the keys out

Iva: I want to see the comments on the day 1 of this conf..
... to see the particular streams

ivan: I don't know if tag is the right property for using a single property for this
... literal or URI range

timbl: That's not very RDFy

bigbluehat: If we knew the developers, our extension model is already there to say that..
... this is a bag which you can put whatever.. or suggest things

timbl: if you want to extend this, there is an RDF.. in the JSON world, well if you want to extend it, all other JSON keys will be mapped into our ns
... So, in other words, if you add something random in there... call us and rev the spec
... if you add another key to JSON API.. then asking for global scope to change..

ivan: I have the impression that, this is the kind of discussion that we can carry on for several hours
... I propose for the next version of the document; clear feedback from the community
... we may come up with loads of other properties that we formally define.. essentially open ended properties
... we define, but we don't know if it will be really useful or not - need feedback from community
... I can't say ATM that RDF makes that cut.
... We have to draw the line somewhere.. and where the line should be drawn here, we can't discuss that now.

Iva: Instead of getting feedback from the community, this is the stuff that needs to come out how people will use this..
... e.g., hashtags before it became a thing.. organically came out and then specified later

ivan: I don't think we are contradicting
... These are the questions about the core.. we get feedback

shepazu: I would like to see it rise organically

azaroth: There is the EPUB folks, and their mapping of the ... schema.org. One required for them.
... (?) along the same lines. Two different communities asking for the same thing.
... Solution for hypothesis/Annotator...
... It is just the user adding in the tags
... labeling that in the model or more specific ways for it

shepazu: Haven't we traditionally, treating tags as ... (?)

bigbluehat: Annotions in hypothesis for tags is not entirely clear.. an arbitrary call
... I use them in different ways e.f., format comment, or resource.. and they are not technically associated but being annotation.

shepazu: Depends on precise you want to be

ivan: How should we move on?

azaroth: Consensus is that.. list as audience or list structure for poll .. which could be used.. however, we can also that we are not going to deal with it

bigbluehat: I think for audience, we should discuss again. Also bring up again for dumping ground other people to put
... model wise, for JSOn developer if they don't want ot use.. they can decide. They could be legitimate RDF graphs.

ivan: Lets separate audience stuff from the others
... we should document
... I would like to see a more precise proposal for the generic stuff
... Trying to get feedback from the community to see whether it is useful or not.. we should not close (issue 8) either way

timbl: You are looking for one annotation, and it got this audience column e.g., student, and click on that and my system knows
... For that, it doesn't have particular properties, the UI can find

azaroth: Okay, lets discuss later.

ivan: The word "tag" is overloaded even in this group

azaroth: Issue 18 (?)

<azaroth> issue: https://github.com/w3c/web-annotation/issues/10

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

ivan: I do understand the difference.. 80/20 cut situation. the annotation has an id, yes, this is annotation expressed in rdf, json-ld or whatever.. which is identrified this way.. lets not go there

shepazu: I see this valuable
... We should wait to see how much this idea is used out there before saying it officially in the core model
... By punting on it to see how the community does it.. but the community can come up with something different.
... that's an area they can decide how best
... rather than having exactly how to do it, we should probably accept that the UC is valid

ivan: That's what I said.

azaroth: The complexityu of adding it far outweighs

ivan: Then we get into the HTTPRange...

azaroth: Does anyone want to argue for it?
... or close?

shepazu: Can we have a tag for issues tag for 'possible future version'

ivan: postpone

shepazu: v-next
...

azaroth: Next up is issue 18

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

https://github.com/w3c/web-annotation/issues/18

azaroth: this is more of a vocab question than a model question
... at least two diff vocabs to express general class of a resource
... we have even reduced from SHOULD to MAY
... however, there is some interest using in schema.org
... resource classes
... compares to/as well as DC
... But really the issue is ... what the resource is for those classes

shepazu: I'm still inclined to prefer mimetypes

azaroth: Right, that is a SHOULD in the model
... assuming you are not saying remove Classes in the model

bigbluehat: there are some mediatypes which don't give enough

azaroth: e.g., you can use media fragments time based

ivan: I'm not even sure if you are right.. b/c a specific fragment is bound to a media type

shepazu: but the media type for animated gif and gif are the same
... depends on the implementation right

azaroth: erikmannens , Do you recall what happened?

erikmannens: Will check

shepazu: I strongly prefer schema.org

ivan: what is the current status with W3C on that?
... I don't know what the answer is

shepazu: the question is.. when we are referring to DC to schema.org... and we want to know can we normatively reference schema.org?

timbl: We can see it as a reasonable thing to request

shepazu: It is a matter of referencing an external resource..

azaroth: For the resources participate in the annotation ... e.g., i'd like to say the thing on youtube is a video.. but they might change that, what I do know is that that is a video..
... the target of the annotation is a webpage, and you want to display it as an iframe

shepazu: I think the issue is larger than that
... e.g., "for author"

timbl: The specific question is.. broadly classifying media
... we want interoperability
... in general err on the side that people understand everything

(or don't? .. slightly inaudible)

bigbluehat: schema.org is centralized

timbl: centralized
... on the other hand, you want it to be understood
... what you want is to get everybody moving together
... you are trying to get interoperability

shepazu: In that same respect, the odds that you are going to get w/ interoperability
... how broad is an ontology, how many things does it address, and how many sites are using it
... and within a short years, it is used more than DC

ivan: That's not true

bigbluehat: No..

timbl: There is a huge amount of schema.org stuff out there run by Google Search engine

shepazu: Not only Google

timbl: Right
... So there is a lot of code that uses DC out there
... so if you try to move all that code from DC to schema.org..

shepazu: I'm clearly not going to win this audience over

azaroth: We can look at another issue
... probably not going to make progress on that now
... Next up is issue 21

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

azaroth: 21 is somewhat of a protocol related topic
... the topology... and the annotation ecosystem
... if you have a same annotation that's duplicated over multiple sites
... should we make a reference between duplicate annotations
... to indicate whether to keep copies

ivan: I'm not sure I understand
... I'll explain what I don't understand
... an annotation is defined in a way that it should have its own identifier
... so if I replicate an annotation, but keep the identifier.. then it is conceptually it is the same thing.. just made a copy
... the id uniquely identifies that is annotation

azaroth: From pure RDF POV, you can always use the same URI
... when you add the HTTP layer... and available to be retrieved..

ivan: So you create a new annotation similar but with diff id
... not the same

azaroth: Should we maintain the provenance

ivan: Is it an extra information, which cuts the line necessity or not

bigbluehat: This gets tricky in regards of decentralized and moving the annotations around
... the original URI farther and farther as it moves around.. and it gets a diff URL even though it is pretty much the same
... but you are "getting a new URI"
... we are talking about moving an annotation around ... essentially the same annotation

timbl: You dl the entire the file and remember where it came from.. it now understands what the base URL is
... the other model is you copy and have a diff copy, allow people to edit it and don't care about where it came from

bigbluehat: Whether annotations are muted or not

shepazu: Another wrinkle to core topic is.. I can publish an annotation to multiple servers.. would they have the same id

ivan: Almost comes back to http14
... an id regardless of its location
... conceptually have the same thing when you just copy
... for the time being the model has a URI.. a single URI.. which is the id of the annotation.
... we have two concepts and the model has only one

shepazu: Is the URL inside the annotation?

timbl: 3.. do heuristics on it to come up with another id
... e.g., vcard is useful for things.. which means that you can squish it together.. syncing together..

Ira: I just don't want ot see diff.. 2) i want to see the annotation is really about the content that I'm seeing (the context is maintained) ..
... the question should be resovled, if i comment or reference, .. does that get propagated across
... lets say i only subscribe to one annotation server.. and not interested in the others
... from the users perspective

shepazu: Just to supplement that.. that says to me that the annotation is.. regardless of where it is published, it should have a new globally unique id

takeshi_: ... many become offline, or device, or website.. after when device is connected, so if we have diff uid, it is difficult to find
... it depends on how we synchronize the annotation

shepazu: Another similar case to offline, i have made 20 annotation on my laptop.. that's the only place they live.. and only I decide to share them.. whether published it to somewhere... and then the uid.

ivan: In the issue itself Paolo says that.. there are other vocab with prov. .. to add additional info e.g., derivedFrom
... if annotation server adds a new thing, they can track a new thing... where it came from.. so the provenance is there

shepazu: The market/community should decide

ivan: If you need to do that, use the PROV-O b/c it is there

bigbluehat: I would agree that, if they are legitimate
... So Social WG has does something .. like everything has an id.. inboxes go.. at various locations
... but when it moves around, and you store the location
... once the id is set, I don't want it changed

shepazu: How do you propose .. the only way to.. form the spec perspective, you should not change the id, isn't a valid annotation

ivan: That's the point.. if it is a diff annotation, .. putting there derivedFrom makes sense

bigbluehat: We should say that.. when my annotation moves from a to b, it should have the same identifier

Ralph: ...iff they have the same id

timbl: What's the UC.. when does the software need ot know

shepazu: If X publishes to 3 you could specify that two annotations are the same annotation iff annotation services, and I see in my sidebar seeing them.. and see all.. would be nice to see it only once.. having it collapse
... If I'm authorized to comment to post 2 services she is on.. and my comment to both
... This is a product decision and not specifically w/ the data model
... (Web Annotation data model spec)

azaroth: timbl considered rel=canonical
... the client should assign uid

ivan: I am unclear about thsi last point
... purely from an RDF POV
... the annotation is a resource it has its own URI
... why would I have to decide that it is a UUID?

timbl: No, you don't have to say that
... the moment you make annotation.. and give its shiny URI

ivan: I'm not saying you should not use uuid

timbl: MUST have an HTTP URI
... MAY have UUID
...

azaroth: Logistically, we take a break b/c coffee overrules :)
... Discussion around how to refer to Turtle... specifically on testing requirements
... I propose 15min to talk about that.. 11:30-12:00 implementations/demos, afternoon .. about integration with Social.. around protocol

Reorganization of the Model document

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

ivan: The way the model doc is done today is.. it defines the whole model.. and sort of has a duo phase
... obviously for two difference audiences.
... the proposal to cut it down into two. One URIs and RDF terms.. using same examples, and defacto standard way to show the vocab.
... a second recommendation for the JSON(-LD)
... and ns stuff will disappear from that
... so for different audiences for an easier sell
... if we have full testing for the JSON-LD manifestation, we are not required to have a separate testing for Turtle, because Turtle is not RDF, it is just a serialization, ditto for JSON-LD.
... so this simplifies our lives
... I apologize for the editors b/c they have to create two docs
... if at the end of a year, we have a relatively stable document, then syncing two docs should be easy.. maybe even with some tricks find common parts
... e.g., repeating some text
... this is roughly what we said this morning?

bigbluehat: Sounds about right
... shepazu's argument may be that there is too much RDF which could scare people

ivan: I'm not sure if I'd understand shepazu:-)

csarven: (shepazu is not currently in the room)

ivan: The idea is that the JSON-LD doc should stand by itself

bigbluehat: That might make him happier

<tantek> from the IRC sidelines, I agree, so much RDF in that document either scares (or glazes over) most web devs

ivan: I can't judge whether the figures/graphs would scare anyone

Ira: I think bigbluehat 's point is good

bigbluehat: If we leave the JSOn-LD that would make most happy

ivan: The fact that the @context is there...

bigbluehat: I don't mind introducing people to JSON-LD e.g., here is what @context is ...

azaroth: My experience with JSON devs is that, they can handle it as long as you point them to it

<tantek> optional vs required @context may be a good topic for the informal joint Annotation/SocialWeb WGs meeting this afternoon (has a time been set?)

bigbluehat: Google does this all the time e.g., inbox actions with schema.org
... they'll copy/paste
... whatever is needed

azaroth: What will we call the non-model thing.. annotations in JSON?

bigbluehat: At the top of the document basically?

azaroth: TR/slug
... if you Google for it..

bigbluehat: We have annotation-model
... web-annotation doesn't equal annotation model

ivan: We have to change the shortname.. can we do that Ralph?

Ralph: yea
... same document

timbl: Same document you can have two names ;P

azaroth: All good
... now implementations/demos..
... csarven, bigbluehat , takeshi ... 10mins each?

csarven https://github.com/csarven/linked-research -- temp: https://csarven.databox.me/Public/dive-into-linked-research.html

<Zakim> Ralph, you wanted to comment on a use case for embedded annotations

Alignments to social web activities

azaroth: the annotation WG deliverables has 3 parts
... one of them is the protocol, which uses LDP
... discovery is important -- how does a client know where to send the annotations?
... notifications is another thing we're interested in; it could be based on Activity Streams (AS2)
... finally, search -- I haven't seen a lot of work so far
... given a collection of annotations, how can I find the annotations I'm interested in without getting all the other annotations
... the final deliverable is the FindText API
... basically, find content that the user wants to annotate

tantek: as the only SocialWeb WG chair here, let me give you an overview of our work
... 1st thing is the AS2
... 2nd area is a social API, to allow clients to communicate with servers
... 3rd area is a federation protocol
... the first area involving AS2 faces a big challenge; we're not going into a green field, since RSS and Atom are the defacto standards
... also, none of the big social players (Facebook, Google, etc.) are participating in the WG
... those companies are notorious for not cooperating (see. the latest fight between Twitter and Instagram)
... these silos have their own APIs, which are simple and minimum JSON APIs; this also means there are a lot of developers that use them
... we have some interesting activity going on: microbpub API, pump.io (activity pump), and there is the Solid API
... we have people working on all 3 fronts, which is good
... there's also work being done on webmention, in the federation scope
... we're trying to see if we can ship something simple to implement and use
... AS2 is an example; we are trying to make it compatible with JSON-LD but not require JSON-LD

ivan: when you mention API, is that a RESTful API?

tantek: that's a good question!
... we had use cases that demonstrated that REST is not always useful
... some statically hosted web sites don't need REST
... webmention and micropub work like this

[people arguing about the use of the REST term]

ivan: I want to know what you do that involves http

<npdoty> Link header or <link> tag, to be clear. for a static site, the tag can be even easier

shepazu: it seems that you guys do have implementors (even though they're not top tier)

tantek: we have no expectations that the big players will get involved
... we do our spec issues and discussions on github (less so on the mailing list)

shepazu: I'm not really concerned about what channels you use, I just care that you have implementors interested in doing the work
... e.g. a guy from Diaspora* said they are interested

tantek: yes

bigbluehat: we're just interested in collaborating, to see where we overlap

ivan: I fully understand and I also didn't expect the big players to be interested in your group, but I wonder who is your constituency

tantek: the target audience depends on who you speak to
... IBM is the only member who is working on a real product
... on the other hand, most implementors are not interested in AS2, they want something simpler
... people want something simple, less or equal to implementing RSS/Atom

<annbass> No, guess not

<annbass> Just saying

<shepazu> https://lists.w3.org/Archives/Public/public-socialweb/2015Oct/0056.html

tantek: IBM wants to ship a product

azaroth: in terms of points of alignment, how volatile do you think AS2 is going to be?
... we'd like to avoid redefining the vocabulary in our own namespace

tantek: if you can provide example of annotations using RSS/Atom, that would be good input for the SocialWeb WG

ivan: we were wondering about how stable your vocabulary is (e.g. collections)

azaroth: for instance, we would like to use AS2 ordered collections instead of relying on LDP paging

tantek: an ordered list sounds like a feed to me

azaroth: moving forward, if we want to show support for collections but collections will be removed from AS2, then the two WGs can collaborate on the vocabulary

tantek: when we have a use case that uses a collection, implementers are always looking into ways of not doing it

bigbluehat: we do have a use case that would benefit from AS2 collections
... for potential implementors of AS2, hypotes.is is a candidate

tantek: you mentioned something about notifications (where to send an annotation and discovery)

azaroth: yes, basically how does the server that receives an annotation from a client notifies the interested parties about the new annotation?
... PuSh is a possible solution

tantek: the webmention protocol allows any URL to mention any other URL
... and also add a specific type of interaction

ivan: is this a spec?

tantek: it's a protocol that is currently being developed within the indieweb camp

<azaroth> Source = <annotationURI> ; target = <targetURI>

[people discussing the webmention protocol]

<csarven> See also http://csarven.ca/webmention which proposes a property parameter in addition to be used with source and target

ivan: in our protocol document there should be an informal description on how it works with webmention

tantek: there's also an extension called "vouch" which we're working on, that we hope will be used to fight spam

ivan: what is the current status of vouch?

tantek: it's implemented by several sites, but it's not a requirement for webmention

csarven: there's another extension that I've proposed, which uses the property parameter
... it's just a way to add a property to describe the type of relation (like an RDF triple)

ivan: is it necessary for the annotation documents to specify any level of security

bigbluehat: webmention expects the target to scrape the source document and find the mention

<npdoty> https://github.com/converspace/webmention

<tantek> btw: https://indiewebcamp.com/Webmention

<tantek> npdoty - that's out of date

ivan: do you plan to add a security extension in your document (the SocialWeb WG spec of webmention)?

<tantek> https://indiewebcamp.com/Vouch

tantek: the intent is to keep the spec modular

<tantek> https://indiewebcamp.com/Webmention#verifying_private_webmentions

tantek: we're also looking into doing secure webmentions

<npdoty> tantek, where is the more recent version published? we've been discussing bugs in that github repo and I've been relying on that document for implementation

<tantek> npdoty: wiki is canonical

shepazu: what's the relation between the Social API and webmention?

<bigbluehat> npdoty: pretty sure we'd need something more permanent / immutable to anchor our spec on fwiw

<bigbluehat> tantek: ^^ rather

<npdoty> whoa, well, the github document is a readable spec :)

<rhiaro_> http://w3c-social.github.io/SocialAPI/socialapi

rhiaro: there's a section in the editor's draft (Social API) re. webmention

<tantek> bigbluehat: don't confuse the CMS (wiki vs github) as "more permanent / immutable"

<bigbluehat> npdoty: right. it's a spec, but it's not canonical until published--and therefore immutable

<tantek> on the web things are always published, a la WHATWG living specs

<azaroth> scribenick: bigbluehat

deiu: this stuff is relatively new
... so it's not ready to be normative
... we want to build a system that folds into how LDP works
... you can have notifications inboxes
... inboxes are just a container--into which clients post notifications
... each inbox can contain as much data as you want
... clients will then interpret the contents and take what they need from inside
... it's not limited to just source & target
... you can have a lot more metadata about the notification
... you can also have secure notifications
... we have access control per inbox
... you can make them append only and state who can append
... you can have many of these inboxes as you want
... you can have one global inbox, but you can also have one inbox per application or per page that you publish
... ever resource, in theory, can have its own inbox
... for notifications

shepazu: so. for example. someone creates an inbox--annotate corrections here, and annotate comments here
... meta tag, header or something for discovery

deiu: yes. you can even got really meta, and ever annotation can have it's own inbox

shepazu: could you annotate the collection?

deiu: yes. :)

tantek: perhaps a demo to see of the stuff all working
... we have a demo of Social Web Acid 0

<tantek> https://indiewebcamp.com/SWAT0#Video

<deiu> scribenick: deiu

[tantek showing the video on this laptop]

<annbass> video is of Aaron Parecki demo'ing SWAT0 examples in Portland IndieWeb 2015

<annbass> ben_thatmustbeme posted a photo of Aaron, and tagged him

<annbass> therefore Aaron was notified, via webmention

<annbass> Kyle commented on the photo, that Aaron looked good ... and Aaron received another notification

<annbass> there was yet another comment (I think from kevinmarks), which also caused a notification to occur

[coffee break]

Alignments with AS Collections

azaroth: [talks through abstract collections model on whiteboard]

ivan: we're there with the abstract data model, we just need a few paragraphs to turn it into json or rdf

bigbluehat: could we create definities from activitystreams, copy them into a new spec and give it a name, like 'json collections' and define it as a collections spec?

ivan: or even put it into a section in the model
... we have an rdf model, it translates into json, it can be part of the protocol

azaroth: section blah, blah blah... protocol refers to this

bigbluehat: I wonder if we spec it as a separte things o we can move on
... lots of peopel need collections in json-ld, not just us

takeshi: should I assume that collection is an annotation data collection, or kind of rdf graph?
... I want to put any types of data into the data store
... If we use url as a key, we could have the annotation data and also other data types

ivan: they could be either uris or full

takeshi: so in this case we can get any types of node that has that url but I think that some elements in page zero could make an entire graph, but there might be some missing node
... to make the complete graph
... for instance, if I have annotationa nd also website details in a different format, different datatypes, we can see the annotation data on page zero, but we might get the detail delivered on page 8
... in that case our expectation is, I would like to list say bookmarks with details, we can put some type of url and title in a bookmark, but you cannot show the details

bigbluehat: not without separate requests per annotation

azaroth: we need to address the use case where all of these are limited to annotations
... and only annotations
... in the collection
... so the need to put the details about the target into the annotation

ivan: it depends, if we go the way ben said, we do it in a way that other people can use it as well, we should not put that kind of restriction

azaroth: I agree
... and so to clarify, what we could do is specify it generically and then say here is the expectation for annotation servers, that everything will be an annotation

bigbluehat: further constrain in the protocol
... this guy has this thing called 'zoom', scenario where you have an annotation that references another url, so potentially you're dereferencing over and over
... so you can specify zoom and say how deep you want to go
... but potentially this is an implementation detail
... it's up to the implementor what to return, multiple types or just one type

takeshi: it will work
... in that case, you might get the same number of entities in each page but volume might be different

bigbluehat: if annotations returned are just body url and target url you could have loads
... we should provide for that, and provide for a scenario without that

azaroth: that's why we don't want client requesting page size
... varies what's reasonable between servers
... if we have bookmarks which are small, server can say here's 10,000 of them, because it's only half a meg

bigbluehat: one of the things that couchdb does is it doesn't have page numbers, it just uses offesets and limits
... because it's potentiallyr eceiving writes while you're asking for an index
... so to declare a total page count is foolish, it changes on every request
... and contents of each page might change
... to get to next page, you don't say give me page two
... so you say start at this annotation url and give me eg. 10 more after that
... Some way to say get me to the next page, starting with whatever you currently have

azaroth: follow your nose to the next page

bigbluehat: exactly

azaroth: you never need to understand the url construction

ivan: so first one, static annotation lists/sets
... came up with multiplicity constructs, in there this is overkill

azaroth: oa:List is total overkill, never used with millions of things

ivan: so we should be careful, the first is not a use case for this structure
... it's just a list that we can include if we really go there with multiplicity constructs
... second, response from the container, and third search response, they're fine
... If we map that to rdf then of course we get to the disagreeable features that even in sparql 1.1 querying lists.. past(?) expressions essentially can be used to describe a list. Formally sparql has solved this
... the only problem is I don't know what the implementation status of this is in sparql servers these days

deiu: I don't know, it's hard to tell

ivan: it makes implementation much more complicated
... correction: property path in sparql
... like regular expressions
... a path from a to b, but in between are these things that should be in the path
... I don't know in advance the size, can have *
... I know there was a certain level of pushback because it maeks implementation more complicated

csarven: there was some recommendation that it's okay to use property paths because you can skip some of the variables that you can define in between

ivan: the point is that lists are not any mroe the big no-no when you do sparql

azaroth: that's good. That said, I don't think we need to talk about sparql

ivan: I know, I'm just saying that if we model it in rdf, one of the reasons why people don't use rdf lists is because once I get to sparql I have problems

azaroth: there are two answers, one that you've given, sparql 1.1 sovles it
... the second is that primarily all of our queries are going to be at the annotation level, the actual list construct is a serializaiton of a search response, rather than a construc that's maintained in a triplestore
... so you'd never actually need to search that

ivan: I understand, that's true
... It's mroe for the first usage
... And there is one mroe positive.. dont' use rdf/xml
... because there it becomes much more complicated to dlists
... but it's your problem if you use rdf/xml

deiu: please remember what ivan just said about rdf/xml in ten years when people say the same thing about json-ld

rhiaro: it's possible that if you spec collections separately and it's simple, social could use this

ivan: if we spec it separately, it would be short

bigbluehat: I agree

azaroth: in the iana relations list, they already have first, last, prev, next

ivan: there has been an enormous discussion on whether using iana terms in rdf with stable uris is somethign we can/should do or not
... look at the discussion.. mark got into a huge discussion with erik wilde etc
... it maybe solved, but if we do it now with our own namespace, but in the future iana solves that it's okay

bigbluehat: also there's collection and item as link relations in an rfc

azaroth: the atom rfc defines a uri for all of the link relations and it's not good enough?
... page 22

ivan: I have gone through that but, even more honestly, I'm not intersted in that discussion
... it came up whether we can refer to iana uris in an rdf session and it folded into discussion about how we find rel relations, and then into how html5 does it, and there's this whole big thing that is happening with somewhere in the middle the question can rdf safely use a uri for thos erels

bigbluehat: remains to be seen

ivan: i've seen just now that mark had a discussion with timbl today, they tried to get to a point with cleaning up iana registration
... We can always change those terms if they are stable before we go to rec.

azaroth: it's not like we're going to rename the json, so it's a case of changing the context

ivan: we should put this explicitly as an isseu in github
... for the first version we don't want to carea bout that

azaroth: So, next one. I don't want to design a query language.
... Ray suggested on a call (?) ..something crazy... there's no other query language... so what are we going to do?
... without a query language there's no interoperability

bigbluehat: can we recommend or maybe even spec that people use uri templates mapped to json terms as we defined the terms in our json-ld such that they can have wahtever url structure they want and they can use {creator} in their query parameters

ivan: I don't understand

bigbluehat: we say maybe that through a link relation of annotation search endpoint or something, it's expected to be a uri template, and the keys used in that are json terms used in our specification
... so given an annotation with my name on it, you could click it and i twould do a search

ivan: the whole syntax is so much geared on building uris with parameters and queries etc, which somehow.. it's not made for querying

bigbluehat: that uri could contain a query, just in as much as you can pipe sparql or linked data fragments into a thing
... it doens't matter to the web annotation world what the uri does or looks like, you could have an sql statement in it if you were really nuts
... but you could pass in known terms

ivan: isn't it then even more simple to say that we do not define any query language at all, we leave it for future releases
... the only thign we say is a specific implementation can offer a certain query language
... what we require that the return ona query should be of this format
... you can use a sparql engine or thing layer around it, and the query is a sparql query and what your eply is this

bigbluehat: want to say this is where i can send values encoded as a uri, and i'm going get that back
... whatever else is in the uri template is up to it, but I know as a developer if I get rel=annotation-search I can fill it in with the target url or wahtever I can get back a collection that relates to that key value pair
... does that make sense?
... discovery related, not search related

azaroth: I believe most common use case of search by target is there are a lot of different locations in the structure of an annotation where you would find target, so what key would you use?

bigbluehat: target, source, scope

azaroth: also problematic searching for keywords in the body

ivan: one step beyond what I said is to say there is no standard thing, and maybe somebody could put together a note or an informal appendix etc giving some examples of using the query language you refer to if that's what they use
... servers MAY do query this way, MAY do query this way, showing the various possibilities depending on what tool the implementation uses for the environment
... to say we have thought about it but there's no reason for us to choose
... These things do exist, we cannot standardise any of them

bigbluehat: the one exception we might make is search by target
... hwere potentially you might want to say as the publisher of the target, you can find annotations that I've published that I know about, that relate to me, I'm passing my url to this endpoint that will give me this feed of annotations for this documents

ivan: how would you do that?

bigbluehat: I wouldn't want to define a query parameter, but I would be happy to define a key name in a uri template
... a link header, or a link in the markup *draws on whiteboard*

ivan: so what we would define are variable names in the uri template to correspond
... we can make it easier to say if we use url templates in your queries, then the name of the json-ld terms should be used as variables

bigbluehat: exactly
... we will have to pick differerent / higher level words
... because the structure of our json is complex, the actual value of target could be in several places
... we define a few keys, maybe even one
... this is the every day use case

ivan: it's very funny to me if we define this and only these things normatively

bigbluehat: as a developer, I want a place to put my search terms and get back results

ivan: if we do an informative doc refering to search... making only that line normative in a sea of informative information seems very strange

bigbluehat: i agree, but as a developer I need to know how to ask for my annotations
... So it's not a requirement?

ivan: they will use informative recommendation
... but we don't need to make a formal rec

bigbluehat: hydra already defines paged collections. It's not done, but it's got all the keys we just talked about

azaroth: it's a CG with no normative status

bigbluehat: if we defined a collection thingy they might reference ours

ivan: we should contact them

bigbluehat: I'd like to include them to help get it right

takeshi: how many characters can you fit in a link header

bigbluehat: at least 256

deiu: there's an rfc for that

takeshi: something about encoding subgraphs

ivan: I don't know the asnwer
... all this is informative anyway
... you are right, one more reason not to standardise that

azaroth: now that we have at least some agreement, we should move on

Future plans, F2F

azaroth: input from observers welcome
... do we think it would be valuable to have another f2f, when and where?

ivan: we should get a very good idea and pencil in our agend a period without making a formal decision now
... but we have to realise that the reason why I think it will probably be very useful becasue now is the time when we will have to plan more strenuously
... these days having charter extended etc is more difficult than it used to be
... if by the time charter expries you are in CR and you have implementations and you can get feedback, then an extension is relatively okay
... but we have to be very careful to go there with CR published and not before
... October 1st is our deadline
... Ideally we should have rec published them
... Having a CR is realistic if we are careful
... Having a f2f where we, among other things, we really dot the i and cross the t, this is important
... in order to have CR in september

shepazu: when is iAnnotate?

everyone: don't know

bigbluehat: last year in april, but not started planning for it yet

ivan: maybe it has nothing to do with it, I do'nt know, but this year at the last minute books in browsers (?) was cancelled

bigbluehat: not related

shepazu: from the perspective of fairness, we have had two or three meetings in the US, both west coast
... one in Japan
... I think it could be appropriate to try to have a meeting in Costa Rica... or Europe. Or North Africa

ivan: this idea of making it in europe, I may be wrong, iAnnotate was considered in europe
... but we don't have an answer
... That might be the ideal setup

bigbluehat: Frankfurt book fair

ivan: in october, too late
... Readium have set up lab in paris
... want to do some sort of public event in paris in march
... I don't know dates yet, but we will know them when they're settled
... The ideal would be iAnnotate, that's highest priority. But if it does not come to Europe, then trying to bind to event in paris
... additional plus is that w3c has office in paris
... ideal time is March
... we will know about IDPF event in a month
... but if it doesn't, we are not bound to paris

various: talking about berlin

shepazu: we should definitely try to shoot for europe, anyway

ivan: charter exprires 1 october, having a meeting at tpac only makes sense if we need an extension
... if we are alread in cr it's not necessary

shepazu: we should absolutely meet at tpac

ivan: we have to have cr for all our specs that we want to ship in the first year

shepazu: I think i twould be good to have the next set of specs already started

bigbluehat: is that enough time, if we met at tpac, to make anything omre than github issues

ivan: if we get the current first round of documents into CR status then getting an extension of the current charter of say 6 months is probably not an issue
... In those 6 months we can manage CR, and have little to do
... And in that case, we can use the 6 months to handle CR etc, and essentially make a charter proposal for a recharter
... If we plan things that way, then meeting at tpac would be essentially on rechartering
... a viable option

azaroth: +1

everyone: noises of agreement

shepazu: I tend to think that this group has more to do
... and we're not going to get everything done in the next year
... that means we need to collaborate with other wgs

azaroth: no objections to that