Recognising this, some of our (Eurostep) customers are now have the business objective to be good at cross-enterprise collaboration and are using a standards based information hub that allows them to use their in-house tools (including PLM and ERP) while receiving/publishing information to their partners. Transfer mechanisms to and from the hub include file exchange (many formats from .xls to STEP to native) and web services – whatever is needed for each partner. As I said in my comment above, the focus shifts to the information needed, rather than the file or format.

it seams everyone in the discussion wants to stop dealing with files. Let’s try to see if they are needed…

I really think a centralized approach (without file) can provide efficiency during the different phases, but the aim is a product, and intermediate aims are I think documents that describe the product in its phase.
In that extend, we could imagine that a solution could combine a DB part deal with the “drafts” or the current content of the product; with a file based approach, that masters the results of the work.

Furthemore, I hope I can in the future continue to work without been always linked to a centralized system; and to deal with manageable content that concern me. In that perspective I am quite afraid with the duality between the real complexity of a centralized solution (let’s say DB), and the simplified way to present it (everything accessible for everyone anytime, etc.)

Numerous valuable insights being shared. Good stuff.

To your question, how do I see a connection between file/dbase layers…ties into the thought I had after reading Nigel’s own comment.

While they are all we had and have, files are artificial contructs forming barriers to the true exchange of information. The more transparent the barriers become, the better. After all, this whole discussion thread isn’t even about the -content- itself, rather about the constraints (files/formats) we’ve placed around them.

The relationship? The ‘file’ will remain necessary for a long time. If only as a means of transferring encapsulated data from a provider (e.g. OEM) to a service provider (e.g. supplier). It may be something as simple as needing the file as a container of info for a machine tool.

I envision being able to tag information in a dbase and, selectively, being able to export it to a file. Working through the details here would be cumbersome. In a simple example: individual objects, whether they’re a conveyor or a 2 point line, will need to have logic enabling them to know “if ‘I’ am selected for export, then ‘these other’ objects need to go for the ride.” This logic will be governed by the mix of constraints we’ve discussed earlier: permissions, role, task, etc.

Of course, there also needs to be a mechanism for effectively tracking data for possible reintegration at some future point. Initially, it may be easiest to only allow for export of data. But a fully-functioning system will require bi-directional capability.

Individually, many of these things have been tested and used in production already. Pulling it all together, particularly with a centralized orientation, is where the next generation of real fun begins:) !