Service Endpoint Technical Asset

26 views
Skip to first unread message

GaBriella Branson

unread,
Nov 28, 2022, 4:56:39 PM11/28/22
to TopBraid Suite Users
Hello,

I am trying to determine where the data in the below image belongs in EDG. After some definition reading and relationship traversing I landed on Service Endpoint (instead of Software Service or Software API) . What questions should I be asking myself to determine if this is, in fact, the correct class to be using? I selected Service Endpoint because it has a relationship back to an Interoperable class using the "depends on data from" property.
Rest API Definitions.JPG
Service Endpoint does not have a property for the endpoint URL. Does that mean I am using the wrong class?

Also, I am getting this fun message:
Service Endpoint Data Exchange Details.JPG
I went and looked at the model and that field is a boolean it says, but where am I supposed to capture in the incoming and outgoing flows in order to populate this section?

Technical Asset Model.JPG

Apologies if this is not enough information to answer my question.

jlam...@topquadrant.com

unread,
Nov 29, 2022, 4:54:55 PM11/29/22
to TopBraid Suite Users
Hi GaBriella,
I agree with your Service Endpoint choice.  It is lacking a few properties that you'll want to add for yourself so build a Technical Asset extension model (which you likely already have :) to capture these.  If that first screenshot is a website, you should capture that in the 'location link' property of the Enterprise Context property group.  You could add 'xml link' and 'json link' to this property group so that the actual endpoint URLs are associated to each Service Endpoint.  These would be datatype properties with a value of 'anyURI'.  Alternatively, you could treat each XML link and JSON link as instances of Service Endpoint.  This decision would depend on the granularity you are after.

Regarding the fun message...I would go to that boolean property and deactivate it for now.  This field is likely auto populated by some of the lineage business logic.  I'll make sure a ticket is created to dig into this deeper.  Deactivating the property will get this message out of your way and will not hinder your development in any way.

All the best,
Jesse

Branson, GaBriella C

unread,
Nov 29, 2022, 7:23:16 PM11/29/22
to topbrai...@googlegroups.com

Thank you for the validation/input, Jesse. Much appreciated!

 

Note, we are still on 7.1 so there is a chance the message I am getting is due to our older version…

 

GaBriella Branson

Wildland Fire Data Management Program - Knowledge Manager

 

Stay Connected! Sign up to receive  email updates from the Wildland Fire Data Management Program

 

From: topbrai...@googlegroups.com <topbrai...@googlegroups.com> On Behalf Of jlam...@topquadrant.com
Sent: Tuesday, November 29, 2022 12:54 PM
To: TopBraid Suite Users <topbrai...@googlegroups.com>
Subject: [EXTERNAL] [topbraid-users] Re: Service Endpoint Technical Asset

 

 

 This email has been received from outside of DOI - Use caution before clicking on links, opening attachments, or responding.  

 

Hi GaBriella,

I agree with your Service Endpoint choice.  It is lacking a few properties that you'll want to add for yourself so build a Technical Asset extension model (which you likely already have :) to capture these.  If that first screenshot is a website, you should capture that in the 'location link' property of the Enterprise Context property group.  You could add 'xml link' and 'json link' to this property group so that the actual endpoint URLs are associated to each Service Endpoint.  These would be datatype properties with a value of 'anyURI'.  Alternatively, you could treat each XML link and JSON link as instances of Service Endpoint.  This decision would depend on the granularity you are after.

 

Regarding the fun message...I would go to that boolean property and deactivate it for now.  This field is likely auto populated by some of the lineage business logic.  I'll make sure a ticket is created to dig into this deeper.  Deactivating the property will get this message out of your way and will not hinder your development in any way.

 

All the best,

Jesse

On Monday, November 28, 2022 at 4:56:39 PM UTC-5 gabriell...@ios.doi.gov wrote:

Hello,

 

I am trying to determine where the data in the below image belongs in EDG. After some definition reading and relationship traversing I landed on Service Endpoint (instead of Software Service or Software API) . What questions should I be asking myself to determine if this is, in fact, the correct class to be using? I selected Service Endpoint because it has a relationship back to an Interoperable class using the "depends on data from" property.

Service Endpoint does not have a property for the endpoint URL. Does that mean I am using the wrong class?

 

Also, I am getting this fun message:

I went and looked at the model and that field is a boolean it says, but where am I supposed to capture in the incoming and outgoing flows in order to populate this section?

 

 

Apologies if this is not enough information to answer my question.

--
You received this message because you are subscribed to a topic in the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/topbraid-users/o6IzSQEXUVQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/4f245ac8-baf7-4d95-b43a-9539357893adn%40googlegroups.com.

Ralph Hodgson

unread,
Nov 30, 2022, 12:00:45 PM11/30/22
to TopBraid Suite Users
GaBriella,

To help the understanding of Technical Asset Models in EDG, I am trying to post 2 PDF  files as separate posts of a  (~15MB)  presentation that describes the technical assets.  So far this is failing to post to the google group.

=====

This is part 1 of a 3 part deck.

Since I am on vocation right now I could not complete the update work on how software endpoints are modeled for the purposes of describing exchanges (flow) or simply as a catalog. There is a need to distinguish what a service is from what an endpoint is. More on this later.

This is the first PDF, part1A, as a ZIP.

I will have a further revision by Monday.

Regards, Ralph
Reply all
Reply to author
Forward
0 new messages