Wikipedia

Talk:SORCER/Archive 2

< Talk:SORCER
Latest comment: 10 years ago by Timtrent in topic Selective manual archiving has a consensus
Archive 1 Archive 2 Archive 3 Archive 4 Archive 5

Selective manual archiving has a consensus

Latest comment: 10 years ago2 comments2 people in discussion

To reduce clutter here, we manually archived all discussions, some of which may still have been active. Please see "Archive 1" over to the righthand side, to view the previous info. Feel free to open a new section here, if you want to discuss something in the archives further (don't edit the "Archive 1" contents directly though... too confusing!). I've already copied the sourcing-and-tone sections from the archives, see below. 74.192.84.101 (talk) 18:02, 30 December 2013 (UTC)

Makyen has just added an automatic archiving scheme to this talk page. I have, however, reverted that addition for two reasons:
  1. The talk page as it stands is being used to reconstruct the article, and all material on it currently is germane to that reconstruction. Auto-archiving by date is inappropriate at this stage in the article's life.
  2. Addition of automatic archiving requires a demonstrable consensus to be built. That has not yet been performed.
My feelings are that the talk page should be considered for autoarchiving, but probably not before April 2014 in order to give sufficient time for much of the reconstruction to be performed. After that time it seems to me to be sensible to consider an auto-archiving scheme, but with full consensus for:
  • Doing it at all
  • number of threads to be left
  • number of days of inactivity on a thread prior to archival
It is worth considering whether, post reconstruction, this talk page will see much activity anyway. When an article is 95% complete then discussion tends to cease. I feel that is a discussion best held when the article is 95% complete, but your opinion may differ. Fiddle Faddle 10:58, 2 February 2014 (UTC)

todo list

Latest comment: 10 years ago1 comment1 person in discussion

Here are the snark-spams at the top of the article today.

  1. A major contributor to this article appears to have a close connection with its subject. (December 2013)
  2. The topic of this article may not meet Wikipedia's general notability guideline. (December 2013)
  3. This article possibly contains original research. (December 2013)
  4. This article relies on references to primary sources. (December 2013)
  5. This article may contain an excessive amount of intricate detail that may only interest a specific audience. (December 2013)
  6. This article may be too technical for most readers to understand. (December 2013)

Pretty long list.  :-)   There are actually just two basic issues. WP:RS to prove wikiNotability, which is being covered above. WP:TONE, too much jargon, and gotta stay neutral. As we go through the paragraphs, we can start to solve tag#6 and tag#5. 74.192.84.101 (talk) 15:20, 29 December 2013 (UTC)

notability and sourcing, further discussion thereof

Latest comment: 10 years ago2 comments1 person in discussion

Commentary goes here please, use the shortname of the source in the list above (if such is yet specified). 74.192.84.101 (talk) 18:02, 30 December 2013 (UTC)

Here are the key authors that work on SORCER/FIPER in the academic world, as opposed to the classified world. Cite-counts of top three papers are raw google-scholar-figures (not checked!).

  1. '00-12 w/43+36+24 cites from best papers == M Sobolewski (plus five co-authors on some of his more-recent less-cited papers ... SORCER/FIPER is the topic)
  2. '00-11 w/74+39+24 cites from best papers == RM Kolonay (plus Sobolewski on top-cited papers... plus three co-authors on some of his more-recent less-cited papers ... collaborative CAD/CAE is the topic)
  3. '03-06 w/67+23+20 cites from best papers == CD Cera (not Kolonay or Sobolewski... plus several co-authors on all papers ... secure collaborative CAD/CAE is the topic)
  4. '05-07 w/64+32+18 cites from best papers == WD Li (not Kolonay or Sobolewski... plus one distinct co-author on each paper ... collaborative product CAD/CAM is the topic)
  5. '03-08 w/27+15+11 cites from best papers == S Goel (plus Sobolewski on all papers ... plus one co-author on most papers ... collaborative CAD/etc secure grid-computing is the topic)
  6. '08-11 w/22+11+05 cites from best papers == J Yu & J Cha (plus Sobolewski on top-cited papers ... plus four co-authors on less-cited papers ... CAE/concurrent engineering is the topic)

("SORCER" OR "FIPER") ("federated" OR (distributed collaborative) OR ("exertion oriented" OR "with exertions") OR "sobolewski" OR "kolonay" OR "rubach" OR "goel" OR "nan li" OR "li nan" OR "li wd" OR "wd li" OR "berger" OR "J Cha" OR "JD Cha")

Here is the full list of papers that GoogleScholar thinks are important, organized by author.

rank/A googHit cites notes title author,year

Sobolewski

  1. 4 43 . Federated P2P services in CE environments M Sobolewski - Advances in Concurrent Engineering, 2002
  2. 18 36 ++. (s) SORCER: Computing and Metacomputing Intergrid. M Soblewski - ICEIS (3-1), 2008 -
  3. 12 24 ++. (eop) Exertion oriented programming M Sobolewski - IADIS, 2008 -
  4. 13 21 ++. (f)Zhao Context model sharing in the FIPER environment S Zhao, M Sobolewski - Proc. of the 8th Int. Conference on Concurrent …, 2001 -
  5. 6 19 . Lapinsk Managing notifications in a federated S2S environment M Lapinski, M Sobolewski - Concurrent Engineering, 2003 - cer.sagepub.com
  6. 1 19 ++. (f) FIPER: The federated S2S environment M Sobolewski - JavaOne, Sun's 2002 Worldwide Java Developer …, 2002 - 211.68.71.80
  7. 11 16 . (fmi) Metacomputing with federated method invocation M Sobolewski - Advances in Computer Science and IT, 2009
  8. 8 15 ++. (eop) Federated method invocation with exertions M Sobolewski - … of the International Multiconference on ISSN, 1896 - proceedings.fedcsis.org
  9. 7 13 ++. (eop) Federated collaborations with exertions M Sobolewski - … Technologies: Infrastructure for Collaborative …, 2008 - ieeexplore.ieee.org
  10. 24 11 . Rubach Dynamic SLA negotiation in autonomic federated environments P Rubach, M Sobolewski - On the Move to Meaningful Internet Systems: …, 2009 - Springer
  11. 27 11 . Rubach Autonomic SLA management in federated computing environments P Rubach, M Sobolewski - Parallel Processing Workshops, …, 2009 - ieeexplore.ieee.org
  12. 30 11 ++. (eop) Object-oriented metacomputing with exertions M Sobolewski - Handbook On Business Information Systems, 2010 - mfile.narotama.ac.id
  13. 32 8 ++. (eop) Exerted enterprise computing: from protocol-oriented networking to exertion-oriented networking M Sobolewski - On the Move to Meaningful Internet Systems: OTM …, 2010 - Springer
  14. 33 6 . Turner FICUS—A federated service-oriented file transfer framework A Turner, M Sobolewski - Complex Systems Concurrent Engineering, 2007 - Springer
  15. 46 5 ++. (eop) Provisioning Object-oriented Service Clouds for Exertion-oriented Programming. MW Sobolewski - CLOSER, 2011 -
  16. 55 4 . Object-Oriented Service Clouds for Transdisciplinary Computing M Sobolewski - Cloud Computing and Services Science, 2012 - Springer
  17. 43 3 . Hard File Location Management in Federated Computing Environments C Hard, M Sobolewski - International Journal of Recent Trends in …, 2009 -

