Re: First attempt at modelling

Hi Frank,

Thanks very much for this document. I understand that I have caused some confusion with regards to the direction and objectives of the group!

As you have reviewed the objectives of the group, let me review what we have done so far.

Call-01 & Call-02: Crispin presented his straw-man. Everyone listened very patiently but the general reaction was that this was rather too detailed, and XML formatting too unfriendly, for people to engage in useful discussions. So it was agreed that Crispin would develop a tool which would enable people to play around with the straw-man specification and see whether it could be useful.

Call-03. A progress review discussion.

Call-04 & Call-05: Jono presented the ADL's work on a SCORM profile for xAPI. This was very well received.

Call-06: a further progress review discussion. It was agreed to invite further presentations on current work on competency definitions, and to have a further discussion in Call-07 trying to encapsulate the purpose of the group in an easily-digested half page.

My reaction to the prospect of hearing more use-cases, interesting though they are, is that there is a danger of the group slipping into spectator mode. I think the use-cases are interesting so long as we can use them as material for modelling activity. But my tool is not going to be available for another couple of months, at best.

There are two reasons for my new interest in UML. My *old* interest in UML (as illustrated by Learning Activity Model) was to define conceptual taxonomies, rather than more concrete, technical architectures.

1. First, I think we need to demonstrate that whatever we are proposing will not duplicate what is already available. So *part* of the requirement is precisely to show (as I think you suggest, Frank) that UML is not sufficient. We might need to do a similar elimination exercise on e.g. XSD.

2. My first release of the tool (and the documents I have written so far) are focused on the high level data modelling. But I think we are moving towards a recognition that this is only part of the solution. We also need to model topologies and/or workflows. I thought a look at UML might be particularly interesting from this point of view, to help clarify what we meant by these terms. This is an aspect of the requirement which I have not yet produced any very concrete proposals.

3. Possibly as a way in which the group more widely could engage with the use cases that we are proposing to explore, while I try and make progress with the tool. Even if UML might not be sufficient for our purposes, it might help clarify some of the differences between different use cases: traditional SCORM, xAPI, xAPI-SCORM, xAPI-CMI5, a competency model, what Aswini proposes with JSON metadata provided by interrogating a service...

If it is just a matter of keeping people busy while I make progress on the tool, you might say that you would prefer to dig holes and fill them in again. It may be that we should just go dormant and reconvene when I have a tool to give you to play around with - and that that is the point at which we should invite people to present more use cases, as we will then be able to interact with those use cases by modelling them.

My answers to your questions, Frank, are that I did think it might be useful to model different use cases (in particular the variations - multi-player etc) at the topological and workflow levels, though not at the data model level. And that I thought this would be useful, not for the purpose of creating specifications, but for the purpose of exploring what it takes to model these things, establish in what respects a generic tool like UML could be streamlined when replicated at a higher level, and to establish the key ways that the different use cases differ.

Does that make sense?


Crispin Weston


