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] Re: MVP Discussion


Folks,

I've been working for a couple of weeks on a paper for the CTI TC to (1) explain the notional concept of Time-Based Versioning (TBV) and (2) provide details and examples specific application to CTI Objects and Relationships.

I can demonstrate how this approach supports the highly diverse perspectives expressed on versioning requirements:

(1) Only want/need the most recent versions.

(2) Want/need to establish the full state of the data model  (2.1) at any specific point in time, (2.2) over any range of time.

(3) Want/need to query the data model for data (2.1) at any specific point in time, (2.2) or for all versions of data over any range of time.

Everyone can have it "their way": win/win. On this basis, I think its worth a look.

The initial draft of the paper that uses property graph representations to demonstrate TBV is almost ready.  Graph representations require conceptual translation to CTI JSON, so I want to add pictures/examples in our notional JSON representations before publishing. These should clearly how TBV would work and the minor changes required to separate "State" from "Structure" .

Creating the pictures/examples in our notional JSON and adding them to the paper is going to take me a while.  Please let me know directly if you are interested in reviewing/critiquing the early draft and/or contributing to the paper.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org




On Fri, Apr 8, 2016 at 4:18 AM -0700, "Terry MacDonald" <terry.macdonald@cosive.com> wrote:

Bret,

This way of doing translations causes the same problems as the explicit versioning... relationships no longer point to the latest version of an object (as there may be two translations of the same object). Which object is the 'truth'? Which version of the object is the one that everyone should connect their relationships to?

An alternative is to make all 'free-text' fields an array of text entries, and each text entry has a language attribute associated with it, so that the single object embeds multiple languages. But then this has its own problems, that there is no way for third-parties to provide a translation of another companies data (maybe that's a good thing as it isn't officially published by them)?

Another alternative would be to actually create a Translation object. This would then be used only in a translations of other objects. This would mean there is only one 'real' version of an object, and the others are specifically translations, meaning there is no confusion as to which one is the true assertion. In other words something like this:

[
  {
    "id": "report--cbf7a3eb-5ef0-42ef-a30c-14be2a14cc1d",
    "type": "report",
    "lang": "en",
    "created_at": "2016-01-29T21:18:33Z",
    "title": "Hi, this text is in English",
    "description": "So is this"
  },
  {
    "id": "relationship--7f3fcd28-9a4b-480b-852b-77e7b33db237",
    "type": "relationship",
    "source_ref": "report--cbf7a3eb-5ef0-42ef-a30c-14be2a14cc1d",
    "target_ref": "translation--5cfa580e-ea87-4d11-b0cc-600af7a64968",
    "bidirectional": true,
    "value": "translation-of"
  },
  {
    "id": "translation--5cfa580e-ea87-4d11-b0cc-600af7a64968",
    "type": "translation",
    "translated_type": "report",
    "lang": "es",
    "created_at": "2016-01-30T19:13:09Z",
    "title": "Hola, este texto es español",
    "description": "Asi es esto"
  }
]

Maybe that could work?

Cheers

Terry MacDonald | Chief Product Officer







On Fri, Apr 8, 2016 at 8:01 AM, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
Ryu,

Would something like this work for you?  We have already defined this "translation-of" relationship.  So it would be trivial to add some text to describe how it should work.  

The first report is the "original" report... You will then see a second report at the bottom and a relationship object with a type of "translation-of" that links them together.   Doing it this way will allow people other than the object creator to write a translation.  

[
  {
    "id": "report--cbf7a3eb-5ef0-42ef-a30c-14be2a14cc1d",
    "type": "report",
    "lang": "en",
    "created_at": "2016-01-29T21:18:33Z",
    "title": "Hi, this text is in English",
    "description": "So is this"
  },
  {
    "id": "relationship--7f3fcd28-9a4b-480b-852b-77e7b33db237",
    "type": "relationship",
    "source_ref": "report--cbf7a3eb-5ef0-42ef-a30c-14be2a14cc1d",
    "target_ref": "report--5cfa580e-ea87-4d11-b0cc-600af7a64968",
    "bidirectional": true,
    "value": "translation-of"
  },
  {
    "id": "report--5cfa580e-ea87-4d11-b0cc-600af7a64968",
    "type": "report",
    "lang": "es",
    "created_at": "2016-01-29T21:18:33Z",
    "title": "Hola, este texto es español",
    "description": "Asi es esto"
  }
]






Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Apr 7, 2016, at 04:45, Masuoka, Ryusuke <masuoka.ryusuke@jp.fujitsu.com> wrote:

Hi, Bret,
 
> 5) If the feature is not used in mass today,
> then it probably does not warrant being an MVP item. 
> Not used == not used.  I am sure between Soltra and EclecticIQ
> they can give us some great metrics.
 
I am a bit concerned with used in mass today.
Yes, I am thinking about Internationalization.
Without it, I cannot start accumulating CTI nor
implementing CTI systems seriously.
I am afraid that those who use a language
other than English as the primary language for his/her work
are probably a minority on this TC.
 
On the other hand, I cannot come up with very good and fair
criteria as to which to pick as MVP items...
 
Regards,
 
Ryu
 
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Wednesday, April 06, 2016 1:30 AM
To: cti@lists.oasis-open.org
Subject: [cti] MVP Discussion
 
All,
 
I have a few concerns with the current MVP items as discussed on the call today
 
1) We need a statistically significant number of people to vote, before we can decide if it is in or out.
 
2) I feel that some of the items in the list are not well understood, and thus we got mixed voting.
 
3) I think this voting needs to be moved to a SurveyMonkey and we need to add the options of "abstain" and "I do not know what this means".    
 
4) Things that have 100% votes, should be in, and we should do those first.  
 
5) If the feature is not used in mass today, then it probably does not warrant being an MVP item.  Not used == not used.  I am sure between Soltra and EclecticIQ they can give us some great metrics. 
 
6) The current list represents a LOT of stuff.  Keep in mind that it may take groups 2-5 years to full support everything in that list.  That means in the mean time you will have a lot of products that are NOT compatible with each other.  Can you imaging the conformance issues that this will cause?  Keep in mind that even Soltra Edge does not fully support STIX 1.2 and how long ago did that come out.
 
7) If the 2.0 MVP does not have everything that a group needs, say the USG.  Then they can keep using STIX 1.2 until such a time that the 2.x tree does have what they need. I do not believe any of us are saying that people need to switch from STIX 1.2 to STIX 2.0 on day one.  
 
8) For orgs that are currently using STIX 1.2.  You will probably not want to switch to the 2.x family until about 2.2 or 2.3, would be my finger to the wind guess.
 
9) For orgs that are not yet doing anything with STIX yet, what is the bare minimum that you need to make a solution work.  
 
10) Things we do not understand well or that are not really used should be pushed to a 2.x release.  

 

Thanks,
 
Bret
 
 
 
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 




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