Kolonay

  1. 10 74 ++: Röhl A federated intelligent product environment PJ Röhl, RM Kolonay, RK Irani, M Sobolewski… - AIAA-2000-4902, 8th …, 2000 - Citeseer
  2. 5 39  : Kolonay Federated grid computing with interactive service-oriented programing M Sobolewski, RM Kolonay - Concurrent Engineering, 2006 - cer.sagepub.com
  3. 20 24  : Kolonay Grid interactive service-oriented programming environment R Kolonay, M Sobolewski - Concurrent Engineering: The Worldwide …, 2004 -
  4. 29 7 ++: SORCER SORCER for Large Scale, Distributed, Dynamic Fidelity Aeroelastic Analysis & Optimization RM Kolonay, M Sobolewski - International Forum on Aeroelasticity and Structural …, 2011
  5. 54 7 Burton Turbine Blade Reliability-based Optimization Using Variable-Complexity Method SA Burton, R Tappeta, RM Kolonay… - & Proceedings 저널· …, 2002 - arc.aiaa.org
  6. 21 6 ++ Sampath 2D/3D CFD Design Optimization Using the Federated Intelligent Product Environment (FIPER) Technology R Sampath, R Kolonay - 2002 - arc.aiaa.org
  7. 45 4 Tappeta Application of approximate optimization to turbine blade design in a network-centric environment RV Tappeta, RM Kolonay, S Burton - … 저널· 프로시딩즈| 기술보고서| 해외 …, 2002 - arc.aiaa.org
  8. 48 3 Burton Object Models for Distrib. Multidisc'y Analysis & Optimization (MAO) Environments that Promote CAE Interoperability RM Kolonay, SA Burton - Collection of Technical Papers-10th AIAA/ …, 2004 - arc.aiaa.org

Cera

  1. 41 67 CD Cera Role-based viewing envelopes for information protection in collaborative modeling CD Cera, T Kim, JH Han, WC Regli - Computer-Aided Design, 2004 - Elsevier
  2. 58 23 CD Cera Multi-Level modeling and access control for data sharing in collaborative design T Kim, CD Cera, WC Regli, H Choo, JH Han - Advanced Engineering …, 2006 - Elsevier
  3. 59 20 CD Cera Hierarchical role-based viewing for multi-level information security in collaborative CAD CD Cera, T Kim, I Braude, JH Han, WC Regli - 2004 - DTIC Document
  4. 71 5 CD Cera Hierarchical role-based viewing for secure collaborative CAD C Cera, I Braude, I Comer, T Kim, J Han… - Proceedings of …, 2003 - gicl.cs.drexel.edu

W.D. Li

  1. 39 64 WD Li State-of-the-art technologies and methodologies for collaborative product development systems WD Li, ZM Qiu - International Journal of Production Research, 2006 - Taylor & Francis
  2. 17 32 WD Li A Web-based service for distributed process planning optimization WD Li - Computers in Industry, 2005 - Elsevier
  3. 9 18 WD Li A Web-based process planning optimization system for distributed design WD Li, SK Ong, AYC Nee - Computer-Aided Design, 2005 - Elsevier
  4. 22 12 WD Li Collaborative product design and manufacturing methodologies and applications WD Li - 2007 - books.google.com
  5. 50 4 WD Li Cooperative and Integration Mechanisms in Collaborative Product Development. WD Li, R Roy - IJEBM, 2007 - ijebm.ie.nthu.edu.tw

Goel

  1. 36 27 . Goel Service-based P2P overlay network for collaborative problem solving S Goel, SS Talya, M Sobolewski - Decision Support Systems, 2007 - Elsevier
  2. 31 15 . Goel Trust and security in enterprise grid computing environment S Goel, M Sobolewski - Proc. of IASTED Int. Conf. on Communication, …, 2003 -
  3. 26 11 . Goel Mapping engineering design processes onto a service-grid: turbine design optimization S Goel, SS Talya, M Sobolewski - Concurrent Engineering, 2008 - cer.sagepub.com
  4. 25 10 . Goel Preliminary Design Using Distributed Service-based Computing S Goel, S Talya, M Sobolewski - … of the 12th Conference on Concurrent …, 2005 -

Yu, Cha, et al

  1. 2 22 . J Yu A CAE-integrated distributed collaborative design system for finite element analysis of complex product based on SOOA J Yu, J Cha, Y Lu, W Xu, M Sobolewski - Advances in Engineering Software, 2010 - Elsevier
  2. 28 11 . J Cha A service-oriented collaborative design platform for concurrent engineering WS Xu, JZ Cha, M Sobolewski - Advanced Materials Research, 2008 - Trans Tech Publ
  3. 14 5 J Yu A Service-Oriented Architecture framework for the distributed concurrent and collaborative design J Yu, J Cha, Y Lu, S Yao - Service Operations and Logistics, …, 2008 - ieeexplore.ieee.org
  4. 37 4 ++ J Cha A manufacturing grid architecture based on Jini and SORCER W Xu, J Cha - … Perspective for Competitive Enterprise, Economy and …, 2009 - Springer
  5. 42 3 J Yu A remote CAE collaborative design system for complex product based on design resource unit J Yu, J Cha, Y Lu, Y Zhuang - The International Journal of Advanced …, 2011 - Springer

Soorianarayanan (plus Sobolewski on all papers ... distributed filesystems is the topic)

  1. 23 22 . Soorian Service-oriented file sharing M Sobolewski, S Soorianarayanan… - Proceedings of the …, 2003 - actapress.com
  2. 35 5 . Soorian Monitoring federated services in CE grids S Soorianarayanan, M Sobolewski - CE2004: The 11th ISPE …, 2004 -

Berger (plus Sobolewski on all papers ... distributed filesystems is the topic)

  1. 16 17 . Berger SILENUS–a federated service-oriented approach to distributed file systems M Berger, M Sobolewski - Next Generation Concurrent Engineering, 2005 -
  2. 15 13 . Berger Lessons learned from the SILENUS federated file system M Berger, M Sobolewski - Complex Systems Concurrent Engineering, 2007 - Springer
  3. 19 13 . Berger A federated grid environment with replication services V Khurana, M Berger, M Sobolewski - Next Generation Concurrent …, 2005 -
  4. 44 3 . Berger A dual-time vector clock based synchronization mechanism for key-value data in the SILENUS file system M Berger, M Sobolewski - Parallel and Distributed Systems, …, 2007 - ieeexplore.ieee.org

other FIPER folks

  1. 38 12 ++ Bailey FIPER: an intelligent system for the optimal design of highly engineered products MW Bailey, WH VerDuin - NIST SPECIAL PUBLICATION SP, 2001 - Citeseer
  2. 53 10 ++ Wujek A workflow paradigm for flexible design process configuration in FIPER B Wujek, P Koch, WS Chiang - Proceedings of the 8th AIAA/USAF/ …, 2000 - arc.aiaa.org

