Proposed APML Teleconference

[J. Trent Adams]

APMLers -

Following along on a thread discussing potential enhancements to the
APML specification, it seemed like a good idea to propose a
teleconference to have a real time discussion about next steps.

Of specific interest would be to make sure the APML 1.0 specification
is locked down, and what's necessary to close the books. From there,
it'd be good to chat about a roadmap for the next set of proposed
enhancements (eg. RDF support, etc.).

To get the ball rolling for a teleconference time, I've created a
quick Doodle poll to see if we can agree on a time:

http://www.doodle.ch/3ndykfxayhf4zutp

All you'll need to do is enter your name and checkbox the times you're
available. I'll take the most significant overlap in availability and
set up the call.

We'll probably use the teleconference setup used for the
DataPortability Project, so once the date/time is settled, I'll send
out the dialup information. You'll be able to call in via phone or
Skype.

Looking forward to the call,
Trent

---
J. Trent Adams
=jtrentadams

About: http://www.mediaslate.org/jtrentadams/
Follow: http://twitter.com/jtrentadams

[TSchultz55]

Trent,

Awesome. Thanks for initiating this! I've added the times I'd be
available for the discussion on Doodle. I'll bring with me a few
talking points for this meeting.

Looking forward to it.

Regards,

Tim

[Paul Jones]

Trent,

Given the very international participation for this specification, there will need to be a clarification for the timezone that Doodle is actually referring to. I can't actually find any indication of a timezone on it.

Thanks,
Paul

[David P. Novakovic]

Yep. We are +10 here, i'm guessing trent is -8... plus there are a lot
of euros on here. need some clarification :)

[gdupont]

As soon as I get the timeZone data (I'm at GMT+1), you can count me in
through phone at least...

gdupont

[J. Trent Adams]

APML Crew -

I hear you about the time zone problem. For some reason I assumed
(yes, I know what that means) that Doodle would handle the time
translation based on your personal settings. Silly me.

I'm in Boston, so the times I entered are based on United States
Eastern Time. Based on my experience running the teleconferences for
DataPortability, I tried to select times that would work across the
globe. To help us remain in sync, here's a cheat sheet with a couple
key time zones called out:

GMT | California | Boston | London | Hong Kong | Sydney
12 | 5 am | 8 am | 1 pm | 8 pm | 10 pm
13 | 6 am | 9 am | 2 pm | 9 pm | 11 pm
14 | 7 am | 10 am | 3 pm | 10 pm | 12 am *
15 | 8 am | 11 am | 4 pm | 11 pm | 1 am *
16 | 9 am | 12 pm | 5 pm | 12 am * | 2 am *
17 | 10 am | 1 pm | 6 pm | 1 am * | 3 am *
18 | 11 am | 2 pm | 7 pm | 2 am * | 4 am *
19 | 12 pm | 3 pm | 8 pm | 3 am * | 5 am *
20 | 1 pm | 4 pm | 9 pm | 4 am * | 6 am *
21 | 2 pm | 5 pm | 10 pm | 5 am * | 7 am *
22 | 3 pm | 6 pm | 11 pm | 6 am * | 8 am *

* = Plus one day to the GMT date.

Soooo.... without rebuilding the Doodle poll based on GMT (which I
should have done in the beginning - shame on me), you can use this
chart to cross-reference from Boston time to GMT or your own.

http://www.doodle.ch/3ndykfxayhf4zutp

If, however, there's still confusion... I'm open to rebuilding the
poll based on GMT and redistributing it (along with a link to a useful
time conversion tool).

Mea culpa,
Trent

[Paul Trevithick]

Trent, you’ll be happy to know that Doodle has now added local timezone xlation support.

[J. Trent Adams]

APML Team -

It looks like we've got a rough consensus around a reasonable time for
the proposed teleconference:

WHEN: Thursday, August 7th at 10:00am US/ET [1]
WHERE: Skype +9900827041975640

You can join the teleconference for free via Skype, -or- you can dial
up via one of the following phone numbers:

Room Code: 1975640

US / Canada: 1-201-793-9022
Austria 0820 401 15470
Belgium 0703 57 134
France 0826 109 071
Germany 0180 500 9527
Ireland 818 27 968
Italy 848 390 177
Spain 902 885 791
Switzerland 0848 560 397
United Kingdom 0870 0990 931

NOTE: The above phone numbers are toll calls. I have a limited set of
toll-free phone numbers, if you need one. Ping me if you're strapped
for cash and I can hook you up.

The agenda is pretty open, so feel free to load it up with what you'd
like to discuss. For my part, here are a couple items I'd like to
touch:

* Introductions (simple hello & where you're from kinda' thing)
* What we need to do to close out APML v.1.0 (if anything)
* High level roadmap for next version (e.g. RDF)

I'm looking forward to chatting with everyone and seeing where we can
go from here.

- Trent


[1] For those of you around the planet, here's a cheat sheet:

San Francisco: 7:00am
Boston: 10:00am
GMT: 2:00pm (aka 14:00)
London: 3:00pm
Berlin: 4:00pm
Tokyo: 11:00pm
Adelaide: 11:30pm
Sydney: 12:00am (Friday, August 8th)

To cross-check I got these times right, or to look up another time,
here's a link to a complete chart:

http://tinyurl.com/5etgh9

---
J. Trent Adams
=jtrentadams

About: http://www.mediaslate.org/jtrentadams/
Follow: http://twitter.com/jtrentadams

On Jul 31, 10:43 am, "J. Trent Adams" <jtrentad...@gmail.com> wrote:

[Chris Saad]

Heya Trent - a number of last minute things has come up for a bunch of us who would like to attend. Can we re-do the scheduling vote and try again please bud?

Chris

--
Chris Saad

FaradayMedia - For Audiences of One
Particls - Are You Paying Attention?
Engagd - The Open Attention Platform
Media 2.0 Workgroup - Social, Democratic, Distributed
APML - Your Attention Profile
DataPortability - Connect, Control, Share, Remix

[David P. Novakovic]

To quote dr farnsworth, 'I am already in my pyjamas' and based on
Chris' email this isn't on tonight. I'll stay posted for the new time.

David

--
Sent from Gmail for mobile | mobile.google.com

[gdupont]

Any news ?

Is the telco aborded ?

On Aug 7, 2:42 pm, "David P. Novakovic" <davidnovako...@gmail.com>
wrote:

> To quote dr farnsworth, 'I am already in my pyjamas' and based on
> Chris' email this isn't on tonight. I'll stay posted for the new time.
>
> David
>

> On 8/7/08, Chris Saad <chris.s...@gmail.com> wrote:
>
>
>
> > Heya Trent - a number of last minute things has come up for a bunch of us
> > who would like to attend. Can we re-do the scheduling vote and try again
> > please bud?
>
> > Chris
>
> > On Tue, Aug 5, 2008 at 10:49 PM, J. Trent Adams

> > <jtrentad...@gmail.com>wrote:

[TSchultz55]

Ah kinda last minute.....I'm still available to discuss, as I pushed
some meetings this morning back to fit this in :)

