{{{ #!comment NB! Make sure that you follow the guidelines: http://trac.posccaesar.org/wiki/IdsAdiEditing }}} [[TracNav(TracNav/IdsAdi)]] [[Image(wiki:IdsAdiBranding:Logo-128x128.gif)]] = POSC-Caesar FIATECH IDS-ADI Projects = == Intelligent Data Sets Accelerating Deployment of ISO15926 == == ''Realizing Open Information Interoperability'' == ---- = Team Member Interest Areas = These are specific interest areas of the members (See also [https://www.posccaesar.org/wiki/IdsAdiAvalonCollab the subject areas already recognized].) Adrian Laud (Noumenon) Informatio content of schematic and 3D models including geometry and geometric representation aspects. Need to populate missing classes needed. Transport mechanisms (XML’s) in addition to iRING technology. (Respnse - Note content defintions & mappings are not limited by the implementation technology choices. This content collaboration work is being done independently of the technology scopes.) Mike Oswalt (Fluor) Data sheets – currently see no distinction between physical supply chain and functional design needs. Posting formats /sheets of interest. Not just “datasheets” – but also enveloped in a business transaction … eg RFQ etc and EDI formats for these … (Response - experience of mapping datasheets shows that expectations need to be set about the scope of business processes being supported by each datasheet scope - a whole general purpose datasheet supporting all business lifecycle uses represents a huge number of objects to be mapped correctly.) Duane Toavs (Emerson) Also echo datasheets interest – in-line vortex meter and a valve examples in progress – working with Bechtel already. Also, need the “how to’s” … (Response - Tangible datasheet example are essential to learning the “how to’s” and modelling constraints of content creation & mapping, so this approach is very much encouraged - see also the business process lifecycle scope comment on datasheets above.) Gord Rachar (SNC Lavalin) Even before the “how to’s” – basic skills & knowledge to “get started” – how much do people actually need to know (non-geeky). Editing / reworking the “Primer” down to these essentials. Please feedback to Gord on the primer. Gord is interested in feedback from active participants (eg Darius) on Camelot. Keith Willshaw (Bentley) Schematics and Datasheets (and 3D less so). Major plant items in these sets. Has seen the complexity in datasheets grow to more than originally expected, so the scope / expectations point is reinforced. Tom Struzik (DOW) Echo the others. List type documents – line lists / instrument lists etc are important. Also functional areas – like comparison utilities. (Response - We generally see “lists” as part of datasheets scope … but they are a specific kind of datasheet, so we do need to classify the "document types" and scopes we are dealing with - Controlling list type documents are considered high priority.) Rahul Patil (Bentley) Might it be better if we focussed on business process interest areas rather than the content scopes ? Response - In a way yes, and yes we should already look at any content scope in terms of what is it being use for / what business process(es) is it supporting ? The "content" (including change-management / meta-data content) is nevertheless the subject of this collaboration space. We need to be careful not to excpand the scope of this space to all technical and process issues. Ivo Willems (Fluor) Exchange ''and'' collaboration – (and not just iRING technology ?) Business context … eg EDI exchange per Mike’s comment above. Meta-content / wrapper. (Response - See the responses on this work being independent of the technologies. Need to focus on the content and not get side-tracked on all the business collaboration and interoperability aspects here - HOWEVER note that one aspect / axis of the [https://www.posccaesar.org/wiki/IdsAdiComplianceSpecification compliance guideline] concerns the change management "round tripping" aspects of any batch or asynchronous transaction.) Andy Till (BP) – The progress on defining "hand-off" between suppliers and EPC’s impressive. We should also be concerned with lower levels of business maturity / expectations – maybe shallower implementations. Business drivers for EPC’s and OO’s may be subtly different – Design vs & O&M & legal / records. Is there an “OO Datasheet” … distinct from design and procure ? (Responses - How to’s do consider [https://www.posccaesar.org/wiki/IdsAdiComplianceSpecification compliance levels] and business maturity to adoption. Technology aspects of compliance levels are NOT RELEVANT to this content collaboration Wiki scope - iRING or XML Schemas or other implementation choices are not limiting here - the content issues concern the analysis and mapping of content need to support business scopes. ----