Re: [vwrap] vwrap Digest, Vol 11, Issue 24

[Morgaine <[e-mail]>]

That sounds interesting, Vaughn.

Unfortunately my Firefox browser and Gmail on Linux appear to have a
semantic problem with Powerpoint, despite the success of Service Level
(Syntactic) Interoperability because it is a recognized type.  Is the OGCII
material available in any other format?

:P


Morgaine.




==========================

On Thu, Mar 31, 2011 at 3:34 PM, Vaughn Deluca <[e-mail]>wrote:

> Morgaine,
>
> Thanks a lot for the explanation, i now realise that "service level
> interoperability is an existing technical term, and  not something
> that was manufactured on the fly here in the group...my bad.
>
> I will update my definition in the glossary a bit, (and use an existing
> source).
> In the process of doing my homework, and reading up on the topic, i
> stumbled over a very  interesting piece on the web that i would like
> to bring up here for discussion.
>
> It is a powerpoint presentation with teaching material from the OGCII
> (Open Geospatial Consortium Interoperability Institute).  Processing
> Geospatial data appears to have many problems in common with our
> virtual worlds. See:
> http://portal.ogcii.org/files/?artifact_id=168   (warning: powerpoint
> download)
>
> The core idea is simple. A standard intermediate data format, that is
> used to match possibly very disparate datasets (like our assets from
> different virtual worlds) and some mechanisms to extend this.
>
> I might have missed this, but it seems to me that this concept has up
> till now not figured this explicitly in our thinking. It would be good
> if people on this list have a look at this material, if only to point
> out that it matches closely to stuff we *did*specify, or alternatively
> why it is *not* applicable to our case, and bad idea.  However,  I
> think it is very useful, and could easily be adapted for the VWRAP
> problem domain with its many disparate and  distributed data sources.
>
> It anyhow nicely addresses the differences between working service
> level interoperability and the semantic mismatch you mentioned.
>
> --Vaughn
>
> On 3/31/11, Morgaine <[e-mail]> wrote:
> > Very well put, Vaughn.
> >
> > Regarding "service level interoperability", it's not really a subset of
> VW
> > interoperability at all, but lies orthogonal to it because it is a
> property
> > of all multipart systems that implement services.  I'll try to explain.
> >
> > Client-server systems for example have at least two distinct parts with
> > distinct roles, server(s) and client(s).  Service-level interoperability
> > typically consists of designing and specifying the protocols or
> interfaces
> > between them in such a way that any part of the system is interchangeable
> > with another equivalent part that performs the same role, say from a
> > different manufacturer, and the system as a whole still continues to work
> > normally.
> >
> > This rarely needs to be honored with a fancy title such as "service level
> > interoperability" in these days of IETF standards and highly
> cross-platform
> > web applications.  Historically however, applications did not behave
> quite
> > so nicely, and vendors often sought to lock customers in with hidden
> > proprietary interfaces, so there was a need for adding "service level
> > interoperability" to the tendering documentation in days gone by, to
> avoid
> > surprises later on.
> >
> > Today, the need for that has almost disappeared, and if your online
> service
> > has a documented protocol interface then "service level interoperability"
> is
> > virtually assured without doing anything at all, assuming normal
> commonsense
> > has prevailed during development (and there is no deliberate obfuscation
> of
> > course).  There is only one other area of this topic where a little more
> > needs to be said.
> >
> > Protocol messages can normally be validated syntactically to a strong
> > degree, and whether a message is correct or not is normally known
> > immediately upon syntactic validation.  Unfortunately, that is not always
> > the end of the story, because protocols can transport complex data items
> > which are valid syntactically yet invalid semantically.
> >
> > This is the last vestige of where that term is commonly encountered,
> > as *Service
> > Level Semantic Interoperability*.  Is it relevant to us?  Yes, a little.
> > For example, it would do us no good to transport Collada meshes from an
> > asset service to a client that tries to render them as some other
> graphics
> > format --- that would create a semantic mishap, because one party thinks
> > that the items means one thing and another party applies a different
> > semantic.  So yes, there is a little more for us to consider here, but
> it's
> > not a lot.  In most part we have already stated the solution every time
> that
> > we have mentioned MIME types for describing content.  This is mostly a
> > solved problem.
> >
> > There may be one or two other areas where we have to specify the required
> > semantic alongside the simple matter of protocol syntax, but that's a
> > standard part of defining protocols.  There is nothing really new here.
> >
> > Lastly, service level interoperability focuses entirely on single
> services
> > and their clients, so it's unrelated to interoperability between multiple
> > services, such as a set of virtual world services.  This means that,
> apart
> > from defining type semantics, it doesn't get us even a step closer
> towards
> > interop between virtual worlds.
> >
> >
> > Morgaine.
> >
> >
> >
> >
> >
> >
> > ==========================
> >
> > On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca
> > <[e-mail]>wrote:
> >
> >> Katherine wrote:
> >> >It seems to me that accomodating "full" interop only would reduce the
> >> >number of possible implementers and use cases for our work
> >>
> >> I am sure that nobody  suggested to we restrict ourselves to "full"
> >> interop only.
> >> "Service level interop" is clearly subset of VW interoperability. You
> >> can't have VW interoperability without service level interoperability!
> >> However, If i understand Morgaine right, she is worried that the VWRAP
> >> specs will be *restricted* to service level interop only.
> >>
> >> It has been argued (sorry, I forgot by whom) that proper
> >> specifications of service level interop will give us virtual world
> >> interop for free. I think we need a bit more, but i really have a hard
> >> time envisioning how service level interop can be specified in such a
> >> way that it *prevents* VW interop, at least not if we pay attention to
> >> this aspect, and clearly we do. So in conclusion i do not see much of
> >> a problem.
> >>
> >> Izzy wrote in another tread "This whole argument between service level
> >> interop and 'full' interop eludes me." At first it eluded me to, but
> >> now i think that what is actually expressed in these discussions is
> >> the question of the scope of our effort as well as design approach.
> >> Some prefer to work bottom up, following their primary interests in
> >> getting the low level protocols working, especially since that will
> >> already be good enough for (all?) of their use cases . Some prefer a
> >> more top-down approach, first sketching the high level picture of the
> >> users perception of VW interop,  and from there working downwards,
> >> obviously also because that approach optimises the realisation of
> >> *their* use cases.
> >>
> >> I think we need both, and above all, i do feel that the two approaches
> >> are not al all incompatible and both are without any doubt square
> >> within the current charter.
> >> Formally splitting our effort in two working parties along the current
> >> visible fissures and getting each to work on their own interest is a
> >> recipe for disaster. It will only strengthen the animosity that is
> >> already slowing us down tremendously, and will sustain the infighting.
> >> Rather than spitting efforts off, we need to address the causes for
> >> the current disagreement and found common ground.  In my view that is
> >> not all all hard.
> >>
> >> I have been reviewing the discussion we had in September and i am
> >> actually amazed at the level of consensus that is expressed in those
> >> email exchanges. Unfortuanately we have been very bad at consolidating
> >> that consensus. As a result we recycle the same problems time and time
> >> again. The archives make very depressing reading from that point of
> >> view. We need to do more documentation for sure.
> >>
> >> I am currently going over the September discussion and looking up the
> >> places were we all agreed on the way forward.  Much of that is still
> >> undocumented, and my aim is to get those points written down in the
> >> wiki.
> >>
> >> As i final point i want to make clear how I understand the term
> >> "Service Level Interop". I used the term, and since the glosary entry
> >> is still emtpy, i feel obliged to add at least my personal reading. If
> >> somebody disagrees, please add an improved version.
> >>
> >> Service level interoperability:
> >>        A subset of "Virtual World Interoperability" as defined by the
> >> VWRAP
> >> protocol. Service level interoperabity loosely describes specific
> >> interactions between VWRAP endpoints. These inteactions form the glue
> >> that hold a particular virtual world together, but might just as well
> >> be used for communication between different VWRAP compatible virtual
> >> worlds (i.e. crossing trust domains).
> >>
> >> I intend to put this up in the glossary, but first will see how it
> >> flies here  :)
> >>
> >> On 3/29/11, Katherine Mancuso <[e-mail]> wrote:
> >> > Hi everyone,
> >> >
> >> > I want to speak up for agreeing with Meadhbh & Mike about keeping a
> >> > role for service level interop in this group.  We've made good
> >> > progress towards this goal and can continue to work on it.
> >> >
> >> > Here is an alternative proposal to any which has been brought up so
> >> > far.  I'm aware this may not be fully correct in its technical
> >> > details, as I am not a software architect:
> >> >
> >> > Could the partisans of "full" VW interop consider working together on
> >> > a draft specification that is something like the intro or David's
> >> > piece in scope that lays out which specific capacities would need to
> >> > be supported at a minimum to allow for "full" interop, perhaps getting
> >> > input from implementers such as the Hypergrid folks and the folks who
> >> > coordinated the teleport test at Linden?  Citing existing service
> >> > specifications (either ones developed within this WG, or outside
> >> > specifications like XML, Collada, etc) is preferred, and for
> >> > capabilities for which there are not existing service specifications
> >> > or the existing specifications don't work well enough, address that to
> >> > lay out a clear roadmap of what must be developed.
> >> >
> >> > My vision here is that folks who are doing service-level work could
> >> > continue developing and implementing their individual services, and
> >> > the folks who wish to do "full" interop could define a menu of
> >> > services which must be implemented for "full" interop.  Implementers
> >> > could then choose their path based on their use cases: implement the
> >> > "full" interop specification including all the specifications called
> >> > for, or implement individual services.  I believe that both of these
> >> > concepts can exist under our existing charter or with limited
> >> > amendment to the charter and intro, which is much easier for everyone
> >> > to agree to than entirely rewriting both, and does not require
> >> > trashing years of work.
> >> >
> >> > It seems to me that accomodating "full" interop only would reduce the
> >> > number of possible implementers and use cases for our work
> >> > dramatically, not to mention cut out a productive body of folks in
> >> > this group who have been contributing an awful lot of documents and
> >> > implementing.
> >> >
> >> > For example, to illustrate my point:
> >> >
> >> > From my work as a SL developer focusing in education, I know there's a
> >> > substantial use case in K-12 education in the US for walled gardens,
> >> > because schools have big legal liability problems with letting minors
> >> > wander unwalled virtual worlds (most school libraries in the US have
> >> > internet filters for the same reasons) and have fairly intense
> >> > supervision requirements which require substantial moderation &
> >> > surveillance tools.  However, a shared asset server that contains a
> >> > core of "safe" content might be of interest to these folks, since
> >> > educators don't necessarily need to reinvent the wheel for their
> >> > classrooms every year.  This is a really good case for service level
> >> > interop ... implement the asset server specification only, not the
> >> > "full" one that allows you to teleport to other worlds.
> >> >
> >> > On the other hand, universities have far greater interest in letting
> >> > students and professors teleport among university spaces (which
> >> > happens metaphorically in the real world all the time), and fewer
> >> > liability issues.  Sharing an asset server might be of interest to
> >> > them, but so too might "full" interop.  They'd want to implement the
> >> > "full" interop specification.
> >> >
> >> > (Paging Fleep Tuque, are you here to make this case better for me?)
> >> >
> >> > TL;DR - Proposal is to amend the charter & intro so that they allow
> >> > the "full" interop people to work in one community on their ideas and
> >> > the service level interop people to work in parallel on their ideas,
> >> > rather than assuming that one model has to exclusively dominate the
> >> > group.
> >> >
> >> > I will be unavailable to post anything else much lengthy through 3
> >> > April,
> >> > FYI.
> >> >
> >> > Katherine
> >> >
> >> > --
> >> >
> >>
> ---------------------------------------------------------------------------------------------
> >> > Katherine Mancuso
> >> >
> >> > ISIS Inc, Community Manager (http://www.isis-inc.org)
> >> > Sex::Tech Conference, Social Media Chair (http://www.sextech.org)
> >> > The Vesuvius Group: metaverse community builders
> >> > (http://www.thevesuviusgroup.com)
> >> > GimpGirl Community Liaison (http://www.gimpgirl.com)
> >> >
> >> > http://twitter.com/musingvirtual
> >> > http://facebook.com/kmancuso
> >> > http://www.linkedin.com/in/kathymancuso
> >> > Second Life: Muse Carmona
> >> >
> >>
> ----------------------------------------------------------------------------------------------
> >> > _______________________________________________
> >> > vwrap mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/vwrap
> >> >
> >> _______________________________________________
> >> vwrap mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/vwrap
> >>
> >
>