One of the things I wanted to discuss anyway was reoccurring meetings
(i.e. twice a month).

[J. Trent Adams]

GD -

I'm still on board with the call... it's hard to reschedule so, I
propose we move ahead with who's available.

- Trent

On Aug 7, 9:48 am, gdupont <ger.dup...@gmail.com> wrote:

[Paul Jones]

I think a big part of the problem is that considering we have active members in 3 very different timezones, and no matter what time is selected, a number of people are substantially inconvenienced. The call in Australia, for instance, is past midnight.

I'd also be concerned about the loss of historical information over decisions, given that voice calls lack a clear trail.

[Trent Adams]

Paul -

I totally hear you on the difficulty in scheduling a time that works
for everyone. My hope was that over the past week when it was
proposed, folks could jump into the thread to talk up various times.
At least that's why I thought the Doodle poll would work (and seemed
to indicate of everyone who responded that the 10am ET / 2pm GMT would
work). We'll work out a better schedule that's more convenient for
the next round.

Anyway, we had a good chat amongst the folks who made it, and I'll
send around a brief recap for asynchronous consideration and input.

Onward,
Trent

[J. Trent Adams]

Despite a last minute drop-off from key contributors, we had a good
call. As I don't have access to the wiki or Groups pages to add
minutes, here's a short summary of what we discussed:

ATTENDING:
J. Trent Adams (matchmine, DataPortability Project)
Tim Schultz (Johnson & Johnson)
Nick Givotovsky (Datasphere Interactive)
Paul Trevithick (Parity, Higgins Project)
Gérard Dupont (Information Processing Competence Center)

MINUTES:

* APML in It's current form is easy to export, but hard to leverage
for
import without more context.

* We should move aggressively toward an RDF solution.

* Proposal to shift the view of APML as one specified technology
to a conceptual framework with at least two technical formats:
+ APML - XML (simple for people to use)
+ APML - RDF (more context-rich and extensible)

* Need to evaluate and prioritize the suggested additions to
get to APML v.1.0.

* Identify a rough roadmap of delivery for drafts, specifications,
and related outreach to encourage understanding / adoption.

* Two tracks emerged needing separate attention / mindshare:
+ Technical specifications
+ Scope, policy, adoption, process

* Discussion around need for IPR protection and possible
integration with OWF or the new IDTBD org being formed.

* Set a time each month to hold ongoing teleconferences
to continue advancing the ball.

