[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] Database Subcommittee / conceptual/logical model subcommittee
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:Pmaroney@Specere.org] Sent: Wednesday, June 24, 2015 1:11 PM To: Jerome Athias Cc: Richard Struse; Chet Ensign; Eric Burger; cti@lists.oasis-open.org; 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: pmaroney@specere.org On 6/24/15, 12:56 PM, "Jerome Athias" <athiasjerome@gmail.com> 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 <Pmaroney@specere.org>: >> 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: pmaroney@specere.org >> >> >> >> >> On 6/24/15, 11:39 AM, "cti@lists.oasis-open.org on behalf of Jerome >> Athias" <cti@lists.oasis-open.org on behalf of >> athiasjerome@gmail.com> >> 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 <cory-c@modeldriven.com>: >>>> 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: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On >>>>Behalf Of Jerome Athias >>>> Sent: Wednesday, June 24, 2015 7:06 AM >>>> To: Eric Burger >>>> Cc: cti@lists.oasis-open.org >>>> 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 <Eric.Burger@georgetown.edu>: >>>>> 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 >>> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]