[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.php >>>> >>> >>>--------------------------------------------------------------------- >>>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.php >>> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]