There were probably some other topics I've missed, so feel free to
reply with any updates or clarifications to these points.

For my part, I'll work on setting up a formalized discussion around
getting the teleconferences off the ground. I'll make an effort to
ensure broad participation across time zones (read: Paul, you're front
and center).

Any other suggestions?

- Trent

---
J. Trent Adams
=jtrentadams

About: http://www.mediaslate.org/jtrentadams/
Follow: http://twitter.com/jtrentadams

[David P. Novakovic]

Thanks for the notes Trent.

It sounds like some good discussion was had. I look forward to seeing
where this takes us. :)

David

[Paul Jones]

Hi Trent,

On Thu, Aug 7, 2008 at 7:08 PM, J. Trent Adams <jtren...@gmail.com> wrote:

Despite a last minute drop-off from key contributors, we had a good
call.  As I don't have access to the wiki or Groups pages to add
minutes, here's a short summary of what we discussed:

Unfortunately, given the spam that kept appearing there, restricting editing rights was about the only way to prevent the information on the pages becoming useless.
 

ATTENDING:
J. Trent Adams (matchmine, DataPortability Project)
Tim Schultz (Johnson & Johnson)
Nick Givotovsky (Datasphere Interactive)
Paul Trevithick (Parity, Higgins Project)
Gérard Dupont (Information Processing Competence Center)

MINUTES:

 * APML in It's current form is easy to export, but hard to leverage
for
  import without more context.

 * Proposal to shift the view of APML as one specified technology
  to a conceptual framework with at least two technical formats:
    + APML - XML (simple for people to use)
    + APML - RDF (more context-rich and extensible)

I personally disagree with having multiple formats for the APML output as, realistically, that would require every parser to support both for interoperability. That, in my opinion, would substantially hinder adoption. To the best of my understanding, technologies such as GRDDL would allow for transformation into an RDF form from basic APML, whilst preserving the base format.
 

 * Need to evaluate and prioritize the suggested additions to
  get to APML v.1.0.

I actually do have a very rought draft of APML 1.0 that I'll send out in a separate email.
 
Paul.

[J. Trent Adams]

Paul -

Absolutely no problem on the wiki access. At some point if we get
into regular telecons, it'd probably be useful for the secretary (i.e.
note-taker) to have access to somewhere the minutes could be loaded
up. Till then, we can manage just fine on the list.

Re: Two separate tracks of APML (XML / RDF)

The thought expressed on the call was that the RDF version might put
early adopters off due to the complexity. As long as there's some
kinda' simple version available for them, that probably solves that
problem.

From what you suggest, it sounds like you're proposing something like
the current APML XML version take primacy over an RDF variant (created
through a transform). I could be missing something here, but wouldn't
that mean that the RDF would be essentially a "downsample" of the non-
RDF version? It was my understanding that we'd hoped an RDF solution
would be more richly defined than what non-RDF XML could handle.

Taking another tack, why would someone be required to parse both APML
formats? Wouldn't it make sense to have separate parsers that the
consumer/producer could decide to use based on their need?

That being said... IMO, it's less an edict that "It must be RDF!"
rather than a discussion about utility. As long as the APML concepts
are associated with more context than they are now, we should be in
much better shape.

And thanks for circulating the v.1.0 draft... I'll spend some quality
time with it. :)

Cheers,
Trent

On Aug 8, 12:10 pm, "Paul Jones" <pauljone...@gmail.com> wrote:
> Hi Trent,
>

[Paul Jones]

Hi Trent,

On Fri, Aug 8, 2008 at 6:05 PM, J. Trent Adams <jtren...@gmail.com> wrote:

Absolutely no problem on the wiki access.  At some point if we get
into regular telecons, it'd probably be useful for the secretary (i.e.
note-taker) to have access to somewhere the minutes could be loaded
up.  Till then, we can manage just fine on the list.

Hopefully we should be able to organise for active members to get some kind of editing right soon - I'm open to suggestions on the best ways to do it.
 

Re:  Two separate tracks of APML (XML / RDF)

The thought expressed on the call was that the RDF version might put
early adopters off due to the complexity.  As long as there's some
kinda' simple version available for them, that probably solves that
problem.

From what you suggest, it sounds like you're proposing something like
the current APML XML version take primacy over an RDF variant (created
through a transform).  I could be missing something here, but wouldn't
that mean that the RDF would be essentially a "downsample" of the non-
RDF version?  It was my understanding that we'd hoped an RDF solution
would be more richly defined than what non-RDF XML could handle.

Taking another tack, why would someone be required to parse both APML
formats?  Wouldn't it make sense to have separate parsers that the
consumer/producer could decide to use based on their need?

Perhaps we're thinking about different angles here, but here's the explanation on my take:

