What is the most appropriate way to handle multi-part recipes with Schema.org?
For example, a cake recipe that has two parts -- the cake batter and a frosting.
Should the two parts be separate recipe objects? Should they be grouped, without distinction, under a single recipe object? Or, is there a way to handle the separate parts under a single recipe (or other schema) object?
Here are a few relevant links:
The Schema.org Recipe type
Google Developers Recipe Page
Related
We need to create a booking system that allows rape victims to book sessions with a counsellor (who is a volunteer therefore is not on duty 24/7) online. The organisation used to do the booking process over the phone, writing down important information.
This is the package diagram I created for a project. I am not sure: am I allowed to just use the packages as entities for the class diagram?
A package is a tool to structure models by grouping somehow related pieces into namespaces.
It is not unusual to recognize a decomposition that coincides somehow with larger components (e.g. Client, Application and Data). But it is not correct to use packages as a substitute for a class. It may even look confusing.
It is not a problem to keep enclosing or nested packages such as Booking system in a class diagram. But you should use a proper class box for classes. You would then be able to show not only the properties but also the operations in a different compartment. Last but not least, you could be more precise in the relationships between classes, considering that packages are only related via dependencies and some special package operations, whereas classes can be related also with associations, inheritance, etc..
For example, your diagram tells only that Booking is dependent on Client. And this means the content of one package needs to know about the other packages. But in reality Client and Booking should be associated i.e. an instance of Client would be related for a longer time to some specific instances of Booking. In this case, you'd expect that you could easily navigate from the one to the other. Associations also allow to specify multiplicity, e.g. that one client could have 1 or more bookings, but each booking would be for only one client.
Other remarks, unrelated to the question:
Your comment box suggests that you try to explain the purpose of the system, perhaps for some stakeholders. You may therefore consider using a use-case diagram to show the big picture with the different actors and the goals they want to achieve with the system.
In a class box, you could add an «Entity» stereotype above the name of the class. Entities are domain classes that matter to the users.
Data storage system seems not to fit in the diagram: it's not really an entity. Perhaps it's a class, a component or a package, but not really an entity.
I have a language table for 2 fields id and language_name. Can I consider this as a value object?
Ex record: 1 EN
2 DE
3 TR
As soon as these values are immutable, I think I don't need to give them Ids and make it as an entity which represented in database directly.
You can consider them as value object, but you don't have to consider everything in DDD way.
According to Martin Fowler's definition:
When we use a Domain Model, we use it because it contains complicated
domain logic. It can be helpful the classify this domain logic into:
validations: checks that input makes sense and objects are properly
suited for further actions.
consequences: initiating some action that will change the state of the world
derivations: figuring out some
information based on information we already have
ValueObject s are good at validates and derivations.
Language tables, on the other hand, are usually used to solve i18n issues(ui/query conern). Generally speaking, there is no domain logic here.This kind of features are easily implemented in simple CRUD style and better for being so. Consider them in DDD add lots of constraints like only aggregates can be returned by the repository or you could only modify an local entity through it's aggregate. For example, Users edit a product, add english description and deutsch description. One can model product as an aggregate and description as value object, but this does not add much value and somtimes annoying(Now a product cannot be edited by a english editor and a deutsch editor at the same time for concurrent modification on an aggregate).
But what if there is some real domain validations and derivations on the product aggregate? like inventory and pricing. This is where bounded context comes to the play. One can have both an inventory/pricing bounded context modeled in DDD and a product description context modeled in CURD.
I have some documents and an ontology for some concepts. Are there any frameworks that automatically extracts those concepts from the given documents and creates triples? The ontology must contain special properties?
I found UIMA, but as far as I understood with UIMA I can do only something like this:
create some dictionaries which keep associations with the ontology
use this dictionary with ConceptMapper
write a CAS consumer that creates the triples and persists them -
I don't like this approach because I have to keep in sync the concepts from the ontology and the dictionary.
Can be UIMA used differently, or are there any advanced frameworks that can use directly my ontology with lets say some custom properties as input and based on it annotate the documents?
I want to use ontologies as domain model because I want to create further a knowledge base and ontologies seem more flexible than for example relational model.
Thanks.
After spending more time searching on Google I found GATE and more specifically OntoRoot Gazetter and Large KB Gazetteer.
OntoRoot Gazetteer is a type of a dynamically created gazetteer that is, in combination with few other generic GATE resources, capable of producing ontology-based annotations over the given content with regards to the given ontology. This gazetteer is a part of ‘Gazetteer_Ontology_Based’ plugin that has been developed as a part of the TAO project.
I didn't test them but these ones seem good solution candidates for my problem.
My concept is to have a logging/audit edmx file with corresponding mapped types defined in one project. This edmx has concepts and classes like AuditTrail and PropertyChange
A second edmx for the actual application models, domain if you will, with classes like Product, Category, and Order.
What I want to do is "scoop up" the first auditing edmx file into the second domain edmx. The schema information is 100% the same, the database has tables from both.
What I want to have happen is that these two edmx files are combined in such a way that I can use a transaction to save data such as both are dependent on each other finishing. My audit information can't save without my domain information and vice versa.
I've been goggling around and this seems possible I'm just missing some implementation detail thats not bringing this together.
This should be as simple as pointing the domain edxm and objectcontext connection string to the auditing edmx's csdl, ssdl, and msl files? The goal would be to load all of the MetaData information inside a single instance of an ObjectContext so I can wrap a call to both with a transaction.
This is what I have in my connection string for the web app/domain part of this application:
connectionString="metadata=res://*/Models.CfarModels.csdl|
res://*/Models.CfarModels.ssdl|
res://*/Models.CfarModels.msl|
W:\map\AuditModels.csdl|
W:\map\AuditModels.ssdl|
W:\map\AuditModels.msl;
Am I on the right track here is is this impossible?
While it is possible to load multiple CSDL files into one (Entity)Connection, it is not possible to load multiple MSL or SSDL files, because these are completely self-contained.
Back to the CSDL, there is a rarely used <using> element in CSDL. Which might give the impression that it is similar to a Reference in .NET, but actually it is more like a Merge.
I.e. one CSDL in another actually modifies both, merging them together, and potentially invalidates MSL's and SSDL's, by making them incomplete.
So back to your scenario:
You could in theory have 2 CSDLs:
1) To describe the Audit types
2) That uses (1) & defines the Domain Types and defines EntitySets and AssociationSets for both kinds of types.
You would then have one mapping file to map (2) and a storage model file too.
Which would leave you with something like this:
"metadata=res://*/Models.CfarModels.csdl|
res://*/Models.CfarModels.ssdl|
res://*/Models.CfarModels.msl|
W:\map\AuditModel.csdl;
Personally though I don't think you gain enough from this separation to make it worthwhile, most of the metadata is in the extents, the mapping and the storage model anyway, so type re-use while nice is only about 20% of the work anyway.
All you can really re-use is the audit type definitions, but that probably isn't worth the effort.
Hope this helps
Alex James
Microsoft.
I would like to experimentally apply an aspect of encapsulation that I read about once, where an entity object includes domains for its attributes, e.g. for its CostCentre property, it contains the list of valid cost centres. This way, when I open an edit form for an Extension, I only need pass the form one Extension object, where I normally access a CostCentre object when initialising the form.
This also applies where I have a list of Extensions bound to a grid (telerik RadGrid), and I handle an edit command on the grid. I want to create an edit form and pass it an Extension object, where now I pass the edit form an ExtensionID and create my object in the form.
What I'm actually asking here is for pointers to guidance on doing this this way, or the 'proper' way of achieving something similar to what I have described here.
It would depend on your data source. If you are retrieving the list of Cost Centers from a database, that would be one approach. If it's a short list of predetermined values (like Yes/No/Maybe So) then property attributes might do the trick. If it needs to be more configurable per-environment, then IoC or the Provider pattern would be the best choice.
I think your problem is similar to a custom ad-hoc search page we did on a previous project. We decorated our entity classes and properties with attributes that contained some predetermined 'pointers' to the lookup value methods, and their relationships. Then we created a single custom UI control (like your edit page described in your post) which used these attributes to generate the drop down and auto-completion text box lists by dynamically generating a LINQ expression, then executing it at run-time based on whatever the user was doing.
This was accomplished with basically three moving parts: A) the attributes on the data access objects B) the 'attribute facade' methods at the middle-tier compiling and generation dynamic LINQ expressions and C) the custom UI control that called our middle-tier service methods.
Sometimes plans like these backfire, but in our case it worked great. Decorating our objects with attributes, then creating a single path of logic gave us just enough power to do what we needed to do while minimizing the amount of code required, and completely eliminated any boilerplate. However, this approach was not very configurable. By compiling these attributes into the code, we tightly coupled our application to the datasource. On this particular project it wasn't a big deal because it was a clients internal system and it fit the project timeline. However, on a "real product" implementing the logic with the Provider pattern or using something like the Castle Projects IoC would have allowed us the same power with a great deal more configurability. The downside of this is there is more to manage, and more that can go wrong with deployments, etc.