On 4 May 2015, Frank Polster <polsterf@gmail.com> wrote:
> Crispin,
> 
> Attached is a document that is a bit of a "review of the bidding" on my part to ascertain where we currently are in the XDMDL project. If my general understanding is correct I have made suggestions about going forward. If not ok.
> 
> I think to some extent we have moved further along with your five objectives of which we deferred three. I think we are talking about bridging to the the deferred three at this point with the development of a prototype tool and therefore the use case and UML diagrams are the next step.
> 
> Thanks Frank
> 
> On Mon, May 4, 2015 at 3:07 AM, Crispin Weston <<crispin.weston@saltis.org>> wrote:
> 
> > Hi Aswini,
> > 
> > Many thanks for the thoughts - and I am very sorry to see that I have not enrolled you on to the wiki - I will send you login details, after which you should be able to post to the wiki.
> > 
> > I am sure that my very high level, first attempt at a SCORM model, could be improved, with different diagrams for each actor, and it would be great if you and others could contribute ideas using the Visual Paradigm tool.
> > 
> > I will send you login details - and thanks again.Crispin
> > 
> > 
> > 
> > On 3 May 2015, Aswini Sridhar <<ashumeow@live.com>> wrote:
> > > After glancing, reading and visualizing [1], here are the answers to that wiki. (I’m unable to post answers though.)
> > > 1. Do you think that these diagrams correctly capture the top-level processes involved in SCORM? If not, can you improve on them?
> > > There is yes as well as no.
> > > In terms of yes:- These diagrams correctly capture the top-level processes involved in SCORM.
> > > In terms of no:- We can also improve it. It is great to put one common diagram like in Figure 1 [1]. Along with Figure 1, we can add separate figures for every actor.
> > > And why?
> > > In that figure 1, there are 4 actors namely publisher, administrator, instructor and learner. Every actor will be given different functions.
> > > The least one and easy one is the publisher who creates the package.
> > > Common functionalities for administrator, instructor and learner are --- login, logout.
> > > Users and instructors can’t access certain things, because administrator might have revoked certain access points. But, it has been already illustrated in the diagram, but it appears quite complex.
> > > How about Figure 1 as common and separate figures for every actor? This will make it more easier for us to add more functionalities and we can make it more friendly model and easier/simple to understand.
> > > 
> > > 2. Can you produce similar diagrams for other use cases: xAPI, multi-player, competency references etc.
> > > Yes, sure. Why not?
> > > 
> > > 3. Is this a useful approach to understanding how to model these different processes?
> > > For now, it appears quite useful.
> > > It would be nice to hear suggestions from others.
> > > 
> > > 
> > > 
> > > [1] <http://wiki.saltis.org/display/XDMDL/SCORM>
> > > 
> > > Coming back to your other questions,
> > > a) I could apply for a Community license for the Visual Paradigm software, which is what I used to create the diagrams.
> > > 
> > > Yes, Apply for it. I found that the community license is free in VP S/W official page.
> > > 
> > > b) we could devote a call to discussing how to create these diagrams.
> > > 
> > > Yes, that would have be great. We can dedicate some time for it through a call that would help everybody in our group to participate in modelling the diagrams.
> > > 
> > > c) everyone on the group could get a homework to model one use case using the VP tool.
> > > 
> > > Sounds fun! =D
> > > 
> > > 
> > > Regards,
> > > Aswini. S
> > > 
> > > From: Crispin Weston <crispin.weston@saltis.org>
> > > Sent: ‎Monday‎, ‎04‎ ‎May‎ ‎2015 ‎00‎:‎28
> > > To: <public-xdmdl@w3.org>
> > > 
> > > Dear All,
> > > 
> > > I have tried my hand at producing a couple of UML models, which I have posted to the wiki at <http://wiki.saltis.org/display/XDMDL/SCORM>. This effort was stimulated by Aswini's question about having a system where one might interrogate a service in order to retrieve appropriate JSON metadata. My thought being that these sorts of use case need to be explored in some sort of commonly understood modelling environment. In this way, we might get a better understanding of what exactly a machine-readable modelling environment would look like that allowed different interoperability scenarios to be implemented easily.
> > > 
> > > Do have a look and let me know if you think this might be a useful avenue to pursue. If you think it is, then:
> > > 
> > > a) I could apply for a Community license for the Visual Paradigm software, which is what I used to create the diagrams.
> > > 
> > > b) we could devote a call to discussing how to create these diagrams.
> > > 
> > > c) everyone on the group could get a homework to model one use case using the VP tool.
> > > 
> > > Let me know what you think! And if you think that my SCORM diagrams could be improved on (or supplemented with lower-level diagrams), do download your own evaluation copy of VP, download the editable file from the wiki, and amend as you wish.
> > > In the meantime, I propose that next week's call should focus on producing a better and shorter definition of the group's purpose.
> > > 
> > > Crispin
> 
> 
> -- 
> 
> Frank PolsterCell 757-816-6230
> Google Voice -757-741-7002
> <polsterf@gmail.com>
> <frank@g3.com>