3d views

[k.o.lu...@rdg.ac.uk]

Just had a discussion on how the 3d views should be made (Shirley,
Rob, Edwin and myself). One of the main issues discussed was to
include different sources into the FFS.

After reflecting on this a bit, I'm thinking that this is knowledge
that should be on another level, as there might be other applications
that would use a FFS, but wouldn't have different sources. Perhaps
this should be tied in with the actual aggregation process (so
effectively part of an application ontology of the MeA...)

What do you think?

[Pat Parslow]

I think I am a little confused by the terminology :-)

When you talk about including different sources into the FFS - what do you
mean by sources? Resources? 3D source files (code and textures)?
You certainly could include the latter in the FFS (as in, you could
represent it within the instantiated FFS) - I thought this was originally
the plan as it makes the FFS all knowing (!) and means it should be easier
to enable users to skin the front end.
And of course you rather have to include the former, which is why I am
confused.

Unless you mean it should be in some way hard coded into the FFS, in which
case I have to ask, "Why?" "How?" and again with the "Why?" (but this is the
impression I get from your second paragraph, which is why I have to ask!)

I will be in Reading Weds/Thurs so we can discuss (and remember to summarize
here!)

[Karsten Oster Lundqvist]

I mean the source of the different resources that are aggregated. We
have primary and alternative locations, but we don't have a source; like
facebook, blackboard, elgg or "my personal blog".

This is information that ultimately decide how the information should be
aggregated, hence could be viewed as an application specific knowledge
that is only needed on the client side, and not in the FFS.

I can see why it would be a good idea to have it in the FFS as well (all
knowing), so I think I'll need to reflect a bit more on this topic...

Hmmnn, maybe a source is a foaf:agent, because it needs a different kind
of protocol to be communicated with... More thinking is needed, brain
hurts...

[Pat Parslow]

AH OK.

I see that sort of source (I would call it a service, without thinking it
through too much...) as being something which should be in the FFS.

The FFS allows us to represent resources and their relationships to one
another. The service is, in a way (not a very precise way, I'll grant you)
an aggregation of resources, from a client perspective. Ideally I would
like to model it as being a 3rd party MeAggregator instance, with filters to
allow us to interface with it. So, as far as the core of MeAg is concerned,
it should be (in my view, at the moment) just another resource - a fellow
peer in the realm of service-providers. In order to be able to communicate
with it, obviously, our MeAggregator will need to have adapters to modify
the native MeAgAPI calls to service specific calls. In some cases this will
be their API and in others it may be code snippets to allow us to scrape the
results we need from the Service.

In my view, this is something we can use a MeAggregator for. The overall
adapter is just an aggregation of individual API-adapters, filters and/or
views and is defined in terms of the relationships between two key
resources. RecuRecursionsion ;-)

You could just hard code it in a client, but that is rather tacky imho.

[Karsten Oster Lundqvist]

Tacky - perhaps - but might make prototyping easier ;-) Afterall the
aggregation code has to "live" there. (But again haven't settled on
something yet, need more brain input)

Another issue is that much of the info should/could/might (put in word
as appropriate) be the view of the 3d model. For instance each service
would be a planet and resources aggregated from the source/service would
be viewed as satellites and dust around the planet.

Indeed this was the kind of view we ended up with as a good MeA
prototype view candidate for October...

Well - I'll leave for home now... Really... this time...

[Shirley]

Below brief notes from the meeting (it was adhoc):

MeAggregator - Reporting Meeting
11th September 2007
Present:
Rob Aston
Karsten Lundqvist
Edwin Porter-Daniels
Shirley Williams
Brief notes
The purpose of this (brief) meeting was to review the GUI and how it
would interact.

We are using the planet views.

It was agreed that:
· Me would be the sun.
· Planets would be sources (e.g. Blackboard, Facebook, RISIS, Flickr).
· Resources would be somehow associated with planets.
· Tags would be represented as asteroid belts.

Users should be able to see the view others have on them, and adjust
what is and is not available.

[p@]

Can I chuck me two-penneth in?

I think it is important that conceptually the planets are concepts,
not specifically 'sources'. A while ago (when win95 was produced) MS
had worked out that people don't work best when associating work items
with the package they use to produce a specific type of document. I
can see no particular reason why this will have changed, and if the
Planets represent Concepts we can allow for a topic based (mind-map
style) arrangement. This is not to say that we/users cannot then
assign the 'sources' as Concepts, but it gives greater flexibility.

Essentially, from the FFS point of view, the sources are just tags
which are applied to resources by dint of the fact that that is where
they come from. If a user so chooses, they should be able to view
their data aggregated by group or any other arbitrary tag.