#cwebber2eprodrom: and we're ready to move right along.
#cwebber2eprodrom: one note about this week's agenda is that we had some agenda items from last week that did not get handled, so according to the FIFO procedure we're following, we have now moved them all to today's agenda?
#cwebber2eprodrom: great let's work through our list
#cwebber2eprodrom: a couple have come from elf, is elf on the call?
#cwebber2Arnaud: the first few are from last week because elf was not on
#cwebber2jasnell: I'm pulling it up now to look at the list
#cwebber2Arnaud: if elf is not on, we will skip again
#ben_thatmustbemeThe Blog object type probably rolls in to the extension vocab discussion
#cwebber2tantek: didn't see him dial in, don't see him on present list from Zakim
#cwebber2eprodrom: I'm not sure we need the proposer to be here to deal with these. should se address now or wait till elf is here? my feeling is to wait, but we may pass off for multiple meetings
#cwebber2tantek: if james has a succinct resolution to propose, otherwise I'm ok with postponing
#cwebber2jasnell: I have my own biased opinion, best to postpone
#cwebber2azaroth: I disagree with sandro's interpretation... there's clearly a parameter in the media range, don't see why you couldn't fit in a parameter. If that is true though, that's something to keep in mind though
#cwebber2akuckartz: last argument was put forward against json-ld media type was problem of list of lists... even that is not against json-ld + profile
#ben_thatmustbemeI honestly do not care what the media type is so long as it is unique, and preferrably only 1 media type
the_frey_ joined the channel
#cwebber2eprodrom: it sounds like you have a no-compromise idea, what you proposed as as a process is that there is a list of reasons for having a media type for activitystreams, and those will bve refuted one by one, and when th full list is completed, that's when the wg handles it
#cwebber2akuckartz: I'm not against it, I don't see the reasons in support of a new media type
#tantekI don't think this is worth more time frankly, so much time has been wasted on such plumbing. Perhaps we can do a strawpoll to see where the group is overall?
#cwebber2akuckartz: I'm not against comporomise if necessary
#cwebber2eprodrom: could you sketch out to see what way you think the w3c should go forward? would it be just json-ld with profile?
#rhiaro_and wait what about for people who aren't using json-ld..?
#Zakimsees eprodrom, jasnell, cwebber on the speaker queue
#cwebber2akuckartz: yes, then we could have just json-ld... it's more effort than to handle profile
#bigbluehatthere's nothing preventing the use of the application/ld+json media type being used by those who want to...the document could still use the AS2 @context value
#cwebber2eprodrom: to ack myself, I'd like to ask james if we're dealing with multiple fallback media types, should we put application/json on that list
#azarothq+ to note application conformance re list of lists
#rhiaro_cwebber: I think we're as close to consensus as we're going to get on this
#rhiaro_... It seems fromt he LD side we're going to be able to have a guarantee that things can be in an LD format
#rhiaro_... and having an alias to a profile is great
#rhiaro_... the microformats community doesn't necessarily want things to be JSON-LD which is fulfilled by this
#rhiaro_... Seems like we're in a good space of both sides being happy
#rhiaro_... In response to the previous questiona bout the justification, there has been a lot of conversation in thsi group who don't necessarily want to view things as LD
#rhiaro_... and want to have a fallback where they can guarnatee that things are simple json
#rhiaro_... and being able to provide a way to say that things are handled here and that is handled as the profile
#bigbluehat+1 to the proposed comprise and for moving forward
#jasnellthe proposal is to say that implementers SHOULD treat application/ld+json; profile="http://www.w3.org/ns/activitystreams" as being equivalent to application/activity+json
#jasnellbut that application/activity+json is the media type for AS2 documents
#jasnellPROPOSAL: the proposal is to say that implementers SHOULD treat application/ld+json; profile="http://www.w3.org/ns/activitystreams" as being equivalent to application/activity+json, but that application/activity+json is the media type for AS2 documents
#melvster0 may not be a stakeholder so wont state a view, tho I've not seen arguments in favour of application/activity+json so it seems a strange vote
#cwebber2akuckartz: you can overrule my objection but I'm not convinced and I think it's the wrong decision. You can overrule
#sandroPROPOSED; the media type for AS2 is application/ld+json; profile="http://www.w3.org/ns/activitystreams" and implementation SHOULD treat the media type application/activity+json as equivalent
#KevinMarksIf json-ld can't support lists of lists it needs to be fixed
#cwebber2cwebber2: again I think we're going to lose an opportunity
#tantekalso what wilkie said - it becomes much harder to go pitch / ask developers to implement something supposedly simple JSON but says MUST support JSONLD mediatype.
#cwebber2sandro: do you think you understand where these -1s are coming from
#csarvenKevinMarks That argument has 0 barring on what's being discussed.
#tantekalternatively we could propose a straw poll on *only* "application/activity+json" for the folks who prefer "just one mediatype" if they would like to consider it
#cwebber2RESOLVED: the proposal is to say that implementers SHOULD treat application/ld+json; profile="http://www.w3.org/ns/activitystreams" as being equivalent to application/activity+json, but that application/activity+json is the media type for AS2 documents
#tantekmelvster lots of W3C RECs are non-starters today.
#sandromelvster, not every W3C Rec is welcome in every context
#cwebber2jasnell: something that's not core but should be defined, basically
#melvsterfor the record I dont believe this vote reflects the consensus on the wiki and was an example of vote stuffing ... im not enough of a stake holder to make an objection tho, right now ...
#cwebber2jasnell: here's a link to a strawman draft
#sandromelvster, in voting mostly what counts is if someone is willing to lie in the road. That's what matters, not what people think on the wiki.
#cwebber2eprodrom: what about making this as any kind of ? for the core
#cwebber2jasnell: i could address that if I understood it
#cwebber2eprodrom: instead of 3 docuemnts, we have 2 documents, one with core classes and types, secondary doc is the extension
#tantekq+ to suggest dropping all the named collections as wilkie said, and leave it up to those that support those collections to put forth an extension draft for consideration as an ED
#Zakimtantek, you wanted to suggest dropping all the named collections as wilkie said, and leave it up to those that support those collections to put forth an extension draft for
#cwebber2RESOLVED: move Folder, Album, Story out of core into separate extension vocabulary
bengo joined the channel
#cwebber2eprodrom: we are digging deep into AS2 and since we have good progress, I suggest we take one more AS2 item before going on to the invited expert stuff
#rhiaro_so you can see when you have an object, which collections its in
#cwebber2jasnell: like I said last week, we used to have a memberOf property, but it seems like nobody thought it was needed, so was dropped in an earlier revision. There's other vocab terms that could be used as extensions for the same purpose
#rhiaro_I can live with whatever on this, it was just a thought
#cwebber2jasnell: in any other use case.. I think there's no proof of need to do this
#cwebber2jasnell: I'd say it's an optional thing, I'm +0 on it
#wilkiestrict specified ontologies are surprisingly unimportant. I can only see them being used for collection discovery of some kind. I'm indifferent.
#cwebber2csarven: hi, I think there's a big list of partOf members, make sure inverses are in place, let's reuse existing terms... that's just kind of a cleaner approach
#cwebber2jasnell: we decided quite a while ago that AS2 should not depend on any other vocabulary. I have no problem as a best practice for implementers, but don't want to spec saying they should or must
#cwebber2jasnell: yes we decided there would be no nominative dependency on another vocab, we already say use vcard if you're gonna do that... would probably be safe to say should use dc terms, just don't make it a requirmement
#rhiaro_cwebber2: we have some people sitting on the possible IE list
#rhiaro_... and I know we have someone who is eager to implement
#rhiaro_... and we don't want to lose the opportunity
#rhiaro_... I know there are people who look interesting there, but specifically the ownCloud people have emailed me asking what they can do to get inovled
#rhiaro_... Would be a shame to lose them while they're keen
#rhiaro_eprodrom: The chairs today thought that the queue was empty
#ZakimAs of this point the attendees have been Arnaud, csarven, rhiaro, aaronpk, shanehudson, sandro, elf-pavlik, kevinmarks, wilkie, eprodrom, jasnell, ben_thatmustbeme, cwebber,
#ben_thatmustbemeeprodrom: i'll admit it is working out better than i expected. The roll over basically jump starts the next weeks agenda and gives everyone more time to digest it