[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...
XORCISM took a quite similar approach... While one objective was to build a PoC to demonstrate and validate the value, a "platform-dependent" PoC was built were: - A Relational Database schema(s) (one way of materializing the UMLs) is representing the "Ontology" - The Database/Ontology was built based on (Common) Languages and Formats - The technical interoperability is demonstrated/validated by tools interacting with the Enumerations and the Database - The tools are making use of an "API" where all the -Objects- can be manipulated - The "API" (Semantic Interoperability) was generated automatically from the Database/Ontology, and so the Objects inherit from their representation (constructs) found in the Common Languages/Models - The Knowledge Repositories are directly stored in the Database - The data stored in the Database are Making Security instantly Measurable (Again, it's just a PoC.) A better representation for the Ontology is possible. BUT, all the advantages and benefits would be obtained, only, -IF-, the "(structured) raw data" can be easily and 'directly' mapped with the Ontology. JSON alone does not allow this JSON-LD could potentially XML can (with OWL/RDF) Parts of the PoC: https://github.com/athiasjerome/XORCISM PS: I found a lot of optimizations (and missing relationships) for the current STIX (and other) Data Models while working on XORCISM... 2015-11-25 17:19 GMT+03:00 Bush, Jonathan <jbush@dtcc.com>: > Seems like a powerful concept Shawn. > > > > This might be obvious, but is your hypothesis that JSON-LD is the enabling > technology to make OBP happen? Is that the ONLY way to implement OBP? > > Also, I see that the concept started in the DoD. How has the implementation > of OBP gone there? Has it been attempted (from an implementation > perspective) outside of the DoD, in commercial land anywhere? > > > > Sorry, probably too many questions at once… > > > > From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] > On Behalf Of Shawn Riley > Sent: Wednesday, November 25, 2015 6:51 AM > To: cti-users@lists.oasis-open.org > > > Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is > why... > > > > Hi Folks, > > There was another really good article discussing Object-Based Production > (OBP) in the news. As some of you might be aware, I've been focused on > applying Object-Based Production to cyber security / cyber threat > intelligence since some of discussed this methodology at BlackHat 2010 in > Vegas. It's the heart of what the Semantic eScience of Security paper was > about and how it support the science of security core themes while > modernizing analytic tradecraft. Here is a snippit of information about OBP > and link to the article. > > Shawn > > Object-based production is a concept being implemented as a > whole-of-community initiative that fundamentally changes the way the IC > organizes information and intelligence. Reduced to its simplest terms, OBP > creates a conceptual “object” for people, places, and things and then uses > that object as a “bucket” to store all information and intelligence produced > about those people, places, and things. The object becomes the single point > of convergence for all information and intelligence produced about a topic > of interest to intelligence professionals. By extension, the objects also > become the launching point to discover information and intelligence. Hence, > OBP is not a tool or a technology, but a deliberate way of doing business. > > While simple, OBP constitutes a revolutionary change in how the IC and the > Department of Defense (DOD) organize information, particularly as it relates > to discovery and analysis of information and intelligence. Historically, the > IC and DOD organized and disseminated information and intelligence based on > the organization that produced it. So retrieving all available information > about a person, place, or thing was primarily performed by going to the > individual repository of each data producer and/or understanding the > sometimes unique naming conventions used by the different data producers to > retrieve that organization’s information or intelligence about the same > person, place, or thing. Consequently, analysts could conceivably omit or > miss important information or erroneously assume gaps existed. > > OBP aims to remedy this problem and increase information integration across > the IC and DOD by creating a common landing zone for data that cross > organizational and functional boundaries. Furthermore, this business model > introduces analytic efficiency; it reduces the amount of time analysts spend > organizing, structuring, and discovering information and intelligence across > the enterprise. By extension, OBP can afford analysts more time for higher > orders of analysis while reducing how long it takes to understand how new > data relate to existing knowledge. A central premise of OBP is that when > information is organized, its usefulness increases. > > A concrete example best illustrates the organizing principle of OBP and how > it would apply to the IC and DOD. Consider a professional baseball team and > how OBP would create objects and organize information for all known people, > places, and things associated with the team. At a minimum, “person” objects > would be created for each individual directly associated with the team, > including coaches, players, the general manager, executives, and so forth. > As an example of person-object data, these objects would include > characteristics such as a picture, height, weight, sex, position played, > college attended, and so forth. The purpose is to create, whenever possible, > objects distinguishable from other objects. This list of person-objects can > be enduring over time and include current and/or past people objects or > family or previous team relationships. > > In a similar fashion, objects could be created for the physical locations > associated with the team, including the stadium, training facility, parking > lots, and players’ homes. The same could be done for “thing” objects > associated with the team, such as baseballs, bats, uniforms, training > equipment, team cars/buses/planes, and so forth. > > With the baseball team’s objects established, producers could report > information to the objects (for example, games, statistics, news for > players, or stadium upgrades), which would serve as a centralized location > to learn about activity or information related to the team. Also, > relationships could be established between the objects to create groupings > of objects that represent issues or topics. For example, a grouping of > people-objects could be created to stand for the infield or outfield, > coaching staff, or team executives. Tangential topics/issues such as > “professional baseball players involved in charity” could be established as > well. Events or activities (such as games) and the objects associated with > them could also be described in this object-centric data construct. > Moreover, the concept could expand to cover all teams in a professional > baseball league or other professional sports or abstract concepts that > include people, places, or things. > > Similar to the example above, the IC and DOD will create objects for the > people, places, things, and concepts that are the focus of intelligence and > military operations. Topics could include South China Sea territorial > disputes, transnational criminal organizations, Afghan elections, and > illicit trade. Much like the sports example, IC and DOD issues have > associated people, places, and concepts that could be objects for knowledge > management. > > Read the whole article here: > https://www.govtechworks.com/transforming-defense-analysis/#gs.MnGchY0 > > > > On Tue, Nov 24, 2015 at 3:49 PM, Terry MacDonald <terry@soltra.com> wrote: > > " Doing it upside down will not, IMHO, lead to a usable result or widespread > adoption." > > > > This comment is where I have a slight problem. The upside down development > process may not be perfect, but it has worked 'well enough' up to this > point. OASIS CTI is the largest standards group that OASIS has had so far > as I understand it, so STIX/TAXII/CybOX must be fairly useful and have > reached a reasonable adoption even in its current bohemian state to have > generated such interest. > > > > STIX itself is IMHO empirical evidence that sometimes good enough is good > enough. > > > > That said, if there is a way that we can improve the model and the way we > derive serializations without impacting implementers onerously, then I am > very keen to see it. > > > > Cheers > > > > Terry MacDonald > > Senior STIX Subject Matter Expert > > SOLTRA | An FS-ISAC and DTCC Company > > +61 (407) 203 206 | terry@soltra.com > > > > > > > > -----Original Message----- > From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] > On Behalf Of Cory Casanave > Sent: Wednesday, 25 November 2015 2:03 AM > To: Kirillov, Ivan A. <ikirillov@mitre.org>; Trey Darley <trey@soltra.com>; > Shawn Riley <shawn.p.riley@gmail.com> > Cc: cti-users@lists.oasis-open.org > Subject: RE: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is > why... > > > > Ivan, > > This is a discussion we should have. I am not opposed to well-formed OWL > either, what is important is that we have a semantic description. What we > have found in threat/risk is that in conceptual UML models we have 90% of > the expressiveness of OWL in addition to being able to assert some things > OWL is very bad at, such as the time, context and provenance of statements. > Keep in mind we are using UML based on a specific profile for this purpose. > > > > What concerns me more is statement like we should refactor first and then > look at the models. Valid refactoring at a syntax level has gone wrong every > time I have seen it as what your syntax means gets confused and > inconsistent. This becomes a barrier for implementation and > interoperability. Whatever the language of expression, the model should be > where the concepts and their relationships are figured out - we can then > come up with more or more syntax representations for it. Doing it upside > down will not, IMHO, lead to a usable result or widespread adoption. > > > > -Cory > > > > -----Original Message----- > > From: Kirillov, Ivan A. [mailto:ikirillov@mitre.org] > > Sent: Tuesday, November 24, 2015 8:21 AM > > To: Cory Casanave; Trey Darley; Shawn Riley > > Cc: cti-users@lists.oasis-open.org > > Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is > why... > > > > That doesn’t answer my question. You’re still not getting a true ontology - > just various auto-generated schemas based on UML, which I have yet to see be > proven as useful. My inclination that we really need to rebuild STIX/CybOX > from the ground up in RDF/OWL, including on making sure that we have the > right set of instances, datatype properties, object properties, etc. if we > JSON-LD or another ontology-based exchange to be useful. Otherwise, I feel > that JSON schema offers the best value in the interim and will help driven > adoption. Again, we can always revisit the JSON-LD question when we are > ready. > > > > Regards, > > Ivan > > > > > > > > > > On 11/23/15, 4:32 PM, "Cory Casanave" <cory-c@modeldriven.com> wrote: > > > >>Re: Given that, what is the value of JSON-LD in a UML-driven, XSD-derived >> representation? > >> > >>JSON-LD, JSON-Schema, RDF Schema and XML Schema can all be produced, in a >> consistent form, from a well-structured UML model. > >> > >>-Cory > >> > >>-----Original Message----- > >>From: cti-users@lists.oasis-open.org >> [mailto:cti-users@lists.oasis-open.org] On Behalf Of Kirillov, Ivan A. > >>Sent: Monday, November 23, 2015 2:50 PM > >>To: Trey Darley; Shawn Riley > >>Cc: cti-users@lists.oasis-open.org > >>Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is >> why... > >> > >>To add to Trey’s point below, JSON-LD would be a much more logical choice >> if STIX and CybOX had native ontological (RDF/OWL) representations. While >> this is likely a direction we’re heading in, it’s not where we are at today. >> Given that, what is the value of JSON-LD in a UML-driven, XSD-derived >> representation? > >> > >>Regards, > >>Ivan > >> > >> > >> > >> > >>On 11/23/15, 4:06 AM, "Trey Darley" <cti-users@lists.oasis-open.org on >> behalf of trey@soltra.com> wrote: > >> > >>>*Nor* is it the case that we are ruling out standardizing a JSON-LD > >>>CTI serialization schema *in future*. From the mail that went out > >>>Friday: > >>> > >>><snip> > >>>Likewise, the co-chairs recognize that there will be communities of > >>>interest requiring alternative serialization formats (XML, protobufs, > >>>JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to > >>>standardize these alternative representations to ensure > >>>interoperabilitity. However, that work effort lies in the future. > >>>First we must complete the task at hand. > >>></snip> > > > > > DTCC DISCLAIMER: This email and any files transmitted with it are > confidential and intended solely for the use of the individual or entity to > whom they are addressed. If you have received this email in error, please > notify us immediately and delete the email and any attachments from your > system. The recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any damage caused > by any virus transmitted by this email.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]