You can use UML at various levels of abstraction. It has its roots in OO and can be very close to a OO language model or can be used at a more conceptual level. It depends on the subject of the model.
-Cory
-----Original Message-----
From: Patrick Maroney [mailto:]
Sent: Wednesday, June 24, 2015 1:11 PM
To: Jerome Athias
Cc: Richard Struse; Chet Ensign; Eric Burger; ; Cory Casanave
Subject: Re: [cti] Database Subcommittee / conceptual/logical model subcommittee
It may just be Semantics (go figure ;-): I was equating Conceptual <==> UML Models (UML being the "form" of the Conceptual representations). I will defer to others more familiar with model driven architectures/methodologies on other "forms" of abstraction layers/tools/representation if UML is not the correct form for same.
Patrick Maroney
Office: (856)983-0001
Cell:: (609)841-5104
Email:
On 6/24/15, 12:56 PM, "Jerome Athias" <> wrote:
>I would suggest; that a review of the currently available STIX
>Specification Documents, and UML models be performed.
>Making the STIX Specification Documents as final, to then start
>covering Observables as part of the CybOX specification documents.
>Which should be included in the roadmaps of the CTI SCs when created.
>While Conceptual Modeling would help and support the creation of UML
>models, this could potentially (if agreed by SCs) precede UML models in
>the Gantt charts.
>
>Best regards
>
>2015-06-24 19:35 GMT+03:00 Patrick Maroney <>:
>> Level-Set questions:
>>
>> I've presumed the recent "legacy" community discourse on, and
>>consensus for, the priority focus on development of the STIX/CybOX
>>UML Models was a given in the transition to OASIS. This in turn
>>implies consensus that these UML Models are key deliverables (as
>>OASIS Standards) to the CTI TC by the STIX and CybOX SCs.
>>
>> Do we need to re-visit importance of the UML Models as near term
>> deliverables or is there consensus on this point?
>>
>> Procedurally, I don't know if I should direct this to the Chair, make
>>a motion, or use some other method to establish/confirm consensus.
>>However,
>> in my view this is a critical aspect of the work we are beginning
>>which requires broad consensus in terms of specific deliverables for
>>the CTI SCs (and the sequencing/prioritization of same).
>>
>> Patrick Maroney
>> Office: (856)983-0001
>> Cell:: (609)841-5104
>> Email:
>>
>>
>>
>>
>> On 6/24/15, 11:39 AM, " on behalf of Jerome
>> Athias" < on behalf of
>> >
>> wrote:
>>
>>>I'm a great fan of conceptual models!
>>>
>>>I skipped this step while reading the specifications to go directly
>>>to a data relational model, but I can see a lot of benefits producing
>>>a CMap, especially for new adopters (just because one picture can
>>>tell thousands of words). It's easy to share also (e.g. CmapTools)
>>>
>>>The issue that I think we would encounter, is not so much about the
>>>level of abstraction (multiple CMaps could resolve that), while there
>>>is not so much concepts there (in CTI). (I used to do CMap for
>>>complex
>>>systems)
>>>It is mainly, AGAIN, related to the taxonomy.
>>>You could see that when dealing with the extensions points, figuring
>>>out what would be the most appropriate standard/specification to map
>>>CTI to. Things that are around CTI and that you have to deal with,
>>>such like Assets, Vulnerabilities, Exploits, Shellcodes, etc.
>>>But I assure you that it's fascinating ;) And while all these things
>>>are somehow linked together, it makes quite difficult to make choice
>>>to -split- this into multiple models.
>>>(you could look at it in many ways, like asset-centric, risk-based,
>>>vulnerability-based, etc.)
>>>
>>>My 2c
>>>
>>>
>>>2015-06-24 18:18 GMT+03:00 Cory Casanave <>:
>>>> There is certainly a value in a DBMS capability, perhaps one that
>>>>can be implemented across multiple technologies. This may then also
>>>>relate to the "conceptual model" initiatives which have already
>>>>started. A conceptual model can bridge the exchange and repository
>>>>viewpoints and also allow for greater flexibility in implementation
>>>>technologies. We have had great success in generating schema as well
>>>>as transformations between them from models.
>>>>
>>>> With this in mind perhaps a conceptual and/or logical model
>>>>subcommittee should be considered. Depending on the approach this
>>>>could provide some of the value that is being sought for the
>>>>database. A separation of concerns would allow for the definition of
>>>>the database in models with implementation in one or more chosen
>>>>technologies. Such implementation would probably be another
>>>>activity.
>>>>
>>>> There is some grey area in what people call conceptual and logical
>>>>models and the levels of abstraction each represents. For me (and
>>>>many others), a conceptual model is a model of how the world is
>>>>understood - it is then a model of the terms and concepts of the
>>>>world, not a data model. An "instance" of a person in a conceptual
>>>>model is a real person
>>>>- not data. A logical model is then a technology independent data
>>>>model about the world where choices are made as to structure and
>>>>representation. An "instance" of a person in a logical model is data.
>>>>An
>>>>initial activity of a conceptual/logical model subcommittee could be
>>>>to define the purpose, scope and appropriate level of abstraction.
>>>>
>>>> Of course the model activity is just as relevant to the exchange
>>>>schema and can help make them more understandable as well as provide
>>>>a basis for support of other technologies (essentially a model
>>>>driven architecture approach). This works best when the models are
>>>>the normative definition and technology schema are generated from
>>>>them.
>>>>Since this tends to introduce more change (as well as more
>>>>consistency), it would best be coupled with the second phase.
>>>>
>>>> There has already been work on conceptual models this direction
>>>>seems consistent with the communities direction. With the above in
>>>>mind we may want to consider a conceptual and/or logical model
>>>>subcommittee.
>>>>
>>>> Regards,
>>>> Cory Casanave
>>>> Representing OMG
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [mailto:] On
>>>>Behalf Of Jerome Athias
>>>> Sent: Wednesday, June 24, 2015 7:06 AM
>>>> To: Eric Burger
>>>> Cc:
>>>> Subject: Re: [cti] Database Subcommittee
>>>>
>>>> I wonder if providing consumer-oriented XQuery examples (maybe with
>>>>the STIX idioms) would help providing guidance and test/validation
>>>>cases
>>>>
>>>>
>>>> 2015-06-22 14:20 GMT+03:00 Eric Burger <>:
>>>>> Jerome (as he often does) gets this right in one (how about that -
>>>>>use a British colloquialism instead of a US one!).
>>>>>
>>>>> We just submitted a paper for publication at MILCOM looking at
>>>>>STIX/TAXII/CybOX versus IODEF/RID from the perspective of humans
>>>>>versus machines doing the processing. My guess is you can guess the
>>>>>end of the
>>>>>story: STIX/TAXII/CybOX is much better for machines. IODEF/RID is
>>>>>much better for people. Since the goal is for inter-machine
>>>>>communication, you get the point.
>>>>>
>>>>> It does mean there is a lot riding on VERY clear, implementable,
>>>>>interoperable specifications. Debugging this stuff is going to be a
>>>>>nightmare, more especially if the language is so nuanced there are
>>>>>dozens of ways of saying the same thing.
>>>>
>>>>
>>>>--------------------------------------------------------------------
>>>>- To unsubscribe from this mail list, you must leave the OASIS TC
>>>>that generates this mail. Follow this link to all your TCs in OASIS
>>>>at:
>>>>
>>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p
>>>>hp
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>>generates this mail. Follow this link to all your TCs in OASIS at:
>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.ph
>>>p
>>>
>>
