There seems to be any amount of RDF-format for the OSLC but what I'm looking for is a simple E-R-like view of the OSLC metamodel which shows the concepts and relationships which can be used to understand the organisation and possible queries.
Is there a (graphic) representation of the OSLC metamodel anywhere?
If you are after a simple graphical diagram, you can find UML models under this Lyo-Docs
repo. you can find the source .emx files, as well as .png snapshots under the folder "OSLC-V2/images/".
I you are developing OSLC applications, you might want to consider the modelling tool Lyo Designer.
There, you can find a graphical model of the OSLC Core and Domain concepts. The models are based on a OSLC-specific modelling language. Lyo Designer allows you define/extend your own models, from which you can generate an OSLC application, based on the Eclipse Lyo SDK.
I here assume you are aware of the java class implementations of the OSLC Core concepts in Eclipse Lyo. There is also an implementation of the domain specifications.
Related
I'm currently working on modeling context for a context-aware application.
The better choice seems to be ontologies, however object oriented models and relation data bases, seem to have some advantages too.
An author (Jagdev Bhogal and Philip Moore) in particular used object-relational databases to model context and claim that:
The ORDBMS approach provides limited inferencing. A subtype
definition has access to the representation of all of its direct
supertypes (but only within the ADT definition that defines
the subtype of that supertype), but it has no access to the
representation of its sibling types. 〈…〉 Such functionality would
need to be manually programmed when developing the application
interface.
I'm new to this subject, and it seems to me that you could make very complex queries to retrieve almost any information, but I've never used ontologies before.
So: in what way do object-relational databases, or even regular relational databases, provide limited inferencing, when compared to the use of ontologies (e.g. OWL Description Logic)?
Firstly, I would like to say that I am dissapointed when it comes to documentation for SAP BusinessObjects (At present we are using vesion 4.1). I can't believe that such system has such unuseful if any documentation/tutorials that cover real life examples. This is really discouraging.
Now I am comming to my question: In version 4.1. it is stated that the new version offers following feature: "Merged hierarchies can be used in reports (New)". The question is - is it possible to implement collapse/expand functionality in 4.1 version in the same way as it is displayed in the following video: https://www.youtube.com/watch?v=NEAhfX2Bqc8 (starting from 2:08 minutes). If yes - could anyone please explain how to implement the functionality or send a video tutorial that tacles with this issue?
(I assumed that the mentioned new feature is the same as the feature shown in the video, which is implemented with BEX queries. We are not using BEX queries, but our data basis is database that resides on SQL server.)
Thanks!
Hierarchies are specific to OLAP environments (e.g. SQL Server Analysis Services or SAP BW through BICS). If you're using a relational database such as SQL Server, there is no such thing as a hierarchy.
Do not confuse this with navigation paths (Information Design Tool - IDT) or object hierarchies (Universe Design Tool – UDT).
From the documentation:
A navigation path is an object that defines the drill path used in SAP
BusinessObjects reporting tools. A drill path is a list of drillable
business objects that allow a report analyst to drill down on a
dimension.
Thus, a navigation path or object hierarchy is only used to define drill paths in your document, not to hierarchically define your data in a given dimension.
More information about this:
Navigation paths: Information Design Tool User Guide, paragraph 12.14: About navigation paths for objects
Object hierarchies: Universe Designer, page 364: Defining hierarchies
If you're looking for documentation on SAP BusinessObjects, try these resources:
Analytics Knowledge Center
Official Product Tutorials – SAP BI Suite
I'm thinking about moving from EF model first to code first. The advantages look clear enough to me and it seems quite intuitve to use.
What are the disadvantages compared to model first? What pitfalls must I suspect?
There is set of disadvantages:
You must write all code by yourselves
You have lesser control over database generation
You don't have support of Database power pack for incremental database development (code first have SQL migrations but they are still in beta and doesn't provide same feature set as power pack)
You will lose some basic and almost all advanced mapping features (but those advanced features are usually not used with model first anyway).
You will most probably use DbContext API
It will be new for you (unless you already use it with model first)
You will still have to revert to ObjectContext API in more complex cases because DbContext API is only for simplest tasks
It can have additional bugs and sometimes it has even worse performance than ObjectContext API
IMHO after several months of usage and following EF tags on SO I think it is still quite unmature
Anyway DbContext API is the mainstream. Since .NET 4.5 DbContext API will be Entity Framework and ObjectContext API will be Entity Framework Core libraries. It definitely means that DbContext API is what ADO.NET team wants to push forward.
Using Linq to SQL, and a DDD style Domain Layer with de-coupled repositories, does anyone have any good ideas on how to implement a specification pattern without bleeding L2S concerns up into the domain layer, that is still understandable? :)
We have complex business logic surrounding the selection of a set of transaction data, and would like those rules/specifications to be owned by the Domain. We've also done a good job of keeping our domain persistence ignorant.
This presents a problem, because in order to implement a Specification, the domain (as far as I can tell) needs to see the types being queried (L2S types).
Any ideas?
Also, nHibernate is out of the question for reasons I don't want to explain.. :)
Have you considered mapping your generic Specifications into an Expression tree that would translate into proper L2S syntax? It seems that is the main problem you are hitting here. The Specification pattern isn't the problem, but the mapping to L2S is.
Linq-To-Sql classes can be partial. This means that you can extend them by implementing a partial that implements a common interface. That Interface can be shared between layers without the "bleeding" problem you are describing. The rest is just the details of your "IsStatisfiedBy" which should be easy to encapsulate.
I recently had the same issue. Different pattern, but still LINQ to SQL (L2S). I tried two different ways to avoid the leakage.
First we tried using DTOs and a mapping layer. So we wrote super simple objects that had a one to one mapping to the tables. They were all decorated with L2S attributes. We then wrote a mapping layer to map the DTOs to our business objects. All of this was hidden via the Repository pattern from Doman Driven Design. So consumers of the business objects had no idea the L2S was under the hood.
Next, mostly for variety. We tried using the XML mapping features of L2S so the objects themselves needed no attributes. For collections we exposed IEnumerable instead of any of L2S collections. If you looked at the internals of the business classes you could still detect some usage of L2S (EntitySet or Ref). But consumers of the class had no idea. So some bits of leakage but nothing drastic.
In the end we stuck with the first pattern. The second worked and we could have replaced L2S without changing the interface of the business layer, but I was never happy with XML mapping. The first pattern had a much cleaner separation between the database and the business objects. It took more code. The first one also worked better for us because it allowed us to evolve the business objects differently than the tables. In the early days of the project the xml mapping worked because our objects were pretty much one to one with the tables.
So in the end we put a layer between L2S and the domain. It worked. It took more code, but it was really simple stuff. And it was all very testable.
If you want to avoid referencing Linq2Sql from your domain layer, you must work against interfaces that represent your entities instead of working with the actual entities themselves. You then need a mapping layer between your interfaces and your entities.
I've worked this way and found it to be a severe hindrance. I switched to NHibernate for new projects and for the older projects I simply stopped worrying about the domain referencing Linq2Sql entities directly. Overcoming that restriction is simply too much of a time-cost in my opinion.
My newly created system was created using the Model Driven Architecture approach so all I have is the model (let's say comprehensive 'Order' and 'Product' classes). These are fully tested classes that support the business of my application. Now it's time to persist these classes as objects on the harddrive and at some later time retrieve them in the same state (thinking very abstractly here). Typically I'd create an IOrderRepository interface and eventually a ADO.NET-driven OrderRepository class with methods such as GetAll(), GetById(), Save(), etc... or at some point a BinaryFormatter-driven OrderRepostiroy class that serves a similar purpose through this same common interface.
Is this approach just not conducive to LINQ-To-Sql or the Entity Framework. Something that attempts to build my model from a pre-existing DB structure just seems wrong. Could I take advantage of these technologies but retain this 'MDA' approach to software engineering?
... notice I did not mention that this was a Web App. It may or may not be -- and shouldn't matter.
In general, I think that you should not make types implementing business methods and types used for O/R mapping the same type. I think this violates the single responsibility principle. The point of your entity types is to bridge the gap between relational space and object space. The point of your business types is to have collections of testable behavior. Instead, I would suggest that you project from your entity types onto your business types when materializing objects from the database. Separating these two allows your business methods and data mappings to evolve independently, which is very important, especially if you cannot always control the schema of the database. I explain this idea more fully in this presentation.