<html><head></head><body><div class="ydp90f92bcyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div><div dir="ltr" data-setdir="false">Hi all, I hope 2022 is going well for everyone. <br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">I couldn't make yesterday's meeting, but I looked at the brief. </div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">A few of the points were those I raised and we discussed in the prior meeting (example below**), so I'm happy to propose getting together in the interim before the next meeting to work on things together in real-time.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Would you like to collectively? <br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">In any case, anyone is free to contact me if you'd like to go over your particular section together. <br></div><div><br></div><div dir="ltr" data-setdir="false">**examples</div><div dir="ltr" data-setdir="false">- from the last two section about Jan meeting<br></div><div dir="ltr" data-setdir="false">- formal definitions vs. others & clarity of our meaning and use.<br></div><div dir="ltr" data-setdir="false">- the terms 'space domain ...X'. <br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">FYI: this is a particular term, along with other astronautical terms, I have a living catalog of definitions for, as well as work about some of their conceptual and semantic limitations. <a href="https://github.com/rrovetto/astronautics-terminology" rel="nofollow" target="_blank">https://github.com/rrovetto/astronautics-terminology</a>. In my committee service in AIAA and IAF, I demonstrated the equivalence of space domain awareness and space situational awareness, and the problematic aspects of the former. I mentioned this is our last meeting as well. In the AIAA spacecraft architecture model work, i mentioned similar points.<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">- generic terms such as 'role', etc.</div><div dir="ltr" data-setdir="false">- emphasis (bold/italics)</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Again, a focus of mine is terminology (refinement, dev., etc.) including in abstract models like ontologies, so if formally desired I can help hash out a conceptual framework for the terms used in the rasds documents, with asserting or modifying definitions and terms in the process. <br></div><div dir="ltr" data-setdir="false"><div class="ydpf58be3bcpasted-link"><div><br></div><div><br></div><div>Rob</div><div>--</div><div dir="ltr"><div dir="ltr"><i>Afford everyone the opportunity to succeed, learn and grow.<br></i></div><div>-<br></div></div><div dir="ltr"><font size="2"><span><span><span></span></span></span><span></span></font><span style="font-size:16px;"><span></span><span></span><font style="background-color: inherit;" size="2"><i><span></span></i></font></span><span style="font-size:16px;"> <span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><i><span><span><span style="font-size:16px;"><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><i><span>Actively open to work & PhD study opportunities, worldwide<span><span style="font-size:16px;"><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><i><span>.</span></i></font></span></span></span></span></span></i></font></span></span></span></span><br></span></i></font></span></span></span></div><br><div dir="ltr" data-setdir="false"><span><span style="font-size:16px;"><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span class="ydpeea8591dpasted-link"><span style="font-size:16px;"><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span><span><a href="https://tinyurl.com/yas7trzy" rel="nofollow" target="_blank">Hire for services</a> & Schedule meetings (<a href="https://tinyurl.com/yas7trzy" rel="nofollow" target="_blank">https://tinyurl.com/yas7trzy</a>).</span></span></font></span></span></span></font></span></span></span></span></font></span></span></span></span></div><div dir="ltr" data-setdir="false"><br><div><div dir="ltr"><span><a href="http://purl.org/space-ontology" rel="nofollow" target="_blank">Orbital Space Domain Knowledge Modeling Project</a> (https:/purl.org/space-ontology)<span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span></span> </font></span></span><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span></span></font></span></span></div><div dir="ltr"><span></span></div><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span></span></font></span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span></span><span></span><span></span><span></span><span></span></font></span></div><div><br></div></div><span style="font-size:16px;"><span><span style="font-size:16px;"><div><div><font size="2"><span></span><span><a href="http://www.coder.umd.edu/node/287" rel="nofollow" target="_blank">Research Affiliate</a>,
Center
for Orbital Debris Education & Research.</span></font></div><div><font size="2"><span><br></span></font></div><div><div><font size="2"><span><span><span>Education Committee, International Association for Ontology and its Applications.</span></span></span></font></div><div><font size="2"><span><span><span><br></span></span></span></font></div><div dir="ltr"><font size="2">US Merchant Marine. Available to serve in boat-based rescue emergency response</font></div></div></div></span></span></span><br></div></div></div><div><br></div>
</div><div id="yahoo_quoted_5011853646" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Monday, February 14, 2022, 07:16:36 PM EST, Shames, Peter M (US 312B) via SEA-SA <sea-sa@mailman.ccsds.org> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="yiv4335191616">
<style><!--
#yiv4335191616
_filtered {}
_filtered {}
#yiv4335191616
#yiv4335191616 p.yiv4335191616MsoNormal, #yiv4335191616 li.yiv4335191616MsoNormal, #yiv4335191616 div.yiv4335191616MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri", sans-serif;}
#yiv4335191616 a:link, #yiv4335191616 span.yiv4335191616MsoHyperlink
{
color:#0563C1;
text-decoration:underline;}
#yiv4335191616 p.yiv4335191616MsoListParagraph, #yiv4335191616 li.yiv4335191616MsoListParagraph, #yiv4335191616 div.yiv4335191616MsoListParagraph
{
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri", sans-serif;}
#yiv4335191616 span.yiv4335191616EmailStyle17
{
font-family:"Calibri", sans-serif;
color:windowtext;}
#yiv4335191616 .yiv4335191616MsoChpDefault
{
font-family:"Calibri", sans-serif;}
_filtered {}
#yiv4335191616 div.yiv4335191616WordSection1
{}
#yiv4335191616
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
_filtered {}
#yiv4335191616 ol
{margin-bottom:0in;}
#yiv4335191616 ul
{margin-bottom:0in;}
--></style>
<div>
<div class="yiv4335191616WordSection1">
<p class="yiv4335191616MsoNormal"><b><span style="color:black;">SEA-SA </span></b><b><span style="color:#070706;background:#FFEE94;">RASDS</span></b><b><span style="color:black;"> working meeting on 14 Feb 22</span></b><span style="color:black;"></span></p>
<p class="yiv4335191616MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv4335191616MsoNormal"><span style="color:black;">Attendees: Krosley, Radulescu, Shames, Slane, Stangl</span></p>
<p class="yiv4335191616MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv4335191616MsoNormal"><u><span style="color:black;">Review of open issues from 10 Jan 22 meeting – Peter Shames & team</span></u><span style="color:black;"></span></p>
<ul style="margin-top:0in;" type="disc">
<li style="color:black;" class="yiv4335191616MsoNormal">Fred mentioned that the SC14, as part of their considerations of how to leverage the SANA registry of terms, is now starting to more seriously consider the architecture aspects of their work
and to find value in the RASDS++ work as a viable framework. That is excellent.</li><li style="color:black;" class="yiv4335191616MsoNormal">We spent some time at the beginning of the session exploring the relationships between a purely “Enterprise” viewpoint (pg 15) and the relationships to the Functional and Connectivity viewpoints
(pg 53). We all agreed that including these diagrams was a real value, as will be the explanation of the relationships. An updated pg 53, showing the “home viewpoints” of all these objects is included in the (slightly) revised 14 Feb 22 version, attached
here.</li><li style="color:black;" class="yiv4335191616MsoNormal">Ramon pointed out that there are solid correspondence relationships among these primary objects that we should leverage and describe.
</li><li style="color:black;" class="yiv4335191616MsoNormal">Reviewed the notes from 10 Jan relating to file “SEA SAWG <span style="color:#070706;background:#FFEE94;">RASDS</span> Update Views 13Dec21” that was edited following the 10 Jan 22 meeting.</li><li style="color:black;" class="yiv4335191616MsoNormal">We discussed the relationships between the “abstract” Enterprise views of “application” and “service” elements and the “realized” Functional and Connectivity views of “service”, “function”, and
“system” elements. And then we discussed the truly recursive nature of these relationships where the “abstract functions” from the Functional viewpoint are “realized” by the more concrete Connectivity and Physical views, and then, again, where these abstract
component design views are turned into real, concrete, Components by the implementation processes.
</li><li style="color:black;" class="yiv4335191616MsoNormal">We also, briefly, discussed how this can be thought of as a recursive descent down the left hand side of the “Systems Engineering V”, followed by an ascent up the right hand side of the V as
components are created, tested, assembled into modules, elements, integrated, tested and eventually launched and operated. We
<u>may</u> <u>mention</u> that in the RASDS, but will not be exploring it in any depth since it is a whole subject on its own.</li><li style="color:black;" class="yiv4335191616MsoNormal">Touched upon, again, the need for a consistent set of terms that we can all agree upon and that have good provenance and alignment with common usage in our space operations domain.</li><li style="color:black;" class="yiv4335191616MsoNormal">Fred asked “what does system mean”, relative to pg 51 and 53, and we used that to springboard into a look through the definitions of “system”, “Capability”, “Role”, “Actor”, and “Resource”.
Most of these terms are already defined in RASDS, but were not carried into this slide deck. After review we determined that the RASDS definitions are fine as they are, so we will just reference them as they are in the future.</li><li style="color:black;" class="yiv4335191616MsoNormal">We discussed the casual use of terms, as in “resource” or “actor” as opposed to a formalized definition. On 10 Jan 22 we discussed capturing this distinction using bold or italics when it is
a formal use as opposed to a casual one.</li><li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
Christian asked about adding some additional examples, in addition to the abstract object, definition, and representation aspects. Peter pointed out that we did already have these for all of the viewpoints, but that they need to be reviewed.</li><li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
Fred asked about On Orbit Servicing (OOS) as an example. Peter suggested that this might be a bit esoteric as a general example, since it is essentially a very important, but quite specialized, systems of systems example. Ramon suggested we could treat this
kind of “worked example” as a CCSDS Orange Book. We could consider doing that, or find a way to create a “testimonial folder” containing info on worked examples using RASDS++.</li><li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
We then reviewed the items left from the 10 Jan 22 meeting
<ul style="margin-top:0in;" type="disc">
<li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
Pg 17: Element may be used recursively, it may be a whole or a part of a larger whole. “Element” is defined in RASDS, find it in the SANA Registry
<a rel="nofollow noopener noreferrer" target="_blank" href="https://sanaregistry.org/r/terms">https://sanaregistry.org/r/terms</a>. Any definition from Doc 311.0-M-1 is RASDS.</li><li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
Pg 50: the term “Capability” may be defined as an “enterprise capability” in an Enterprise view or a “system capability” in a system view (Functional or Connectivity view).</li><li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
Pg 51: Christian asked if we should consider adding the term “Role” to this diagram. The term “Role” is used as a few points in this deck, particularly in relationship to Enterprise VP, but it is not defined within this deck. It is, however, defined in the
existing RASDS terms as: “The way in which an entity participates in a relationship; an object’s set of behaviors and actions associated with the relationship of that object with other objects.”</li><li style="margin-left:0in;" class="yiv4335191616MsoListParagraph"><span style="color:black;">Pg 54: This list of viewpoints changes for SC14 uses the term(s) “space domain (physical, hardware, software) objects” and in this context the term “space
domain”, with whatever qualifiers, means different aspects of some class of elements that are part of space enterprises, writ large. The term “Space domain” is not in wide use, but space domain awareness is: “</span>Space domain awareness is the study and
monitoring of satellites orbiting the earth. It involves the detection, tracking, cataloging and identification of artificial objects, i.e. active/inactive satellites, spent rocket bodies, or fragmentation debris.” We may want to find a different term, or
to define it ourselves. The current RASDS definition of “domain” is strictly in the Enterprise viewpoint and may be too narrow for current purposes. Other CCSDS uses are more narrowly focused down in “protocol land”. Should we retain this term, and define
it, or drop it in terms of </li><li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
Pg 60: The term Role needs to be defined in the realm of Enterprise and “resources”, in the general sense of the word. The definition identified in notes for pg 51 may suffice.</li></ul>
</li><li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
Not discussed today, also from the 10 Jan 22 meeting:
<ul style="margin-top:0in;" type="disc">
<li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
We agreed to be careful to distinguish examples from class definitions</li><li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
We agreed to carefully include ontology and representational diagrams for each viewpoint, but not to make this be a more dominant feature than that, such as including more formalized ontological definitions in OWL or some other representation</li><li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
We agreed to define, early in the doc, what we were doing and how we were doing it vis-à-vis ontologies</li><li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
Pg 64 & 65: The operational view terms that were provided, derived largely from NIST, need to be carefully reviewed. For instance, do we really need all three of “activity”, “task”, and “work”? Would two of the three be enough? What is the relationship
of these operational / behavioral terms to Role and Resource?</li><li style="color:black;margin-left:0in;" class="yiv4335191616MsoListParagraph">
Pg 84: Are all “Connectors” in these Physical / Structural viewpoints really physical components, as opposed to the more abstract connections as in the Connectivity viewpoint?</li></ul>
</li></ul>
<p style="margin-left:.25in;" class="yiv4335191616MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv4335191616MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv4335191616MsoNormal"><u><span style="color:black;">Next Steps Discussion – Shames</span></u><span style="color:black;"></span></p>
<ul style="margin-top:0in;" type="disc">
<li style="color:black;" class="yiv4335191616MsoNormal">Peter made minor changes to the slides from 10 Jan 22</li><li style="color:black;" class="yiv4335191616MsoNormal">That updated file is attached here. Look specifically at pg 53, which was edited and re-colored to reflect the viewpoints where these various object types are defined. Note: pg 63 still needs
to be updated.</li><li style="color:black;" class="yiv4335191616MsoNormal">Review assignments. Each member of the team agreed to take responsibility for reviewing one viewpoint, and also one closely related viewpoint, for clarity, wording, definitions, and representational
consistency</li></ul>
<p class="yiv4335191616MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv4335191616MsoNormal"><b><span style="color:black;">Next Working Meeting, 14 Mar 2022 @ 0700 AM PDT</span></b><span style="color:black;"></span></p>
<p class="yiv4335191616MsoNormal"><span style="color:black;">Agenda:</span></p>
<ul style="margin-top:0in;" type="disc">
<li style="color:black;" class="yiv4335191616MsoNormal">Briefly review these notes </li><li style="color:black;" class="yiv4335191616MsoNormal"><b><i>Christian</i></b>: review updated diagrams, ontology, and representation approaches for Enterprise viewpoint and secondarily Functional viewpoint</li><li style="color:black;" class="yiv4335191616MsoNormal"><b><i>Fred</i></b>: Review updated diagrams, ontology, and representation approaches for Operational viewpoint and secondarily Enterprise viewpoint</li><li style="color:black;" class="yiv4335191616MsoNormal"><b><i>Ramon</i></b>: Review updated diagrams, ontology, and representation approaches for Physical viewpoint and secondarily Connectivity viewpoint</li><li style="color:black;" class="yiv4335191616MsoNormal"><b><i>Costin</i></b>: Review updated diagrams, ontology, and representation approaches for Functional viewpoint and secondarily Operational viewpoint</li><li style="color:black;" class="yiv4335191616MsoNormal"><b><i>Peter:</i></b> Review the entire package for consistency of topic coverage and presentation across all of the <span style="color:#070706;background:#FFEE94;">RASDS</span>++ viewpoints </li></ul>
<p class="yiv4335191616MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv4335191616MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv4335191616MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv4335191616MsoNormal"> </p>
</div>
</div>
</div>_______________________________________________<br>SEA-SA mailing list<br><a ymailto="mailto:SEA-SA@mailman.ccsds.org" href="mailto:SEA-SA@mailman.ccsds.org">SEA-SA@mailman.ccsds.org</a><br><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa" target="_blank">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa</a><br></div>
</div>
</div></body></html>