I have built a custom model for identifying customer specific entities in Watson Knowledge Studio. Can i leverage and reuse standard entities (e.g. Email) which are part of the standard model in the custom model without having to redefine them from scratch?
I had the same question and found the info below - more details are at: https://watson-tricks.blogspot.com/
Post titled - "Combining the annotation capabilities of both Watson Knowledge Studio and Watson Discovery Service"
"It is not feasible for users to build a complete WKS model that incorporates all of the normal language dictionaries as well as the specialized domain terminology. However, there is a trick which can be used to get WDS to use both the domain specific annotator from WKS and the generic language annotator from WDS.
Unfurtunately this trick is not possible with the normal WDS UI, but it requires the use of the REST API"
I couldn't find enrichment for NLU. However i simply called the Analyze request two times, once with a custom model for Entities and second time without it. Got two JSON's and will combine the two to get a final list of entities. Not cost effective though as the number of requests will increase
Related
I have a business requirement where I need to expose set of custom properties defined by user and since this is user configuration, I cannot go away by creating classes. Therefore I need to opt for open types feature in Odata.
Q1. Is there any sample implementation out there on how I can persist the data to database and also support the querying capabilities on open types?
Q2. One issue I noticed is currently client library is not correctly handling open types and can only be achieved by partial classes that means user has to know the custom properties up front so that they can hand craft partial classes which is not what I want to do. Instead better approach would have been to support open types on client side by dynamic properties. Any pointers on how the client side experience can be optimized.
About query capabilities on open types, order and filter is supported in v5.5(will be released by the end of this month), query the value of dynamic properties, you can follow this pull request, part of this is in master branch now.
About persist the data to database, I think you can consider non-relational database, which can be a good choice for your open type data.
About Q2, achieve by dynamic properties is not implement in client library, maybe you can open an issue in github for us.
How can I add validation for my extensions to a resource in Spark? Typical use case: I have a look up table of values against which the extension value need to be checked against.
I assume validating each extension in a Other resource is suffice or is there hooks in spark to validate 'Other' resource?
There are multiple types of validation, some of which are currently present in the .NET library. Most of these are around validating the instances against the generic "core" definitions in the specifications of the resources, so these will not be able to validate your specific "look up tables". You can read more about these validations right here: http://ewoutkramer.github.io/fhir-net-api/validation.html
What you want to do is introduce your own "look up tables", which we call "ValueSets" in FHIR. What you'd need to do is create your own valueset, and combine this with a "profile". David Hay has written about this here: http://fhirblog.com/2014/03/11/profiles-and-valuesets-in-fhir/
Now, once you have done this, you need the .NET library to validate your instance against the profile. This is work in progress but we expect to add this functionality to the next version of the .NET NuGet package, which will arrive somewhere late august or early september.
First I want to refer to this post:
Where to put Entity Framework Data Model in MVC application?
My edmx will have 7-10 tables in it. Not more.
The problem is I have to build my model which I´m working with out of [lets say] 4 tables.
So I´m asking myself: Are these tables real model representations and would it be correct to put the edmx file in the "Models" folder and how should I name this CONTAINER of models?
Or are 10 tables enough to create a new project? How to call the project? .DataAccess? How to name the edmx file in it?
I don´t have that much experience with MVC and EF and am trying to figure out a best practice there.
Update: This post tells me not to put it in the Models folder: "The model should be decoupled from the backend data store technology as much as possible."
Personally my MVC projects (regardless of size) consist of the following as a minimum:
Data
Logic
Site
This structure seems to work pretty well as it separates business logic from storage and display.
You definitally don't want to put the EDMX in the models folder as that is reserved for view models. Best practice says that view models should be entirely disconnected from your storage entities.
In terms of naming the EDMX i normally name it after the short name of the project, the more important thing is to get the namespace right for the EDMX so your models sit in the correct namespace location.
My response is based on Silverlight and I understand it's a bit out of context because you are asking from MVC view point. But please allow me to illustrate where I put my EDMX
First project solution
-Widgets. These are multiple UI projects with multiple XAML pages
-UI logic is heavy orchestrating every widget and XAML pages in one main user interface
-View-Models. These are almost equivalent to controllers in MVC. I use XAML to directly bind to View-Models. Example QuotationItemModel.vb and xyz.vb and such. Multiple XAML pages may share 1 VM.
-XAML pages suppose to use command bindings as per implementating View-Models. Example button click is routed to VM. I didn't achieve this because the UI coordination logic (from another UI architect) was interfering with my hooking to delegate command
(of CanExecute, Execute Func(Of Object, Boolean) Action(Of Object) causing a stack overflow in first level widgets' click event.)
-Model. There is but one function here. Her job hooks a delegate to web service async call completed event and then triggers the webservice.
Deletegate's implementation actually sits back into in View-Model i.e. QuotationItemModel.vb and not inside Model. There is truly only one function in Model.vb
-There is no other logic in Model. i.e. Model.vb decides end points, http bindings, WCF stuffs
-There is no EDMX whatsoever in this solution. Model also knows nothing about database.
Second project (but inside third solution)
WCF implementation. Light weight. Again 1 function. Operation contracts only.
Code behind only pass business objects into third project.
Connection string for EDMX is configured here and passed to third project.
No other logic.
There is no awareness of EDMX whatsoever
Third project solution
-Begins with a simple factory to delegate logic and invoke classes
-Begins with simple factory logic becomes very heavy backend. Uses design patterns to alleviate maintenance concerns. From here, the patterns could criss cross between commands, strategy, or abstract types etc etc.
-The EDMX design is fully apparent in this layer
-Business objects interacts in logical manner with EDMX
-I either do LINQ to Entities or parameterized queries here
-This layer consist of business logic such as Underwriting ID must exist before a claim transaction can be issued. Or a quotation's running number sequence based on server date. etc etc
-There are some manual mapping of business objects to Entities. Potentially tedious but not always
-Result is passed back as XML
The third project could very well be separated solution with another lightweight webservice in between, producing readiness for 3 tier architecture. Then I will produce my own connection string to EDMX at this pure layer. But mine is now more like '2.5' layer 2 architecture. I sheepishly expose the connection string in middle tier's web config.
Architecture means having another hardware platform altogether. Layer are separation for domain driven design in problem space i.e. UI, communication and business domains. Technically speaking the database of SQL Server (beyond the EDMX) could very well sit in another architecture i.e. Windows Azure
There are pros and cons I see here. Please bring any criticisms gently, I am new to layering, really.
Cons
Without exposing data contracts my UI is blind when communicating in language of business objects and contracts. Previously this was easily achieved by having the EDMX in WCF layer.
I now used Xelement to represent shared business object. But I still need to figure a way to expose the data contract without exposing database internals. Currently, I 'instinctively' know and code the database fields in my Xelements.
Potentially it's like silent binding to backend EDMX. Silence is sometimes bad because if I get a column without data there are many suspected causes. Nothing that cannot be solved via good error messaging from the XML result passed-back. Using my imagination.
Weak mechanism for versioning. Perhaps new clients interacts with separate operation contract for a silent redirection to Backend-Ver 2.0 whilst the existing clients utilize Backend-Ver 1.0. This potentially mean you should now have 2 EDMX for each old and new database respectively
Pros
Extreme decoupling. I can delete/rebuild the EDMX and UI and WCF still compiles. Only my third solution will get compilation error in this extreme test effort.
From silverlight UI, triggering and communication to Microsoft Report Viewer report shares exactly same classes invoked from UI. There are no 'additional webservice function for report' whatsoever. Whatever EDMX + logic requested by UI exactly same for the report-- unless I chose it not.
PS: Silverlight communicates filter criteria to the report via query string.
The report again, is not aware of the EDMX. Example, if I delete the EDMX from backend and then update the data connection from report project and the report project still compiles without problems.
Readiness for migration to multiple architecture without tears. Seasonal load balancing, increase in customer base etc may trigger this investment in architecture.
Reusability of business logic. For example, if the boss gets tired of Silverlight, I just need to re-code the UI business objects, say, into JSON?? under HTML 5. There are no changes to business logic whatsoever, except new requirements. Example, to expand into Life Insurance to co-exist with existing General insurance, a module which is currently coded in Silverlight. Imagine Life Insurance in HTML 5 and still coexisting with same backend. Again, the reason is because both front end is not aware of EDMX I just need to focus on building data contract from within new technology.
Unexpected (I am new to layering really!) side effect. I potentially can test my backend separate from UI. Which in turn manipulate LINQ to Entity (that EDMX). Cool for unit testing.
Updating business logic does not effect new deployment to IIS (Middle layer) except maybe when it comes to versioning.
Anyway here's Layered Application Solution Guidance from talented software architect Serena Yeoh
Layered Architecture Sample for .NET
http://layersample.codeplex.com/
http://layerguidance.codeplex.com/
Notice in the sample which you download, the ingenuity of having multiple UI over different technologies over a common backend, where the EDMX live and sleep. And what's more, over windows workflow foundation, selectively called as needed. You can see where Serena put the EDMX and you have at it with workable running code. Pure bliss.
Lot's (if not most) of the current Web frameworks provide an admin module for basic CRUD operations, but I find the ones I know usually very limited...
So, my question is, which Web framework out there provide the best administration backend?
By the best, I mean namely:
Domain objects that can be heavily polymorphic. Attributes/relations defined in a class appear when editing a record/instance of any of it's subclasses (and sub-subclasses, and sub-sub-subclasses, etc).
Abstract classes. It's ok to have abstract classes anywhere in the domain classes' hierarchy. Their attributes and relations also show in the records/instances of all descending classes.
Relations. Allow to edit (out-of-the-box) the records/instances that have many-to-many relations, and relations with associative classes (e.g., django calls these intermediate models)
Extension. Allow to extend the admin so that we can use our own "UI controls" for specific domain objects. Some information is just too "exquisite" for an out-of-the-box form-based control to work in a suitable way.
UI Components. Instead of having to choose between using all of it or none of it, it'd be nice to have generic "UI controls" that one could reuse from within any page of the website, to edit specific domain objects.
Programming language is not an issue at this point, although I lean towards the languages (or frameworks) that allow me to express the most information at the domain model level (and that the admin module can then use to give me a richer UI).
I've been playing with Active Admin and Rails Admin for a couple of Rails 3.1 projects I am working on. While both are nice, I've migrated more and more to Rails Admin. I've found it easy to customize, it does a very nice job with associated models, and has a great default UI.
Rails Admin
Definitely good old WebObjects with it rule system called DirectToWeb. It generates everything at runtime based on rules. By default it can display all your entity's properties and relationships.
I guess that every current web framework will offer something like scaffolding, but often times, the work begins as soon as you change your model.
Check out this post and this teaser about the latest DirectToWeb-based framework, ERModern. You use nearly zero code for what you see in the video and you can build entire applications around it. It was sponsored by the iTunes team.
Edit for your bullet points:
Abstract classes and domain objects that can be heavily polymorphic - You handle these using rules.
Editing relations - No problem, it only depends on the design of your components. If you use ERModern, you get this for free.
Generic UI components - This is exactly how DirectToWeb works. You use (or define your own) generic components that display themselves according to the current entity (an object inheriting from EOEnterpriseObject) and the rules that fired for the current state (the D2WContext, essentially a big dictionary).
You can see all of this in action in the 45 minutes long ERModern Intro Video.
This isn't an easy question to answer.
You never specify what language you want to use, and you named some features, but how much of these features do you want.
I mean I could suggest a number of frameworks and tools for ASP.Net MVC or Web Forms but what if you're a PHP developer or a Java developer?
I could suggest SharePoint (and I generally dislike sharepoint, but everything you want is in SharePoint), but then the question to ask is.
How much flexibility and freedom do you want to customize or how much do you want the framework to do and you just be a code monkey.
So I will give you just my opinion.
I use ASP.Net MVC for my custom apps. It does all of what you want and allows me the most freedom to create and extend with tools if I so to do so. Plus out of the box there's a user databse with roles I can easily create out of the boss once I run the app for the first time.
Also CRUD is completely easy and straight forward out of the box. just check it out http://www.asp.net/mvc there's a tutorial section that goes through what you're wanting that you could complete in half a day.
Then there are some OR/M like NHibernate, Entity Framework, Subsonic use www.google.com to find tutorials for these if you're not familiar with them.
Then there's SharePoint it has a learning curve but once you get past it it's pretty straight forward as it's easy to pinpoint bugs, focus on the business logic and not worry aobut data base schema (as you don't even need to touch a database).
I love WebObjects.
WebObjects -> EntityModeler -> Wonder -> ERD2WModernLook -> ERAttachment --> ERRest
Bam. Done.
I'm creating an inventory system with Ruby on Rails as the application server and having java clients as the frontend.
Part of the project mandates that we create an integrated class diagram (a class diagram that includes all classes and shows the relationships). The way the class has been designed and what we've been taught before was to use the Boundary-Entity-Controller (BCE) pattern to create appropriate classes, however, since we're using Rails which uses an MVC architecture, they directly conflict since there is not a 1:1 correlation between the two patterns, especially considering that the 'views' in our case is just XML, so there will be no class diagram for the views and a Boundary class shares the input of the controller and the output of a view.
So far, our class diagram just features the Rails related classes (since the client classes are mostly just UI). Here is the result of what we've done so far (ignore the fact that we have a million getters and setters -- it's a requirement for the project that we won't actually be implementing in that way; we'll use attr_accessor):
So, are we on the right track? Anything to add/edit/move? How exactly do we model correctly the built in ActiveRecord validator methods that we'll be using (such as validates_numericality_of :price)?
Any help is greatly appreciated! Thanks.
It seems like you are given several constraints. If I understand it correctly, you used BCE in the analysis and MVC for architecture. In RUP there are two models for these purposes - analysis model and design model - both expressed through class diagrams. So if you want to show that you used the BCE approach as well as the MVC architecture in one monstrous diagram, you can draw Boundaries, Controls and Entities from analysis and your solution classes based on RoR for the design and connect them using dependencies with <<trace>> stereotype.
I am not entirely sure how are the validate methods implemented in RoR, my guess is, when you call validates... method in a model class definition, the particular model class is enhanced through metaprogramming with new private method, which will serve as a callback for the validation phase. I am really not sure about this, but if it is true and there is metaprogramming involved, you have a problem. AFAIK, you can either draw diagram which will show the classes after adding the methods (something like an object diagram on the class level...) or you could model the metaprogram through package merge, which is not easy as well.
You have correctly analyzed the conflict between BCE and MVC. So let's try to map your classes:
Employee, Store, Product, Location are clearly «entity»
EmployeeController, StoreController, ProductController, LocationController are clearly «control» that corresponds to the simpla management of the individual entities.
ActiveRecord is not really an entity. This shows that you are no longer in an analysis model, but already in a design model that is more refined. You could then nevertheless use «entity» since this class contributes only to their implementation.
Manager and Receiver are somewhat to ambiguous for me to categorize properly. If however, there are supposed to represent a special role of an Employee, it would be better to use composition over inheritance, because an Employee may start as Employee and then one day be receiver, and later be manager. The generalisation/specialization relationship does not allow this flexibility: if an employee is created, it will be either Manager or Receiver all its life.
What is not so clear, is if your XxxController really correspond to use-cases, and really do the coordination between the contributing classes:
Use-cases typically are described by verbs, such as Maintain employee records instead of EmployeeController.
Use-cases may need to access several entities. For example one part of maintaining employee records, is certainly to assign an employee to a store. Since the controller will be responsible to coordinate between all the objects, it should also access to store, since it needs to make sure that the store assigned to an employee really exist and is in a status that allow assignement (e.g. not in statuse "StoreShutDownDefinitively"). ANd this is absolutely not clear in your current diagram.
Last but not least, a «boundary» is in principle expected, for every link between an actor (user or remote system) and a use case. Makeing the XML is not sufficient: you need either to send the XML to another system, or display the XML on the screen, with some scrolling if needed. ANd maybe you'll have to react to requests or give the user the opportunity to query for another record:
In an analysis model you would have as many «boundary» classes as linked actors.
But in a design model, you could decide to regroup several boundaries together into one class that cover them all. But you need at least one boundary class.
I don't know RoR, but if I understand well the diagram in that article, your boundary would correspond to the view and the routing. In a classical MVC, you'd also have the controller in the boundary. But looking at the details of the article, I have the impression that RoR ActionController are in fact closer to use-cases (i.e. «control») than to an MVC controller.