Обсуждение

> что можно положить в основу такого стандарта? > для подписок хорошо изучить опыт ATOM и RSS http://activitystrea.ms/

А вы понимаете, что это абсолютно другого сорта acivity? Речь идёт просто о согласовании способа вебсайтов докладывать о том, что кто на них поменял (сделал постинг, оставил коммент, выложил картинку, закачал файл и т.д.). Но использование JSON интересно, это в русле http://ontolog.cim3.net/forum/ontolog-forum/2011-12/msg00059.html

Activity Streams - это рамочный, расширяемый стандарт. Сейчас в нем описана типичная пользовательская активность в вебе, соцсетях. Но туда можно добавить свои target, verb, object и даже autor (сейчас есть только person). На его основе GitHub, например, сделал свои потоки: https://github.com/timeline Есть open/close issue, create branch и т.п. Аналогично поступил StackOverflow. См. стр 112 и 116: http://www.slideshare.net/factoryjoe/activity-streams-socialism-the-future-of-open-source Хорошее введение от автора: http://www.slideshare.net/factoryjoe/activitystreams-is-it-getting-streamy-in-here Интересно, что в основу целая теория деятельности положена.

Там не теория деятельности, а обрывки животных переживаний на тему этой теории. Много бла-бла-бла, а в итоге просто log абстрактной системы в терминах "что кто когда сделал с чем". Этого, конечно, вполне достаточно для целей авторов стандарта, но меня интересуют и модальности ("собирается сделать/сделал/мог бы сделать"), и работа с фактами жизни (онтологией) а не синтаксическими структурами (документами -- объектами сайтов). Так что я останусь при своём мнении: речь идет не об описании активности в терминах приложений социального веба, а об описании дел, которые делают люди в реальном мире.

Даже точнее можно сказать: об описании производства дел, которые делают люди, позиционеры в мирах (натуральном, виртуальном, действительном). Главное здесь понятие дела, которое производится, так как производятся работы этого дела. Но при этом систему производства дел не надо путать (надо различать) с системой документооборота, как многие делают.

Да, именно: этот "стандарт стрима активностей" -- стандарт именно "документооборота" как такового, манипуляций с сущностями вебсайтов. А меня интересует стандарт, исходящий из domain driven design -- стандарт стрима именно жизненных активностей (дел). Это совсем другое, с этим нужно разбираться отдельно -- чем мы, собственно, сейчас и заняты.

Когда я на работе говорил, что система производства дел, этоне система документооборота и не система транзакционная, то мне сделали круглые глаза и спросили: а что такое дело? Да, надо разрабатывать и вводить такое понятие дела, чтобы оно не отождествлялось ни с бизнес-операциями, ни с обработкой документов. У вас такое понятие есть? Надо же выработать еще особый взгляд (концепцию) на компанию, чтобы сказать, что эта организованность предназначена производить дела. И это главное, а какие при этом б-транзакции она должна выполнять и какие будет плодить документы, - это вторично, это подчиненные системы у нее. Могу предложить свое понятие дела. Дело - это выполнение обязательства. Тогда компания - это такая машина, которая занимается выполнением обязательств. И любая компания больше ничем не занимается. А обязательства без требований не существует, это две стороны одной медали. И тут мы плавно входим в инженерию требований (только понятие требований тоже надо правильно построить). А это означает, что любую компанию можно вывернуть по содержанию наизнанку, поработать с этим содержанием (например, установить туда информационные системы, где главной будет система производства дел) и свернуть обратно, изменив, конечно форму этого нового содержания компании. Но, когда это еще будет...

Угу, ваш подход называется сommunication based и очень похож на DEMO. Критику можно почитать, например, тут: http://www.cordys.com/ufc/file2/cordyscms_sites/download/731375d512f6789e8dd8a2775d26c123/pu/cor0027_modeling_rfi_white_paper_lr_v1.pdf

Возможно и так. А каков ваш? Покажите его на примере понятия дела. Что это такое для вас? И соотвественно, что такое дело в всязи с вашим понятием компании?

Я не думаю в терминах, я думаю в понятиях (которые имён не имеют). Поэтому я не могу понять, про какое "дело" вы меня спрашиваете. Кроме того, у меня нет пока собственной онтологии для компании, есть только намётки, как эту онтологию сделать из целого ряда имеющихся в работе (включая ту же DEMO, кстати -- ведь с сервис-ориентированностью тоже нужно работать!). Вот прямо сейчас мы мэппим ISO 24744 в ISO 15926. Там тоже есть task. Будет ли этот task "делом", или "задачей", отмэппится ли он к issue или чему ещё из других стандартов -- мы еще поглядим. Но работа потихоньку идёт, результаты будут опубликованы.

Где вы у меня увидели термины? Термин, это же определение понятия, сформированное для нужд определенной науки. Вы можете вычленить определенную науку у меня? Страннно, что у вас понятия имен не имеют.По моему схватывание какого-то явления в понятии через именование этого, при этом, имя на первых порах може быть приписано как понятию, та к и явлению, - это обычное дело. Для первоначального схватывания так и делают. Но , это ваши проблемы, это в сторону. "нет пока собственной онтологии для компании", - вы верно указывали, что дело - это важно, это то, что не должно сводиться к другим понятиям онтологии деятельности компании, напритмер. Я об этом вам тоже раньше как то писал, обращая ваше внимание, что надо бы разделить в онтологии например, понятие дела и понятие задачи. Можете это найти, если не помните. Не отождетвляйте дело и задачу при меппинге, это будет ошибкой.

