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

On Nov 25, 2015, at 09:14, Shawn Riley <shawn.p.riley@GMAIL.COM> wrote:

Just a quick reminder, the default way OBP with its semantic ontologies and serializations visualizes the OBP data is in a labeled directed-graph which is how humans think about data. The Soltra slide showing how human's visualize CTI data is a human drawn labeled directed-graph that is 99% identical to how the technology would present OBP data to humans.

<Soltra slide - how humans view intelligence.PNG>

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.

<Soltra slide - how humans view intelligence.PNG>
This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX. Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.

Subscribe: cti-users-subscribe@lists.oasis-open.org
Unsubscribe: cti-users-unsubscribe@lists.oasis-open.org
Post: cti-users@lists.oasis-open.org
List help: cti-users-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/

cti-users message