Road map for the DP technical action group

0 views
Skip to first unread message

Elias Bizannes

unread,
Jan 21, 2008, 8:40:49 PM1/21/08
to DataPortability.Action.Technical
Hi everyone,

I'm one of the workgroup members, and I've been consulting some of the
other members to come up with a road map. We've created one for the
technical action group (we are doing this for each of the DP action
groups), and would like to get feedback on it.

We propose the following stages of the technical action group. Each
stage itself will have separate timetables and deliverables; but I
suppose this is the big picture view for you guys.

1. Define the use cases
2. Define the design principles
3. Define the functional parts
4. Define the standards that may fit the functional parts
5. Define the links between the functional parts using the hooks
provided by the standards

Comments?

richard.pendergast

unread,
Jan 21, 2008, 10:55:02 PM1/21/08
to DataPortability.Action.Technical
Hi Elias,

Love your work. It's good to see something tangible coming out of this
group. The roadmap looks really good, and definitely demonstrates an
actionable plan that could stimulate, or at the very least allow for
the driving of, group activity.

However, I am unsure as to the fit. My understanding of this
particular group is taken from the front page summary of the group -
"In all cases the goal should be to find and contextualize existing
work from other groups and weave them into a story - rather than to
invent or discuss the probles/solutions from scratch."

If that's the case then wouldn't the roadmap be more about
investigation, identification and collation?

Maybe I am just misunderstanding the intent. Could we use the roadmap
as a tool we provide to potential implementors? If that's the case,
then this is gold, and I'd love to get behind it and contribute, as
even in it's current form it's given my own implementation project
some simple achievable objectives.

Richard.

Chris Saad

unread,
Jan 22, 2008, 7:34:02 AM1/22/08
to DataPortability.Action.Technical
Richard, Elias,

Perhaps "'Define' the standards that may fit the functional parts"
should be reworded to "Research and list the standards that may fit
the functional parts"

Chris

On Jan 22, 1:55 pm, "richard.pendergast"

Paul Madsen

unread,
Jan 22, 2008, 9:14:13 AM1/22/08
to dataportability...@googlegroups.com
If it is the same group that determines the use cases as subsequently identifies the relevant standards, there could be a danger of only coming up with use cases that can be addressed by 'known' specs, i.e., if  you have FOAF in the back of your mind as a good bet for a relevant piece of the blueprint, you may only come up with use cases that FOAF can solve.

Would there be value in 'separation of duties'?

paul
--
Paul Madsen

Frederick Giasson

unread,
Jan 22, 2008, 9:45:36 AM1/22/08
to dataportability...@googlegroups.com
Hi Paul,

> If it is the same group that determines the use cases as subsequently
> identifies the relevant standards, there could be a danger of only
> coming up with use cases that can be addressed by 'known' specs, i.e.,
> if you have FOAF in the back of your mind as a good bet for a
> relevant piece of the blueprint, you may only come up with use cases
> that FOAF can solve.


In my opinion, use cases are use cases. They have to be independent.
Then, once use cases are outlined, you have to check what can do what,
and how you can extend technologies to meet the need of use cases.


Don't htink about use cases on a technology standpoint, think about it
on a user standpoint; otherwise the exercise is useless.

Take care,


Fred

Reply all
Reply to author
Forward
0 new messages