Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

Subject: Re: [cti-users] Vote NO on JSON - Vote YES on JSON-LD and here is why...

On Wed, Nov 25, 2015 at 11:01 AM, Jerome Athias <athiasjerome@gmail.com> wrote:

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.

cti-users message