So, what this tells us is that SORCER/FIPER isn't really a computer science topic, which means that Garamond's analysis that it isn't academically notable in that niche is correct. There *are* a bunch of computer-science-papers, by Sobolewski mostly but also by Berger (the filesystem stuff) and other co-authors... however, those never took off in the world of strict EECS academia. FIPER/SORCER left TTU in 2009, and returned to their roots, working on high-end military-grade aerospace systems, in the distribute-collaborative-secure-CAD/CAE/CAM world.

  SORCER/FIPER is a software system which is used almost exclusively for industrial engineering, mechanical engineering, and especially aerospace engineering. This is a much smaller field that EECS in terms of author-population, and thus, the cite-counts are naturally smaller that Garamond is used to seeing for OOP/LISP/SOAP/etc. Does anybody know someone from NASA/ESA or Lockheed/Dassault or Boeing/Airbus or something, that can give us an idea about whether a dozen papers with 25+ cites, including three or four with 50+ cites (max 74 for the original FIPER report) is wikiNotable in the engineering disciplines? Hope this helps. 74.192.84.101 (talk) 17:15, 3 January 2014 (UTC)

dealing with terminology/jargon/neologisms

Latest comment: 10 years ago14 comments3 people in discussion
discussion with a bit more heat than light perhaps... see Talk:SORCER#paragraph two for a laser-focus, we can re-open this terminology-question thataway

Good advice, copied from the archives. 74.192.84.101 (talk) 18:02, 30 December 2013 (UTC)

  • mograms, mogramming - a new term (invented by you), which violates WP:OR. The UML? model is translated down to code, so it's just code with a service manifest. You need to explain that correctly, and get rid of mograms, mogramming. It's not cited anywhere in the firmament, except by yourself, which means it's not acceptable within WP.

"mogram (program or model or both) " with the reference to the the independent third party source "Software Language Engineering: Creating Domain-Specific Languages Using Metamodels" by the leading expert in language engineering? Tell me what's wrong with it and please stop creating circular discussions on the same topics.Mwsobol (talk) 21:50, 1 January 2014 (UTC)

  • SORCER is the first platform that created front-end service-oriented mogramming (programming or modeling or both) as the key element of its federated service orientation. (Where is the citation for this?)
    • Please show me another one that allows to define service compositions at the front-end. The fact that front-end compositions of service collaborations can be a hybrid of executable programs and executable models (mogram) is the secondary issue. If there is no another such platform with that feature then it's the first one. Are logical implications are invalid in Wikipedia?Mwsobol (talk) 15:14, 1 January 2014 (UTC)
      • That is not the way it works. Citations are required here. If it is the first then something must show that it is the first. Otherwise it may simply be stated to be "a platform" Fiddle Faddle 16:49, 1 January 2014 (UTC)
  • Exertions Why? Not programs, applications, services? You need to explain why it was called that. I think it's the same as mogramming, re who is citing it generally, and if it's only you, it will not be acceptable.
    • Semantically different things have names, so please try to understand the semantics of exertions first. A front-end and back-end services have different semantics. A service composition at the server (back-end) is done by a programmer and deployed by a deployer before it is used by the end user. A service composition at the font-end (exertion) is created and executed by the end user at runtime. For interpreted exertions (netlets) no compilation and deployment is needed to run service compositions.Mwsobol (talk) 15:29, 1 January 2014 (UTC)
  • SORCER is the first system enabling front-end service-oriented programming with the relevant operating system and dynamic back-end service federations as its virtual processor. That's neat, but don't know if it's true. I think Gigaspaces has a similar mechanism. You will certainly need a citation for this, other wise it's a false assertion, and will need to go.
    • Gigaspaces is just the commercial implementation of JavaSpaces (one of Jini services) to support space computing. It's a space computing middleware based on the JavaSpaces technology. You can write into a Jini space any object, it's generic. In SORCER what is called an exertion space is a JavaSpace service (can be Gigaspaces, we use open source Blitz or Jini JavaSpace) to provide space computing (synchronous federations) for exertions. However with synchronous execution (PUSH vs. PULL in SORCER) the service providers are accessed directly by SOS. You can create an exertion with mix of PUSH/PULL strategies so a part of service providers is accessed directly by SOS and another part reads exertion requests from the exertion space. That is done with the unique SORCR's federated method invocation (FMI). So JavaSpace (Gigaspace) is just one of SOS modules used for FMI.Mwsobol (talk) 15:51, 1 January 2014 (UTC)
  • The rest of the unexplained, non linked article content like Providers use discovery/join protocols to publish services in the network and the SOS uses discovery/join protocols to discover registries and lookup proxies in those registries. What providers? What discovery/join protocols, etc etc etc.
    • Terms service providers (services) and discovery/join protocols come from Jini terminology. The SORCER OS implementation uses Jini technology that defines its SOOA architecture. I assume that was stated explicitly in the article.Mwsobol (talk) 15:59, 1 January 2014 (UTC)

Lastly, it's written more as a reference manual, and currently doesn't make sense, lacks context and flow. The whole product seems to be built using Java, so how is it different from you average Java EE application server, like Weblogic or WebSphere. Sorry the criticism is so heavy. I knows your trying your best. scope_creep talk17:31 12 Dec 2013 (UTC)

  • I can comment shortly (read at least one paper on SORCER if you want to see differences): SORCER is the federated platform (programming environment (exertions and var-models), service-oriented OS with FMI, and federated processor) it's not a server or a middleware. Exertion-oriented programming and var-oriented modeling in SORCER has nothing to to with Java syntax and semantics they are completely new service languages. The fact SORCER in part is implement with Java has nothing to do with the SORCER architecture and programming/modeling model.Mwsobol (talk) 16:07, 1 January 2014 (UTC)
    • Is this paper on SORCER a WP:RS? If not then it is not relevant. Please at least get to understand the Wikipedia environment. Talking for ever round this subject produces nothing except fluff and clutter. It is presumed that your own work environment has rigour. So does Wikipedia. Our rigour is an insistence on correct reference material. Talking round and round abut this topic without making forward progress reinforces my original beliefs about this. Not every workplace is WP:N. Fiddle Faddle 16:56, 1 January 2014 (UTC)
With the neologisms, may I suggest a special reference group named, perhaps neologism where a correct textual explanation is given , but in layman's language. I am sure I've explained this style of scheme to you before, but I only now see the application in this manner. One may have multiple names reference groups in an article. The only caveat is that the associated {{Reflist}}must come after the final instance on the page. Thus one may also have a group named note, another named Dr Pepper, and so forth. Fiddle Faddle 16:09, 29 December 2013 (UTC)