Currently, in the feed syndication world, there is both Atom and RSS. To "participate" properly, software needs to be able to understand both. Choosing one of the other isn't an option, because a user isn't going to accept "sorry, I can't read this feed because the provider chose a format that I don't like".

I fear that if there were two "representations" of APML, then the same would happen. A consuming application could hardly reject an APML document because the producer used an output format that it cannot read...

As for the "downsample", I believe this can be avoided. The "Concept" node within APML now has an rdf:about attribute (as discussed on the mailing list) which allows it to have a richer definition than simply plain text. Other elements could well also have this applied - however, all other elements currently have a URL already, so I wasn't sure if they needed it.

And thanks for circulating the v.1.0 draft... I'll spend some quality
time with it.  :)

I look forward to your feedback.
 
Paul.

[TSchultz55]

Paul,

Adding to additional thoughts posted here:
http://groups.google.com/group/apml-public/browse_thread/thread/302dd690a9a27505

RE:

> As for the "downsample", I believe this can be avoided. The "Concept" node
> within APML now has an rdf:about attribute (as discussed on the mailing
> list) which allows it to have a richer definition than simply plain text.

I was originally on board with this idea as well, until I thought of
some other uses of a pure RDF implementation: the ability to query an
entire pool off attention profiles - (i.e. "Show me all users who have
'explicitly' listed on 'Website.com' that they like the concept
'Linux' with a value of '0.75' or above").

Not sure this could be achieved efficiently with a vanilla XML
implementation.

Regards,

Tim

On Aug 8, 1:13 pm, "Paul Jones" <pauljone...@gmail.com> wrote:
> Hi Trent,
>

[Chris Saad]

In this case, my thought would be that APML XML is an interchange format not a storage format that allows advanced queries.

Perhaps if we restricted the RDF version for storage and query. This way adopters could expect XML in and out, but we could also see an ecosystem of software that can query APML RDF stored on disk in various ways.

The key here, however, is to avoid speed bumps for the interchange process. To maintain KISS.

Chris

[gdupont]

About the RDF/simpleXML balance, I would prefer a simple XML version,
not for me but for broader adoption.

We all agreed on the advantages of RDF and IMHO, having a simple xml
exchange format and a recommendation (and tools) for an RDF-like
storage format, that's great.

About the concept/location/people things, my opinion is that we should
focus APML on its mission : describing user's attention and not
describing each unit of information or entity that are related to this
attention. For instance the concept is simple with only a keyword : at
least anyone can work with it. If someone want to go in deep analysis
use the rdf:about URI and search for a more complete description, but
keep it out the APML. I'm in the same mood for others data <Concepts /
> <Sources /> <People /> <Locations />. Always keep a simple
version and optionally provide a link to a broader definition.
Of course that supposes to be able to retrieve such definition and in
that case either an RDF fragment which is under the responsibility of
the APML provider. Common semantic repository can be used (such as
dbpedia) or had-hoc RDF resource on demand.

The RDF-full storage format will of course be very promising for
querying purposes using APML aggregators. Presenting some demo
application on the exploitation of APML/RDF capability may be a good
advertisement. This is probably where you should enforce developers to
use RDF, provinding converters from APML/XML to APML/RDF

So to follow Chris's thougths : keep it simple ... until
everyone move to RDF !

gd

On Aug 8, 8:32 pm, "Chris Saad" <chris.s...@gmail.com> wrote:
> In this case, my thought would be that APML XML is an interchange format not
> a storage format that allows advanced queries.
>
> Perhaps if we restricted the RDF version for storage and query. This way
> adopters could expect XML in and out, but we could also see an ecosystem of
> software that can query APML RDF stored on disk in various ways.
>
> The key here, however, is to avoid speed bumps for the interchange process.
> To maintain KISS.
>
> Chris
>
>
>
> On Sat, Aug 9, 2008 at 4:17 AM, TSchultz55 <TSchult...@gmail.com> wrote:
>
> > Paul,
>
> > Adding to additional thoughts posted here:
>

> >http://groups.google.com/group/apml-public/browse_thread/thread/302dd...

[J. Trent Adams]

I hear you guys about KISS.

My concern is, as an APML consumer, we're not getting enough value
without more contextual information. We can be an APML provider
easily enough, and we can parse the simple syntax as a consumer of
APML, but we'll need more context to see true value in the format.
Basically, our models indicate that context-free data hurts rather
than helps.

In short, a high level of ambiguity means we need orders of magnitude
more data points for statistical disambiguation.

I'm reaching out to some folks to see if we can shift our thinking
toward the "rdf:about" model. It's possible we may get enough value
out of it, but I'm not sure, yet.

- Trent

---
J. Trent Adams
=jtrentadams

About: http://www.mediaslate.org/jtrentadams/
Follow: http://twitter.com/jtrentadams