OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [cti] Database Subcommittee / conceptual/logical model subcommittee

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
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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]