The hits on google-scholar gave me some insight into when the various terms first cropped up in the literature.

  1. "SORCER", first mentioned 2003/2004 but counts became much stronger by 2007/2008
  2. "federated method invocation" , 2007/2008
  3. "exertion oriented" OR "with exertions" , first mentioned 2007/2008
  4. "mogram" OR "mogramming" , first mentiond 2011/2012
  5. "FIPER" , first mentioned 2000/2001 but became much stronger by 2004/2005/2006
various papers with 3+ cites, organized by year, and with jargon-count

The five jargon-keywords mentioned above are represented in this list by the first column, "x" means hit, "_" means no hit. So for instance, "__x_x" means exertions & fiper, but not sorcer/fmi/mogramming.

FIPER in computer aided engineering

  1. ____x 2000, Cited by@74 , A federated intelligent product environment. PJ Röhl, RM Kolonay, RK Irani, M Sobolewski, Kevin Kao - AIAA-2000-4902, 8th …, 2000 - Citeseer xx
  2. ____x 2000, Cited by 10 , A workflow paradigm for flexible design process configuration in FIPER B Wujek, P Koch, WS Chiang - Proceedings of the 8th AIAA/USAF/ …, 2000 - arc.aiaa.org
  3. ____x 2001, Cited by*21 , Context model sharing in the FIPER environment S Zhao, M Sobolewski - Proc. of the 8th Int. Conference on Concurrent …, 2001 - sorcersoft.org
  4. ____x 2001, Cited by 12 , FIPER: an intelligent system for the optimal design of highly engineered products MW Bailey, WH VerDuin - NIST SPECIAL PUBLICATION SP, 2001 - Citeseer
  5. ____x 2002, Cited by^17 , A distrib.component based integration env.for multidisc'y optimal & quality design BA Wujek, PN Koch, M McMillan… - 9th AIAA/ISSMO …, 2002 - arc.aiaa.org
  6. ____x 2003, Cited by^18 , Towards a standardized engin'g framework for distrib, collab.product realization HJ Choi, JH Panchal, JK Allen… - Proceedings of …, 2003 - westinghouse.marc.gatech.edu
  7. ____x 2004, Cited by*20 , Hierarchical role-based viewing for multi-level info.sec.in collab. CAD CD Cera, T Kim, I Braude, JH Han, WC Regli - 2004 - DTIC Document
  8. ____x 2004, Cited by@67 , Role-based viewing envelopes for information protection in collaborative modeling CD Cera, T Kim, JH Han, WC Regli - Computer-Aided Design, 2004 - Elsevier dtic.mil
  9. ____x 2005, Cited by 09 , A distributed mechanical system simulation platform based on a “gluing algorithm” J Wang, ZD Ma, GM Hulbert - Journal of Computing and Information Science in …, 2005
  10. ____x 2005, Cited by@53 , Tech'y solutions for collab. product lifecycle mgmt–status review & future trend XG Ming, JQ Yan, WF Lu, DZ Ma - Concurrent Engineering, 2005 - cer.sagepub.com
  11. ____x 2005, Cited by^18 , A Web-based process planning optimization system for distributed design WD Li, SK Ong, AYC Nee - Computer-Aided Design, 2005 - Elsevier
  12. ____x 2005, Cited by*32 , A Web-based service for distributed process planning optimization WD Li - Computers in Industry, 2005 - Elsevier
  13. ____x 2006, Cited by@64 , State-of-the-art tech's & methodologies for collab. product development systems WD Li, ZM Qiu - International Journal of Production Research, 2006 - Taylor & Francis
  14. ____x 2006, Cited by*27 , Document-driven design for distrib. CAD services in service-oriented architecture Y Wang, BO Nnaji - Journal of computing and …, 2006 - www-old.me.gatech.edu
  15. ____x 2006, Cited by*23 , Intellectual property protection in collab.des.thru lean info.modeling & sharing JC Brustoloni, BO Nnaji - Journal of computing and …, 2006 - www-old.me.gatech.edu
  16. ____x 2006, Cited by*23 , Multi-Level modeling and access control for data sharing in collaborative design T Kim, CD Cera, WC Regli, H Choo, JH Han - Advanced Engineering …, 2006 - Elsevier
  17. ____x 2007, Cited by 05 , An adaptable service-based framework for distributed product realization JH Panchal, HJ Choi, JK Allen, D Rosen… - Collaborative Product …, 2007 - Springer
  18. ____x 2007, Cited by*27 , Service-based P2P overlay network for collaborative problem solving S Goel, SS Talya, M Sobolewski - Decision Support Systems, 2007 - Elsevier
  19. ____x 2007, Cited by 12 , Collaborative product design and manufacturing methodologies and applications WD Li - 2007 - books.google.com
  20. ____x 2007, Cited by 04 , Cooperative and Integration Mechanisms in Collaborative Product Development. WD Li, R Roy - IJEBM, 2007 - ijebm.ie.nthu.edu.tw
  21. ____x 2008, Cited by 04 , Complex product collab. des. & sim'n based on product master model technology J Ji, D Zhang, S Li, B Wu, B Chen - … Technology and Automation …, 2008 - ieeexplore.ieee.org
  22. __x_x 2008, Cited by 11 , Mapping engineering design processes onto a service-grid: turbine design optim. S Goel, SS Talya, M Sobolewski - Concurrent Engineering, 2008 - cer.sagepub.com

SORCER == in computer science

  1. x____ 2001, Cited by 05 , Context Model Sharing in the SORCER Environment S Zhao, M Sobolewski - 2001 - forthcoming
  2. x____ 2003, Cited by*22 , Service-oriented file sharing M Sobolewski, S Soorianarayanan, Ravi-Kiran - Proceedings of the …, 2003 - actapress.com
  3. x___x 2003, Cited by^15 , Trust and security in enterprise grid computing environment S Goel, M Sobolewski - Proc. of IASTED Int. Conf. on Communication, …, 2003 - sorcersoft.org
  4. x____ 2004, Cited by 03 , Grid computing at texas techuniversity using sas R Bremer, J Perez, P Westfall - Proceedings of the 14th Annual South- …, 2004 - scsug.org
  5. x____ 2004, Cited by 05 , Monitoring federated services in CE grids S Soorianarayanan, M Sobolewski - CE2004: The 11th ISPE …, 2004 - sorcersoft.org
  6. x____ 2007, Cited by 03 , A dual-time vector clock based sync'n mechanism for key-value data in SILENUS f.s. M Berger, M Sobolewski - Parallel and Distributed Systems, …, 2007 - ieeexplore.ieee.org
  7. xxx_x 2007, Cited by^15 , Federated method invocation with exertions M Sobolewski - … of the International Multiconference on ISSN, 1896 - proceedings.fedcsis.org
  8. x____ 2008, Cited by 05 , Service-oriented programming M Sobolewski - 2008 - SORCER Technical Report SL-TR- …
  9. xxx_x 2008, Cited by 13 , Federated collaborations with exertions M Sobolewski - … for Collaborative Enterprises, 2008. WETICE'08 …, 2008 - ieeexplore.ieee.org
  10. xxx_x 2008, Cited by*24 , Exertion oriented programming M Sobolewski - IADIS, 2008 - sorcersoft.net
  11. xxx_x 2008, Cited by*36 , SORCER: Computing and Metacomputing Intergrid. M Soblewski - ICEIS (3-1), 2008 - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.4371&rep=rep1&type=pdf
  12. xxx_x 2009, Cited by^16 , Metacomputing with federated method invocation M Sobolewski - Advances in Computer Science and IT, 2009 - sorcersoft.org
  13. xxx__ 2009, Cited by 03 , File Location Management in Federated Computing Environments C Hard, M Sobolewski - International Journal of Recent Trends in …, 2009 - sorcersoft.net
  14. xxx__ 2009, Cited by 11 , Dynamic SLA negotiation in autonomic federated environments P Rubach, M Sobolewski - On the Move to Meaningful Internet Systems: …, 2009 - Springer
  15. xxx__ 2009, Cited by 11 , Autonomic SLA management in federated computing environments P Rubach, M Sobolewski - Parallel Processing Workshops, …, 2009 - ieeexplore.ieee.org
  16. xxx__ 2010, Cited by 08 , Exerted enterprise computing: from protocol-oriented networking to EO networking M Sobolewski - On the Move to Meaningful Internet Systems: OTM …, 2010 - Springer
  17. xxx_x 2010, Cited by 11 , Object-oriented metacomputing with exertions M Sobolewski - Handbook On Business Information Systems, 2010 - mfile.narotama.ac.id
  18. xxxxx 2011, Cited by 05 , Provisioning Object-oriented Service Clouds for Exertion-oriented Programming. MW Sobolewski - CLOSER, 2011 - sorcersoft.org
  19. xxxxx 2012, Cited by 04 , Object-Oriented Service Clouds for Transdisciplinary Computing M Sobolewski - Cloud Computing and Services Science, 2012 - Springer