Термин -- это как раз "слово", обозначающее понятие. Что там с чем различать -- это разберемся, когда зафиксируем онтологию, дадим уникальные идентификаторы понятиям.

Вы ошибаетесь. Термин - это научное определение некоего понятия. Например, философ строит понятие. А ученые в каждой их своих наук дают термины к этому понятию. Возьмите, например, понятие процесса и вы увидите много разных терминов в разных науках.

Даже Википедия знает, что термины -- это слова, labels для концептов (http://en.wikipedia.org/wiki/Terminology). Я уж молчу про терминологические стандарты. А онтологический ISO 15926 вообще для концептов различает ID, label и name. Вы ваши определения откуда-то из вашей головы достаёте, или из книжек неясного происхождения -- а я обычно стандартами для этой цели пользуюсь (и еще и замечаю разницу между разными стандартами). Стандарты обычно коллективно обсуждаются, поэтому прописываемая в них онтология обычно разделаяемая хотя бы небольшим числом людей, а не просто свежепридуманная одиночками-оригиналами.

Я не знаю откуда вы берете, а я беру из своей практики и из жизнедеятельности, а не "из вашей головы достаёте". Когда в моих проектах собирается много народу, одни с завода, другие приехали из торговой организации, третьи приехали консультанты и пр, то в разговоре всегда наступает такой момент, когда "самый умный" говорит: "давайте договоримся о терминах". Так как я работаю в области экономики, то обычно термины берутся близкими к экономической науке, а остальные, - торгаши, бухгалтерия, производственники и пр, принимают терминологию экономистов. Но так бывает не всегда, но это уже тонкости, о которых вы видимо не знаете, так как "а я обычно стандартами для этой цели пользуюсь". Туда вам и дорога, если у вас главное стандарты. Хотя, вот вам и из Википедии вырезка. И скажите, что это не похоже на мое понимание термина. "Терминология (от термин и... логия), область лексики, совокупность терминов определённой отрасли науки, техники, производства, области искусства, общественной деятельности, связанная с соответствующей системой понятий. Формирование Т. обусловлено общественным и научно-техническим развитием, т. к. всякое новое понятие в специальной сфере должно обозначаться термином. Терминологическая система обязана соответствовать уровню современного развития данной отрасли науки и техники, области человеческой деятельности; она исторически изменчива, имеет разные источники при формировании."

Как пишется в учебниках по ISO 15926, если вы договариваетесь в рамках одного предприятия, то можете мэппиться хоть к Клингону в качестве нейтрального ко всем языка. А вот ежели у вас реально отраслевая ситуация, то Клингон уже не подходит, и нужны другие решения. В любом случае, вы можете опираться на словарь вашего проекта (договорку под руководством встретившегося у вас "самого умного"), а можете опираться на договорку предприятия, а можете опираться на договорку уровнем выше предприятия (где "самых умных" уже огромное количество, включая уже померших и оставивших после себя классические определения из давно написанных книжек). Я работаю вот в таких ужасных условиях, обычно на уровне отраслевых проектов, выходящих часто и в международные проекты -- так что договорки чисто в команде проекта и "предложения из своей практики и жизнедеятельности" меня обычно спасти не могут. Всё вами написанное не противоречит тому, что терминология -- это система слов, привязанных как-то к понятиям. А меня пока интересуют сами понятия, а не какими словами их обозначают. Выбор терминологии важен, но после того как договорились о самих понятиях. Современные онтологии позволяют приклеить к понятиям разные термины, из разных дисциплин, из разных школ.

Последний ваш пост "в дугу". И так разделили термин и понятие. И термин нам дан как слово, и понятие нам дано как слово. Вот это тоже вами понимается? Я как и вы тоже работаю в такой же ситуации. Это отрасль по производству труб. Компания международная, имеет заводы а Росиии, Молдавии, Сша и пр. Продает всем крупнякам из добычи и трубопроводным проектам.Поэтому, вопрос о том как строятся понятия необходимые для отрасли и сколько их должно быть в онтологии для инженерной деятельности этой отрасли (а там не только инженерия имеет место, как вы понимаете, например, управление тоже есть)он стоит. Но пока решается через консенсус. Кстати, ПГ так и говорит, что сегодня понятия строятся через консенсус. Историю физики не надо рассказывать? Я с этим не совсем согласен, но это мои трудности. А вы как отвечаете на эти вопросы? И что говорят ваши стандарты, регулирующие онтологическую работу?

Понятие не дано как слово. Понятие дано как UID, связанный отношениями (реифицированными, тоже имеющими UID) с другими понятиями, имеющими другие UID. А вот слова связаны уже с UID -- все эти labels, names и даже definitions. Терминология -- это про слова, не про понятия.

Я уж подумал, что вы поняли, а вы опять за свое. Понятие нам дано как слово. Слово "стол" может трактоваться и как понятие, и как термин, и как определение. В этом же сила слова. А, если мы еще учтем, что слово - это еще и знак, то много еще чего за словом можно увидеть, даже вещь, или действие. Если вы за словом не видите понятия, то это ваши проблемы. Значит таков у вас язык.

Я за словом вижу много понятий. Омонимия, вот в чём беда. То, что за словом можно видеть и понятия тоже, я понимаю. Но обольщаться, что двое видят одно и то же понятие, я бы не стал. В случае UID проблема становится легче, в современных системах поэтому слова и понятия хранятся и обрабатываются отдельно. Хотя да, "ассоциации по созвучию" тоже бывают. И лингвистические обработчики (включая используемые в IBM Watson средства) вполне могут учитывать "игру слов". Но это другая история.