SORCER in computer aided engineering

  1. x____ 2004, Cited by 03 , Object Models for Distributed MAO Environments that Promote CAE Interoperability RM Kolonay, SA Burton - Collection of Technical Papers-10th AIAA/ …, 2004 - arc.aiaa.org
  2. x____ 2005, Cited by^17 , SILENUS–a federated service-oriented approach to distributed file systems. M Berger, M Sobolewski - Next Generation Concurrent Engineering, 2005 - sorcersoft.net CS + CAE
  3. x____ 2005, Cited by 13 , A federated grid environment with replication services V Khurana, M Berger, M Sobolewski - Next Generation Concurrent …, 2005 - sorcersoft.org CS + CAE
  4. x_x_x 2007, Cited by 13 , Lessons learned from the SILENUS federated file system M Berger, M Sobolewski - Complex Systems Concurrent Engineering, 2007 - Springer CS + CAE
  5. xx__x 2007, Cited by 06 , FICUS—A federated service-oriented file transfer framework A Turner, M Sobolewski - Complex Systems Concurrent Engineering, 2007 - Springer CS + CAE
  6. x_x__ 2008, Cited by 11 , A service-oriented collaborative design platform for concurrent engineering WS Xu, JZ Cha, M Sobolewski - Advanced Materials Research, 2008 - Trans Tech Publ CS + CAE
  7. x___x 2008, Cited by 05 , A Service-Oriented Architecture framework f' distrib. concurrent & collab. design J Yu, J Cha, Y Lu, S Yao - Service Operations and Logistics, …, 2008 - ieeexplore.ieee.org
  8. x____ 2009, Cited by 05 , The physics of an optimized flapping wing micro air vehicle C Chabalko, D Snyser, P Beran, G Parker - Proceedings of the 47th …, 2009 - arc.aiaa.org
  9. x_x_x 2009, Cited by 04 , A manufacturing grid architecture based on Jini and SORCER W Xu, J Cha - … Perspective for Competitive Enterprise, Economy and …, 2009 - Springer
  10. xxx_x 2010, Cited by*22 , A CAE-integ.distrib.collab.des.sys.for fin.el.analy.of complex prod.based on SOOA J Yu, J Cha, Y Lu, W Xu, M Sobolewski - Advances in Engineering Software, 2010 - Elsevier
  11. xx___ 2010, Cited by 06 , 面向复杂产品的分布式协同设计系统 于加晴， 查建中， 陆一平， 徐文胜. 中南大学学报: 自然科学 edu.zndxzk.com.cn/down/upfile/soft/2010428/26-p0539-08609.pdf
  12. x_x__ 2011, Cited by 03 , Network alliance for the total life cycle of reconfigurable machine tool L Ma, J Li, W Xu, J Liu - Management Science and Industrial …, 2011 - ieeexplore.ieee.org
  13. xxx_x 2011, Cited by 03 , A remote CAE collab.des.sys. for complex product based on des. resource unit J Yu, J Cha, Y Lu, Y Zhuang - The International Journal of Advanced …, 2011 - Springer
  14. x____ 2011, Cited by 07 , SORCER for Large Scale, Distri, Dynamic Fidelity Aeroelastic Analysis & Optim. RM Kolonay, M Sobolewski - International Forum on Aeroelasticity and Structural …, 2011

Only about half of the post-2008 CAE papers mention exertions, or FMI ... and many will mention one but not the other... but they all (in this list anyways) mention SORCER (plus sometimes FIPER). By contrast, 100% of the post-2008 EECS papers mention both exertions and FMI, whenever they mention SORCER. Per the google-scholar-analysis in the talkpage section above, which says the academic-genre FIPER&SORCER belong to is CAE/CAD/CAM rather than EECS qua EECS, plus given the history of when the terms arose, it seems pretty clear to me that the main article should be called SORCER, with FIPER as a large subsection. Wikipedia already has an article on concurrent engineering, but not on distributed CAD nor collaborative CAD; maybe another name for the latter? HTH. 74.192.84.101 (talk) 17:33, 3 January 2014 (UTC)

This discussion has been circular since the start

Latest comment: 10 years ago7 comments4 people in discussion
AfD#2 was ended with a 'keep' so we are making progress, AfD#1 could only manage 'no consensus'

Despite enormous efforts by experienced Wikipedia editors to find WP:RS, to show WP:N and to ensure WP:V, the discussion has proved to be an endless round of:

  1. Show me that this is notable
  2. It is notable because it is notable
  3. Give me the reference
  4. The reference is somewhere in this list of probably non WP:RS material
  5. If I find it, show me that this source is WP:RS
  6. It must be reliable because I say it is reliable
  7. Return to number 1

This has been going on for a couple of days short of two months. This alone shows me that the topic is not notable. Were it to be notable this would have been proven a long time ago. Doubtless people use this environment. Good. Maybe it will become notable one day. Today it is not.

Yes, we have WP:NODEADLINE, but there is a threshold of notability all articles must pass. We cannot faff around for ever with those who work in SORCER telling us for ever that their project is notable without clarity of answers to questions. It is time for clear answers. If the SORCER folk can show that this is WP:N by proving the bona fides of their sources to be WP:RS, now is the time. Fiddle Faddle 17:18, 1 January 2014 (UTC)

support-- TRPoD aka The Red Pen of Doom 17:36, 1 January 2014 (UTC)
(( redacted beginning-editor frustration ... will discuss on their talkpage ))    — 74.192.84.101 (talk) 17:54, 3 January 2014 (UTC)

How to explain SORCER conceptualizations?

Latest comment: 10 years ago2 comments2 people in discussion

I was alarmed about the confusing SORCER conceptualizations above, so let's hope the clarification by analogy to a common computing platform will help to understand unique features of the SORCER platform. By the way, conceptually it does not have anything common with grid computing or web services. The fact you can do grid computing or run web services in SORCER does not mean it was designed directly to do so.

Let's consider a common computing platform (or runtime: programming environment, operating system, processor). For example, a UNIX platform (programming environment - Unix shell programming, a UNIX operating system, and a native or virtual processor such that the operating system can execute programs (executable codes) compiled for this platform. So, each platform has a front-end (shell or command processor), a back-end (executable codes) and in the middle (an operating system). A common platform is used predominantly to execute a single command that runs the executable code in the shell locally. Advanced users can write a shel script (in a file or at the command line) to create a pipeline of locally executing programs (pipes are local). The fact that an executable code can provide networking internally using for example sockets or any application protocol (FTP, SMPT, HTTP) is the feature of a program (application) not the platform. The common platform runs executable codes locally.

Now let's imagine that a platform at the back-end instead of local executable codes has applications, tools, utilities that can be provisioned on-demand in the network at runtime (they constitute a network processor of the platform). Now the shell script can define any collaboration (service pipeline (batch), workflow, block for branching and looping) of back-end services that can be found or provisioned in the network at runtime. These scripts define front-end services (programs) as collaborations of back-end services. The shell now executes front-end services and the operating system can run any collaboration of back-end services. These collaborations of backend services for each front-end service are called service federations. The paradigm is called federated service-oriented computing since a shel invokes a federation of service providers. To do so the operating system needs a new invocation method, instead of invoking a single program or pipeline of programs locally invokes a federation of back-end services in the network for each front-end service. Please match the above description to the chart of the SORCER OS in the article. Note that all other service platforms provide service collaborations at the back-end (called an applications server) only.

The above federated platform defines: a front-end service (exertion), a singleton back-end service (a service provider), and a back-end collaboration of services (federation) specified by a front-end service. When developing the FIPER architecture I have introduced the terms given in parenthesis to emphasize three types of completely different service semantics in federating computing. If you prefer, you can use longer names in the article: front-end service, back-end service, and a collaborative service at the backed defined by the front-end service. By the way a front-end service is a collaborative service as well but at the front-end as the virtual service (realized at the back-end by its federation). Also, calling a front-end service as a "service script" like UNIX script is confusing due to completely different semantics of the network shell, operating system, and the processor as a collection of dynamic service federations. SORCER front-end scripts are called "netlets". An exertion is a more generic concept for a front-end specification of a back-end federation. Formally, an exertion is a metamodel with models in the form of "netlet" (textual), "exertlet" (any object that implements Exertion interface, created with API), and "service diagram" (visual programming - interactive GUI). Therefore a netlet, exertlet, and service diagram are exertions. Three different forms of front-end services have to be called differently and three types of services (exertions, service providers, and federations) in federated computing have to be called differently.

The SORCER lab completed research in all aspects of federated computing as described above. Other organizations including AFRL develop federated service applications using the TTU SORCER platform. The research papers by AFRL are focused on how to design air vehicles using SORCER but not how to design SORCER. I assume this article is about the TTU platform architected, designed, and implemented at the SORCER lab as the extension of FIPER. The currently offered open source version maintained by SORCERsoft.com is the implementation completed at the SORCER lab. Thus, please drop any unjustified relationships of the TTU SORCER technology to other organizations that can be used as the secondary sources regarding how SORCER is used. They spent own money on the projects related directly to they business objectives. When they say we develop SORCER it means that develop tools to make SORCER easier to use with their applications. SORCERsoft.com is not developing the SORCER technology as well, the company is developing tools for interactive exertion-programming and var-oriented modeling. They do what Apple has done with BSD UNIX for Mac OSX. There is no any research paper on the SORCER technology from other places than the SORCER lab (sorcersoft.org) since that core technology is open to any organization with no need to redevelop it. I still assume the article should be about the core SORCER technology that originated from NIST FIPER and TTU SORCER.Mwsobol (talk) 02:59, 1 January 2014 (UTC)

During my reading of this explanation, I replied above, which methinks covers the meat of where I am confused. The bullet-points here are just clarifications or quibbles, to make sure we are on the same page after we get to the heart of how exactly server-side back-end service-providers are practically implemented... are they just a server-side exertion with some config-stuff to make them network visible? If not, what exactly *are* service-providers implemented as? Anyhoo, on with the bullet-points.
  • 0. "...conceptually (SORCER'13) doesn't have anything common with grid computing, or web services." Quibble: conceptually speaking, that may be true, but SORCER'08 is described in the sources *as* a grid-computing solution, and used by e.g. DaytonThesis of 2012 primarily *for* the grid-computing features. The sources call SORCER'08 grid-computing, and wikipedia follows the sources. Wikipedia is supposed to document both the current state (as documented in WP:RS) of a topic, as well as the historical evolution of a topic. Therefore, SORCER'03 is relevant tothe wikipedia article, and it *was* a web service implementation, from what Pawel hinted, right? As for FIPER, which this article will also document the history of, it is definitely distinct from SORCER'13 in many ways.
  All that being said, wikipedia IS NOT MEANT to give an elegant theoretical abstract description of SORCER's conceptual architecture. Why? Because less than 1% of the readership will understand such a thing. Wikipedia has to explain FIPER'00/SORCER'03/SORCER'08/SORCER'13 properly, which means, in term s the readership will find more understandable. Therefore, whenever possible, we avoid abstract fuzzy concepts, we use metaphors relating SORCER-features to things the reader has already likely heard of, we keep jargon/neologisms/TLAs/multisyllabicisms to the absolute minimum, and so on. Wikipedia *can* have advanced concepts, but we cannot start out in the first sentence, packing it full of ten fancy words. That will be useless to most readers.
  We have to explain the topic slowly and thoroughly, from the ground up. Is SORCER being used in the wild, as documented by WP:RS, for grid computing? Yes. Do the sources call it that? Yes. Will the readership understand what grid computing is? Yes, and if not, they can read grid computing. Even more readers understand web services, than understand grid computing; it is dramatically easier for the readership for us to say that SORCER is some kinda grid computing infrastructure for CAE, and sorta implemented with non-URL-based web services, and then go on to explain SORCER better, later, than it is to just smash the reader's gumption instantly. :-)   A bit further down, you had suggested a barebones-UNIX-platform metaphor, which is a great idea, see numbered sections below.
  I suggest we start with the barebones-UNIX-platform, and then extend it, and speak of ssh and cURL and such (more on this in a minute). Then we can speak of an analogy to web services. Then to grid computing, as a metaphor to improve understanding, plus also because SORCER is often used thataway. Finally, we'll get to the EECS meat: exertions as classifiers of federation-instances, all running on a virtualized meta-operating-system. Everything will be clear in the reader's mind, the metaphors can drop away, and then can head for the Further Reading section where all the key papers over the years are listed. Plus, at the tail end of the descriptive overview, we can cap off the descriptive-section of the article with the newly-cited-in-2011 mogramming, and a brief mention of the as-yet-still-classified var-oriented stuff. Another portion of the article can cover history of the concept, and the researchers who helped. Another section will cover killer applications, the aircraft-engine design at GE/GRC with Engenious, the traffic-noise-mapping by Nan Li, and the auto-optimizing physics-based-predicting CAD/CAE work by AFRL, among others.
  1. "The fact you can do grid computing or run web services in SORCER does not mean it was designed directly to do so." Correct, and important. The article *should* describe the historical design-goals of FIPER'00/SORCER'03/SORCER'08/SORCER'13, in turn, and it should do so accurately. That said, it should also describe what customers/funders/endusers actually did with SORCER, and usually that means grid-computing for aerospace-design CAE/CAD efforts. Right?
  2. "...a common computing platform (or runtime: programming environment, operating system, processor)." See my note over on WT:Articles_for_creation/Exertion-oriented programming, about the traditional meaning of the terms operating system, software platform, hardware platform, programming environment, API, processor, and runtime. Because wikipedia uses these terms in the way that traditional sources use them, and more importantly, because the readership *expects* that when we say operating system we mean something like Win7 / OSX10.6 / Ubuntu1204 / Android 4.0 , there is simply no way that we can call the SOS an 'operating system' without scarequotes and an immediate explanation that it is really a meta-operating-runtime-platform-thingamabob.
  3. 'UNIX platform' == native (or virtual) CPU, with Linux/BSD/similar UNIX-like OS installed, logged into a command-line bash shell, which can execute both compiled javac apps, as well as interpreted shell scripts (usually bash). Okay, fair enough, this is a description of a 1980s-style UNIX workstation, with no GUI and no ssh and no VNC, plus of course, not graphical web browser and no graphical multimedia-player. So I would dub it the barebones-UNIX-platform.
  4. "each platform has a front-end shell, in the middle an operating system, and a back-end (executable codes)" This description does not match my understanding of Linux. There is a front-end shell, which provides two main features, the usermode interactive TUI and also the shebang-based interpreted usermode shell-scripts. There are compiled apps too, in our hypothetical barebones-UNIX-platform using javac. Even they are still usermode apps, and of course, just like shell-scripts; and under the hood, our shell-scripts are converted from Unicode text into binary CPU opcodes, before actually getting executed by the processor. And technically, java apps are only partially compiled, into bytecode which is later interpreted by the JVM into raw CPU opcodes (at runtime via JIT). In the middle is the kernel mode portion of the operating system, which provides the system-level API, used by the JVM and the bash-interpreter. At the back end is the physical hardware, including GPU and CPU and drives and keyboard-microcontroller and such.
  5. "...to create a pipeline of locally executing programs (pipes are local)." Yes, typically... though our barebones-UNIX-platform is lacking ssh, which *does* allow non-local scripts, and you can even use ssh-tunnelling of GUI apps. Of course, nowadays we also have web-apps and various sorts of web-automation tools, such as wget and cURL and phantom.js and such; some programming languages have HTTP-based cross-network "pipes" built into the language, including Javascript (XmlHttpRequest) as well as PHP (fopen/file_get_contents/etc) ... which are common languages for beginning-programmers, which work in a command-line environment in the form of WSH and PHP-CLI. Maybe we can explain SORCER in those terms, rather than in terms of federated method invocations, in the top half of the article-overview section, before we get into the literature-specific stuff in the bottom half article-gory-details section? We can even speak of dyn-DNS and torrents for dynamic provisioning, and distributed webserver farms plus CDN-style systems load-balancing, to explain some of the fancier features of SORCER, The question is not how best to describe SORCER's academic heritage, in the world of ideas (that can be done of course), but rather how to metaphorically *explain* the complexity of SORCER in easy-to-digest step-by-step chunks.
  6. "...imagine that a platform, ...instead of local executables... has apps... provisioned on-demand in the network at runtime..." Sure, fair enough. When I type 'sort' at the bash prompt, what I expect to happen is that the local PC will execute the local app of that name. The algorithm implemented by 'sort' might be dynamically parallelized across my 8-thread 4-core CPU, with the Linux kernel's scheduler performing the necessary "time-sharing", and conceivably the 'sort' on my machine might even make use of the GPU and/or FPU for additional horsepower. Eventually, the final answer is sent to stdout of my bash prompt. By contrast, when I type 'exert massively_parallel_gridsort.netlet' at the nsh prompt, what I expect to happen is that the SOS discoverer(?) will look around to find there are N idle compute-nodes available, the SOS provisioner(?) will dynamically launch N fresh new back-end service-providers (each of which implements massively_parallel_gridsort_worker() interface-method), and the SOS federated-filesystem will provide one-Nth of the dataset to each compute-node. After the recursion of the Merge_sort#Parallel_processing algorithm is completed, the final answer is sent to stdout of my original nsh command on my local PC, just as expected. Now, one *could* implement such a thing with ssh-calls, or with wget-calls, or some other bash-scripting trickery. What are the advantages of using SOS, rather than fancy-bash-scripting with network-aware command-line apps? And then, what are the advantages of SORCER compared to various grid-computing solutions? For the historical reseachers amongst our readership, how does SORCER compare to network-transparent distributed-operating-system projects like Amoeba (operating system), where Guido van Rossum of Python fame cut his teeth? Does SORCER support process migration, of live and running workers?
  7. "...a new invocation method, instead of invoking a single program or pipeline of programs locally, invokes a federation of back-end services in the network, for each front-end service...." Which is the FMI. However, I would just call it a multikernel system maybe, or some flavor (which?) of distributed_operating_system#Design_considerations, but definitely not wikipedia's definition of a "network operating system" and probably also not any sort of single system image.
  8. "...all other service platforms provide service collaborations at the back-end (called an applications server) only." What about peer-to-peer systems like Gnutella? What about decentralized virtualized networks like Tor?
  9. "exertion == front-end service" / usermode-program / Java-app / nsh-shell-script ... and according to the JPEG in the exertion-oriented programming article, it can also be called a front-end federation. Are all these phrases correct? Any wrong? Any misguided, or with possibly-misleading connotations? Can a front-end exertion, call *another* front-end-exertion?
  10. Paraphrasing heavily: "...service diagrams (interactive-programming-GUI-representation which becomes a netlet), netlets (textual nsh-scriptfiles in EOL which becomes an exertlet), and exertlets (foo.java textfile and/or foo.class bytecode and/or live-in-the-JVM objects that implement the Exertion interface and interact with the SORCER-OS discovery-n-provider API), are the various forms of exertions which exist.... An exertion is a more generic concept for *any* front-end specification of a back-end federation." Is my assessment correct?
  11. "service provider == singleton back-end service" / server-side service / back-end federation / dynamically-spawned network-service / dynamically-bound network-service. Are all these correct? Any wrong? Any misguided, or with possibly-misleading connotations? How exactly are service-providers implemented? The same way as front-end-exertions, just a different name, and configured as network-visible?
  12. "federation == back-end collaboration of services" / conceptual wrapper around an exertion-defined set of service-providers / list of parallel workers executing the compute-tasks given by a parent exertion / instantiation of the 'class' which a specific exertion defines / just a bunch of web-services accessed via SOS-discovery rather than via static URLs / same thing as a front-end federation only run on hardware which cost more than a run-of-the-mill personal machine. Are all these phrases correct? Any wrong? Any misguided, or with possibly-misleading connotations?
  13. "...(these neologisms) emphasize three types of completely different service semantics in federating computing." Okay... which is a valid goal... but aren't they all just nsh-scripts, calling other nsh-scripts, sometimes across the network, and sometimes not? Because if so, explaining that they are all just nsh-scripts written in EOL (or equivalently that they are all just Java-apps written to implement the Exertion interface-spec) is going to make writing the first half of the wikipedia article much simpler. We can explain the semantic distinctions in the bottom half, so that folks will not be confused when they seek Further Reading.
  14. "...a front-end service is a collaborative service as well but at the front-end as the virtual service (realized at the back-end by its federation)." So what you're saying is that a local exertion, which doesn't actually call any service-providers (aka actual implementations of actual functionality), is basically worthless? I thought that I could create a local exertion... or mayhap a "local service provider"... which was a thin wrapper around some traditional UNIX app like grep or somesuch, specifying that my "grep-wrapper" implements the findstr() method. Later, maybe I would create a local exertion called foo, which would FMI to a back-end service-provider for searching the enterprise knowledge-base, but could also get bound to the local-on-my-PC "grep-wrapper" service-provider. Is it impossible to write a local service-provider, and call it from a local exertion?
  15. "Also, calling a front-end service as a "service script" like UNIX script is confusing due to completely different semantics of the network shell, operating system, and the processor as a collection of dynamic service federations." I'll admit that I'm pretty confused by now.  :-)   This sentence in particular made no sense to me, but maybe after some of my other questions are answered, it will start to make sense.
  16. "I assume this article is about the TTU platform architected, designed, and implemented at the SORCER lab as the extension of FIPER." No, incorrect assumption. This article is about the general topic of "SORCER" which includes SORCER'03 prototype, the SORCER'08 paper aka TTU-SORCER, the AFRL fork of SORCER, the multiple Polish forks of SORCER, the Chinese SORCER, the Russian SORCER (if any info is available), and even SORCER "version zero" also known as FIPER, plus forks of FIPER like Engenious/Dassault's fork, and possibly iSIGHT. Wikipedia should cover the history of the system, the major highlights (as specificially make WP:NOTEWORTHY by their mention in Reliable Sources), the proprietary bits, and so on. If we cannot fit it all in one article of a comfy size, it will be split into subsidiary-articles. For a complex system with a long history, see Internet Explorer which has sub-articles on Trident the core technology, MSIE8, MSIE6, MSIE2, and internal forks like IE5 for Mac as well as partially-third-party forks like AOL Explorer and Sleipnir.
  17. "Thus, please drop any unjustified relationships of the TTU SORCER technology to other organizations" See explanation above. SORCER is an encyclopedia article about the general phenomenon, meant for a general readership, and is not specific to any particular variant, organization, company, author, et cetera. We don't have enough sources to give every variant their own article (whereas with Internet Explorer there are literally *hundreds* of articles because there are tens of thousands of magazines/books/teevee/radio/confpapers/etc which document the various versions in excruciating detail).
  18. "...as the secondary sources regarding how SORCER is used. They spent own money on the projects related directly to they business objectives. When they say 'we develop SORCER' it means that develop tools to make SORCER easier to use with their applications." Sources are not privileged, based on who they are; as long as they are talking about the general phenomenon, they belong in this article, about the general phenomonon. That said, we want to be careful that the wikipedia article is *accurate* about the activities of the different groups, giving credit where credit is due. But because the article is not specifically called SORCER open-source codebase as maintained by the owners of SorcerSoft.org and nobody else plus papers by those owners and nobody else, the article will cover GRC FIPER, Engenious FIPER, Dassault FIPER, TTU SORCER'03, TTU SORCER'08, AFRL SORCER'08, SorcerSoft.org SORCER'10, SorcerSoft.org SORCER'13, China SORCER, Russia SORCER, SorcerSoft.com SORCER'13, and soon probably PTIIJ SORCER'14 (if that becomes a fork rather than a contribution back upstream to SorcerSoft.org or SorcerSoft.com or whatever variant PJIIT uses). Does this make sense? Because there is only one article at the moment, that one article covers all the variants that are WP:NOTEWORTHY according to reliable sources, giving credit where credit is WP:DUE.
  19. "...SORCERsoft.com is not developing the SORCER technology as well, the company is developing tools for interactive exertion-programming and var-oriented modeling. They do what Apple has done with BSD UNIX for Mac OSX." Well, kinda... but Apple used their own trademarks, whereas SorcerSoft.com is using the same trademark as SorcerSoft.org (and ditto for AFRL). See my long set of questions above, asking how many SORCER-or-FIPER-related repos there are, today and historically. When you say that SorcerSoft.com is not developing "the SORCER technology" ... you mean that they are not working on the same repo as everybody else (they have their own open-source repo and their own proprietary internal repo I was led to understand if memory serves). Also, since they are trying to build GUI tools that are above and beyond what ships with the core SORCER technoogy, they are absolutely developing the-generic-idea-of-SORCER-related technology, and belong in this general-purpose article.
  20. "...There is no any research paper on the SORCER technology from other places than the SORCER lab (sorcersoft.org) since that core technology is open..." Emphasis added; so, yes, as far as the core open-source system goes, wikipedia will definitely cover that, to the extent that the Reliable Sources cover it. For instance, since there is not var-oriented modelling in the open-source system, wikipedia needs to say as much. Since exertion-oriented-programming was first published in 2007 while SORCER was at TTU, wikipedia needs to say as much. Since the most-cited paper is the one on FIPER from 2000, wikipedia needs to say as much. We don't give subtopics/variants/whatever any more weight than the WP:RS give them, and we don't give them any less weight, either. We try to fairly summarize the subject, based on what the Reliable Sources say. If this does not make sense, Ahnoneemoos or myself can explain in more detail.
Sorry about the WP:WALLOFTEXT, as usual. SORCER-fka-FIPER is quite complex, but I'm starting to get the gist of it... although I'm still at the point where every question that is answered, leads me to ask two brand new questions. Speaking of which, I'll ask Pawel Rubach and/or Pawel Pacewicz to try and fill me in, since they may know the answers I seek. Danke for all the help. 74.192.84.101 (talk) 00:06, 5 January 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:SORCER/Archive_2&oldid=641177294"