Reads

Obiekt pamięci modelowanie, stół OMM.

Obiekt pamięci modelowanie, stół OMM.

Abstrakcyjny

Ten raport podsumowuje wnioski z Object Modeling pamięci Inkubator grupy. Format pamięci obiekt oparty na XML został wprowadzony, który pozwala na modelowanie zdarzeń lub innych informacji o poszczególnych przedmiotów fizycznych, i który jest przeznaczony do obsługi pamięci masowej tych kłód na tzw "etykiety inteligentne" dołączone do fizycznego artefaktu. Grupa tworzy kilka zaleceń dotyczących przyszłej ewolucji format pamięci obiektu w W3C; te połączenia z adresem pochodzenia modelowanie, osadzanie obiektów wspomnieniami na stronach internetowych, a potencjalne korzyści API pamięci obiektu.

Status tego dokumentu

Ta sekcja opisuje status tego dokumentu w momencie jego publikacji. Inne dokumenty mogą zastąpić ten dokument. Wykaz Raportów Końcowych Inkubator Grupy jest dostępna. Zobacz także indeks raportów technicznych W3C na http://www.w3.org/TR/.

Inkubator Grupy mają jako cel do produkcji prace, które mogą być realizowane na zasadach royalty free, jak określono w W3C Polityki Patentowym. Uczestnicy tej grupy Inkubatora dokonały żadnych wypowiedzi na temat tego, czy będą one oferować licencje zgodnie z wymogami licencyjnymi W3C Polityki Patent na części niniejszego Raportu Grupy Inkubatora, które są następnie włączone w Rekomendacja W3C.

misja Obiektu pamięci Modelowanie Inkubator grupy (OMM XG) Część aktywności inkubatora. przedstawiał się następująco: Aby zdefiniować format pamięci obiektu. co pozwala na modelowanie zdarzeń lub innych informacji o poszczególnych przedmiotów fizycznych, najlepiej w ciągu swojego życia, a tym samym realizuje model pamięci obiektu (OMM).

Format pamięci obiekt powinien być zaprojektowany do obsługi pamięci masowej o tzw "etykiety inteligentne" dołączone do fizycznego artefaktu. Takie etykiety z kodami kreskowymi wahają się, aby RFID do czujnika węzły – zminiaturyzowane systemy wbudowane zdolnymi do wykonania pewne przetwarzanie, gromadzenie informacji sensorycznych i komunikowania się z innymi węzłami. Format pamięci przedmiot realizowany na zasadzie "inteligentne etykiety" Pamięć może stanowić obiekt. które mogą służyć jako kolektor danych dla rzeczywistych danych dotyczących świata fizycznego artefakt. Kojarzenie semantyczne definicje z danymi zapisanymi w formacie pamięci obiektu, może pomóc powiązać Semantic Web z Internetu przedmiotów.

Dziś heterogeniczne standardy są już używane do opisania indywidualne cechy fizyczne artefakt w różnych obszarach zastosowań. Planowany obiekt ma Format pamięci w celu uzupełnienia i objąć takie standardy dedykowane do opisu przedmiotów fizycznych. W celu ułatwienia współdziałania w scenariuszach, składających się z kilku domen aplikacji (np procesy biznesowe obejmujące produkcji i logistyki) oraz scenariusze otwartej pętli (np linii produkcyjnych o bardzo różnych etapach procesu), format pamięci obiekt powinien zapewnić znormalizowane sposób organizowania i dostęp wybrane dane niezależne od dziedziny zastosowania. Ponadto powinien on funkcjonować jako warstwa technologicznie neutralne dla dostarczania treści z przedmiotów fizycznych do zastosowań w procesach biznesowych, począwszy od zarządzania cyklem życia produktu do wspierania konsumentów.

Ogólne wymagania dotyczące formatu pamięci obiektu należą:

  • Niezależność od dziedziny zastosowania;
  • Niezależność od technicznych ograniczeń nałożonych przez inteligentnych technologii etykiet;
  • Otwartość, elastyczność, modułowość i skalowalność

Format pamięci przedmiot adresy organizacji, opis i przekształcanie informacji związanych obiektowego. Stąd stosowanie następujących trzech składników odgrywa ważną rolę:

  • Wzór struktury określa cechy strukturalne pamięci obiektów. Należy zapewnić elastyczne i rozszerzalny podejście takie, że każdy potencjalny właściciel obiektu będzie mógł wzbogacić przedstawienie dodatkowych informacji w dowolnych formatach. Model ten powinien wyraźnie wspierać doczesnych i przyrostowych aspekty informacji akumulacji wzdłuż cyklu życia obiektu i pozwalają na opisujące stan obiektu w różnych punktach w czasie. Ponadto należy umożliwić opisania składników aktywnych, takich jak czujniki, stosowane przez obiekt pozyskiwania informacji z otoczenia. Ponadto, model ten powinien być zaprojektowany w sposób, który ułatwia jej przyjęcie na ograniczone technicznie urządzeń magazynujących dane, takich jak chipy RFID. Ponadto powinien on umożliwić skuteczną wymianę informacji pomiędzy obiektami.
  • Zestaw dobrze zdefiniowane metadane umożliwia powierzchowną charakterystykę obiektu fizycznego bez konieczności korzystania z dodatkowych źródeł informacji. Ten metadanych (słowa kluczowe) powinien być stosowany przez każdego rodzaju pamięci obiektów w celu ułatwienia wymiany informacji w scenariuszach z kilku stron interakcji z obiektem.
  • Format konwersji należy zapewnić określoną ale elastyczny sposób przesyłania formatu pamięci obiektu do reprezentacji dopasowania ograniczenia techniczne różnych rodzajów znaczników RFID w zakresie od czujnika węzłów. Powinno to pozwolić na zdefiniowanie mapowania między reprezentacji XML na bazie formatu pamięci obiektu i dowolnych formatów binarnych z potencjalnie silnych ograniczeń technicznych.

Format pamięci obiekt powinien dodatkowo zapewniać mechanizmy wsparcia: dostęp do danych; Interpretacja danych; i integralności danych rozproszone informacji związanych z przedmiotem.

W celu zbadania tego tematu, co następuje sekwencja prac zostało zaplanowane:

  1. Analiza wymagań dotyczących przechowywania i przetwarzania danych o sprzęcie fizycznym i zewnętrznie w środowisku. Uwagi: Obiekt ten obejmuje przetwarzanie wspomnienia na temat inteligentnej etykiety elementu fizycznego użytkownika.
  2. Definicja opisu strukturalnego wspomnienia obiekt, który pozwala na definiowanie bloków treści i historii zdarzeń dla konkretnego obiektu. Uwagi: Brak uzgodnionych formalne definicje dla struktury pamięci obiektów w chwili obecnej. Tworzenie uzgodnione definicje formalne będzie zadaniem grupy inkubatora. Ponadto, ograniczenia nałożone przez fizyczne aspekty technologii inteligentnych etykiet powinny być brane pod uwagę w celu umożliwienia przeniesienia tych struktur ze scenariuszy internetowych opartych na inteligentnych etykiet.
  3. Definicja budowli, które ułatwiają dostęp do zawartości i opis obiektów przechowywanych w pamięci, takich jak słowa kluczowe i struktur indeksowych. Tutaj, zwłaszcza celem jest określenie tych struktur w sposób, który umożliwia szybki bezpośredni dostęp do danych nawet po transferze (i zagospodarowania) takich struktur arbitralnej inteligentnych etykiet. Uwagi: Ważnym wymogiem jest rejestracja rozkładu produktu w "otwarty świat", Czyli struktury te powinny być gotowe do rozszerzenia.
  4. Definicja opisu, który pozwala do określenia powiązanych zdalnych źródeł informacji, takich jak czujniki przedmiotowemu – źródeł, które podają go do pamięci o zawartości obiektu. Uwagi: Następujące pojęcia związane inteligentnych etykiet, szczególny nacisk zostanie położony na opisie i leczeniu źródeł informacji faktycznie podłączonych do fizycznego artefaktu.
  5. Definicja konstrukcji wsporczych konwersji z przedstawień opartych na XML na inne, bardziej zwartą (na przykład binarnie) formatach odpowiednich dla różnych rodzajów technologii inteligentnych etykiet. Uwagi: Ten konkretny krok będzie wymagało formalnego opis procesu mapowania; podejście powinno być otwarte, a tym samym umożliwić dostawców treści do definiowania własnych schematów mapowania za ich treść.

Dopasowane początkowe oczekiwania wyemitowane w statucie. Wysiłki grupy inkubatora dotyczyły egzemplarze (1), (2) i (3) w trakcie wykonywania jednego roku. Grupa zaczęła badać przedmioty (4) i (5); odpowiednia propozycja, jak radzić sobie z tych tematów – również jako część przyszłej pracy – jest zawarte w niniejszym dokumencie. Podczas wykonywania grupa dostosowane do jego działania zgodnie z kryterium sukcesu wyznaczającą (re) nadające strukturę, które

  1. Opisuje fizyczne artefaktu indywidualne cechy i możliwości techniczne.
  2. Umożliwia reprezentację i organizację poszczególnych historii zdarzeń (a więc ewolucja własności pojedynczego artefaktu).
  3. Obsługuje pobieranie i dostęp zmieniając właścicieli i użytkowników wraz cyklu życia produktu.
  4. Jest gotowy do tłumaczenia zgodnie z (Pamięć) ograniczeń narzuconych przez inteligentnych technologii etykiet.

Omówienie tych kryteriów w odniesieniu do proponowanego format pamięci obiektu, patrz rozdział 3.

OMM XG starał się wprowadzić nowe struktury tylko wtedy, gdy potrzebne do określonego celu modelowania pamięci obiektu. W związku z tym, następujące czynności są uważane za powiązane, ale poza zakresem dla potrzeb tej grupy. Ich odpowiednie wyniki objął tam gdzie to możliwe, w celu ułatwienia wdrożenia nowych elementów tworzonych w ramach modelu pamięci obiektu.

Dokument ten bada i motywuje cech strukturalnych modelu wspomnienia obiektów. Jest ona przeznaczona dla czytelników zainteresowanych w kilku obszarach.

OMM badano W3C związku z kilku powodów. Te dzielić się pomysł, że powinna ona być ewentualnie możliwe do przechowywania obiektów wspomnienia w internecie w celu ułatwienia budowy i przekazywania danych związanych obiektowego:

  • Rejestr zdarzeń może zawierać informacje na temat korzystania z obiektem (na przykład minimalnej lub maksymalnej temperatury), które mogą być oznaczone, jeśli zdarzenie krytyczne jest zarejestrowany. Pamięć obiekt może zawierać kłody okresowych odczytów czujnika temperatury (na przykład), które charakteryzują się środowisko.
  • Rejestr zdarzeń mogła udokumentować odpowiednich procesów w całym cyklu życia obiektu, takie jak data produkcji, kontroli jakości oraz działań konserwacyjnych. Informacja ta jest ważna, gdy wspomnienia obiektów są wykorzystywane w złożonych procesach produkcyjnych.
  • Rejestr zdarzeń mogła udokumentować którym ludzie i / lub urządzenia interakcje z obiektu podczas jego cyklu życia.

Common Event Expression (CEE – http://cee.mitre.org/about.html) jest aktywny projekt standaryzacji z naciskiem na jak wydarzenia komputerowe są opisane, rejestrowane i wymieniane. W przeciwieństwie do innych standardów rejestrowania zdarzeń, które są zainteresowane głównie z logów serwera WWW, takich jak W3C formacie Common Log (http://www.w3.org/Daemon/User/Config/Logging.html) i Rozszerzony format W3C pliku dziennika (http: //www.w3.org/TR/WD-logfile.html) CEE ma na celu poprawę ogólnych procesów kontrolnych oraz zwiększenie interoperacyjności imprezy i formaty zalogować.

CEE zawiera z wielu różnych elementów i będzie oferować różne poziomy zgodności. Specyfikacja zawiera o składni dziennika (CLS), który opisuje jak to wydarzenie i jego dane są reprezentowane. Zbiór możliwych pól zdarzeń i typów wartości z rejestrów zdarzeń są opisane za pomocą słownika i CEE CEE Taksonomia definiuje zbiór znaczników, które mogą być wykorzystane do sklasyfikowania zdarzeń. Wspólnota CEE zapewnia rekomendacje log (CELR), które są ukierunkowane na dostarczanie najlepszych rozwiązań, jakie dane do logowania i jak go bali. Wreszcie w innej części opisu (CLT) opisuje to, co jest obsługa techniczna potrzeby (na przykład do lokalizacji, interfejsy do rejestrowania zdarzeń), aby wspierać transportu półwyrobów.

OMM XG zaleca do czynienia z wydarzeniem zalogowaniu obrębie pamięci obiektu w następujący sposób:

  • Pojedyncza OMM blokowe mogą być wykorzystane do reprezentowania jednego zdarzenia, jak pokazano w sekcji 4.1. Jej metadane mogą być wykorzystane do modelowania zdarzenie. Ograniczenia tego podejścia są dwojakie: Przede wszystkim, jeśli aplikacja tworzy ogromną liczbę zdarzeń, to może "przepełnić" pamięć obiektu i co sprawia, że ​​trudne do obsługi w scenariuszach silne ograniczenia w przechowywaniu i sprzętu stosowanego interakcji. Po drugie, ładowność od takich bloków zdarzeń nie jest uzależnione od formatu, który może stać się problemem, jeśli log musi być ustanowiony w kilku aplikacjach.
  • Alternatywnie, aplikacja może zapisać dziennik zdarzeń w postaci danych jednostki OMM Block. Opcja zdalnego przechowywania danych ładunku jest szczególnie korzystne, jeśli duże dzienniki muszą być reprezentowane. W celu ułatwienia komunikacji dotyczącej jakiś przedmiot między zastosowań OMM XG zaleca polegać na standardowym formacie modelowania zdarzeń, w szczególności CEE.

Norma ta zawiera binarny model danych dla opisujące najważniejsze cechy czujników / urządzeń wykonawczych, jak również różne mechanizmy rejestrowania zdarzeń. Różne rodzaje zdarzeń i zestawień (na przykład wartości maksymalnej, to znaczy) podano. W końcu interfejs (również binarne) do przetwornika jest podane.

Ze względu na jego naciskiem na reprezentacjach binarnych i jego wąskiej dziedziny zastosowania, podejście prawdopodobnie nie jest bezpośrednio stosowane w naszym podejściu. Niemniej jednak, jego Obszerną listę typów zdarzeń i mechanizmów rejestrowania jest interesująca.

Pamięć przedmiot ma na celu umożliwienie poszczególnym stronom przyczynić danych do pamięci (na przykład w celu rejestracji wymianę artefakt między partnerami biznesowymi), ale również w celu zapewnienia wyraźnego rozróżnienia wszystkich tych składek. Jako takie, pochodzenie pamięci obiektów są dwojakie: Po pierwsze, pochodzenie przyczyniły danych ma być przedstawiony. Po drugie w zależności od przypadków użycia, ogólna pamięci może reprezentować pochodzenie artefaktu. Tutaj pochodzenie zawartych danych nie jest ograniczona do konkretnego tematu. OMM opiera się na metadanych w celu wspierania odzyskiwanie danych zawartych. Realizacja odniesienia używa metadanych opartych na Dublin Core Metadata (patrz punkt 2.6) w celu opisania pochodzenia treści w pamięci.

Dlatego, OMM jest związana w pewnym stopniu do działań poświęconych modelowaniu i regionie – takich jak pochodzenie grupy roboczej W3C. który ma na celu powszechnej publikacji i wykorzystywania informacji pochodzenia dokumentów internetowych, danych i zasobów. OMM mogą przyczyniać się do tej działalności. Z kolei ogólny wzór pochodzenie (lub mapowanie) byłby szczególnie przydatny do zastosowań opartych OMM: jest prawdopodobne, że scenariusze z udziałem stron z różnych dziedzin zastosowania spowodowałby wspomnienia obiekt o zawartość następujących różne modele pochodzenia.

W3C wyraził zalecenia dotyczącego Efficient XML Interchange (EXI) format. Określa ona zwartą reprezentację binarną dla dokumentów XML, które mogą być stosowane w celu stworzenia binarny i bardzo zwartą reprezentację OMM. Od przypadków korzystania z OMM, zwartość to jednak nie jedyny wymóg binarnej reprezentacji OMM. Na przykład, Omm powinien obsługiwać rozproszoną procesie produkcji (patrz rozdział 4.1), w którym programowalne sterowniki logiczne (PLC), z ograniczonymi możliwościami przetwarzania są bardzo powszechne. Te nie mogą ewentualnie analizować kompletny OMM, ale wciąż potrzebują dostępu do pewnych informacji z OMM. W celu wsparcia tych urządzeń w istniejących procesach produkcyjnych, powinno być możliwe do określenia dokładnego adresu bajtowego niektórych elementów informacji w OMM.

XML i konsekwencji EXI nie pozwalają na to, ponieważ, na przykład Informacje długość wartości atrybutów nie jest zachowana. OMM przedstawienie binarnego powinien być zatem określony za pomocą innych środków. Specyfikacja naturalny język wraz z realizacją odniesienia użyto SemProM. Takie podejście ma jednak nie łatwo skalować do większych przypadków użycia, a tym samym pogarsza się korzyści z normalizacji. Te same wady przytrzymać przez innych przedstawień, takich jak JSON, które są powszechnie stosowane jako bardziej kompaktowych reprezentacji zamiast XML.

Poza domeną produkcji i logistyki, języki, takie jak ASN.1 zostały wykorzystane do identyfikacji kodowanie binarne dla komunikatów. Dane ASN.1 są jednak trudne do zrozumienia i nie jest dobrze obsługiwany w językach programowania. Niedawno potrzeba zdefiniowania kodowanie binarne zyskał kilka atrakcji w społeczności open source i internetową, gdy Facebook i Google wydało ramy gospodarności i ProtocolBuffer odpowiednio. Obie z nich są zintegrowane w coraz większej liczbie języków programowania, dzięki czemu wdrażanie parserami i generatorów łatwe. Zostały one zaprojektowane w celu osiągnięcia wydajności obok tego, co jest osiągalne z ręcznie wykonane formatów binarnych, jednocześnie zachowując wysoką czytelność i rozciągliwość.

2,6 Dublin Rdzeń ® Inicjatywa metadanych

Wraz ze standardowym modelem danych W3C metadanych, ramowa opisowa Zasobów (RDF), przy czym Dublin Core Społeczność opracowane profile aplikacji prowadzących do stworzenia podstawowego zestawu metadanych rozszerzony o dane konkretnych specjalny domen, które pozwoliło nam korzystać z niektórych metadanych Dublin Core dla naszych celów i rozszerzyć je o dodatkowe informacje, zamiast definiowania kompletny nowy zestaw. Więc użyliśmy atrybutów rdzeń Tytuł, opis, Format, twórca, specjalista, Temat (częściowo) jako fundament naszego zestawu metadanych. Rozszerzyliśmy tych typów podstawowych z dodatkowymi funkcjami, aby wspierać naszych potrzeb i uzupełniają je z pamięci pomocniczej określonych informacji obiektu.

Ta sekcja zawiera podsumowanie propozycję dotyczącą formatu pamięci obiektu w oparciu o XML, który implementuje model pamięci obiektu. Format i wzór miały być niezależne od scenariusza aplikacji; oni zająć kryteria sukcesu OMM XG (por sekcja 1.2) w sposób następujący:

  1. Ogólnym celem Format pamięć nie nakłada szczególnych ograniczeń w opisie cech indywidualnych artefakt fizyczny i możliwości technicznych – OMM XG uwzględnić takie modele, aby być poza zakresem tej działalności (patrz rozdział 1.3). Zatem, aplikacja (s) mogą swobodnie przechowywać szczegółowe opisy obiektów w zawartości bloków pamięci. Ponadto nagłówek pamięci i spis treści dostarczyć wskazówki dotyczące obecności tych danych.
  2. Pamięć jest podzielony na bloki. Z biegiem czasu, nowe bloki mogą być dodawane w celu dodania informacji o obiekcie. Pozwala to na reprezentację i organizację poszczególnych historii zdarzeń i tym samym ewolucję właściwości pojedynczego artefaktu.
  3. Mechanizm blok oparte stara się wyraźnie oddzielne wkłady wnoszone przez zmianę właścicieli artefaktu. W celu zapewnienia dodatkowego wsparcia dla pozyskiwania i dostępu wzdłuż cyklu życia produktu, format pamięci obiektu określa niewielki zestaw słów kluczowych udostępnionych przez każde wystąpienie pamięci obiektu. Wśród innych funkcji, te słowa kluczowe pozwalają na określenie informacji o pochodzeniu danego bloku.
  4. Prototypy wykazały, że stosowanie bloków jest korzystne dla przeliczenia pamięci zgodnie z ograniczeniami (pamięć) Zdolność nałożonych technologii inteligentnych etykiet. Aplikacja może swobodnie wybrać podzbiór bloków z pamięci do przechowywania na etykiecie dołączonej do artefaktu. Format pamięci obiektu obejmuje określenie połączeń pamięci, które mogą być stosowane do łączenia różnych części takiej rozproszonej pamięci.

Proponowana Format pamięci obiekt dzieli pamięć obiektu na kilka bloków. Każdy blok zawiera informacje specyficzne dla fragmentów i zawiera zestaw metadanych w celu ułatwienia wyszukiwania przez Dane zadania sam (patrz Figura 1). Ta lista jest uzupełniana bloków z opcjonalnym spisu treści (TOC, patrz rozdział 3.2) i sekcję nagłówka. Ten nagłówek zawiera wersję OMM, pierwotnego unikalny identyfikator ("podstawowym ID") Dla tego obiektu pamięci oraz opcjonalnie link do dodatkowych źródeł zewnętrznych blokowych.

OMM Header wprowadza nową pamięć obiektów. Określa wersję kodowania pamięci i definiuje podstawowy identyfikator. Ten podstawowy identyfikator jest opcjonalne, ale ustalona dla tej pamięci raz ustawiony. Jest on używany do określenia relacji między pamięcią obiektów i wspomnienia innych, dodatkowych (zewnętrznych), bloków i innych struktur (patrz rozdział 3.4). Jeśli nie ma potrzeby dla takich stosunków, wówczas podstawowy identyfikator jest opcjonalny; w przeciwnym razie jest ona wymagana. Dodatkowe i tymczasowe identyfikatory dla tej pamięci mogą być definiowane w specjalnym IDs Block. Ponadto, dodatkowe bloki mogą być przechowywane poza tym pliku XML i związane z tej pamięci w nagłówku.

Poniższe przykłady przedstawiono nagłówek mM z wersją (1 LT, Omm: versiongt ;. Wymagane), adres URL "http://www.w3.org/2005/Incubator/omm/samples/p1" jako podstawowy ID ( LT, Omm: primaryIDgt ;. Wymagane) oraz adres URL "http://www.w3.org/2005/Incubator/omm/samples/p1/ext" jako źródła innych bloków (OMM LT, Omm: additionalBlocksgt ;. opcjonalnie), które mogą być pobrane poprzez HTTP (GT ==; Typ "omm_http").

Każdy blok pamięci obiekt zawiera informacje o określonym temacie. Wszystkie bloki są na równi, układ bloków nie oznacza dowolnej kolejności. Nie ma regulacji i ograniczenia dostępu zdefiniowane, więc ktoś, że ma dostęp do pliku XML może dodać, zmienić lub usunąć bloki bez żadnych ograniczeń. W związku z tym, wniosek nie może działać na założeniu, że konkretny blok informacje są dostępne w określonym czasie. Aby umożliwić użytkownikom i aplikacji w celu identyfikacji odpowiednich bloków (patrz rysunek 2) zestaw metadanych bloku wskazuje wątek bloku, który jest przechowywany w zawartości bloku.

Figura 2: OMM blok składa metadanych oraz ładunku.

Poniższy przegląd pokazuje atrybuty metadanych w szczegółach:

  • ID
  • Cel: Pamięć unikatowy identyfikator dla tego bloku
  • Typ: String
  • wymagany
  • Konieczność: identyfikator blok jest stosowany do identyfikacji blok w pamięci z zewnętrznej pamięci (blok podstawowy ID + Id) oraz łączący dane TOC bloków.
  • przykładowy kod do uznania nowego bloku o identyfikatorze "block_123":
  • Przestrzeń nazw
    • Cel: namespace deklaruje zawartości oraz jej kodowanie w unikalny sposób. Dobrze zdefiniowane bloki OMM są identyfikowane z ich nazw (patrz rozdział 3.3).
    • Typ: URL
    • Opcjonalnie (wymagane, jeśli nie forma jest podana)
    • Konieczność: Używany zadeklarować strukturę ładowności; umożliwia aplikacji, aby wybrać tylko bloki to jest rzeczywiście w stanie przetworzyć.
    • przykładowy kod do deklarowania URL "http://www.w3.org/2005/Incubator/omm/ns/sample" jako nazw:
    • Format
      • Przeznaczenie: Definiuje format / kodowanie ładunku bloku, typ MIME jest przeznaczony. tekst wewnętrzna równa Dublin Core "Format" (Patrz http://purl.org/dc/elements/1.1/format).
      • Typ: typ MIME jako ciąg
      • atrybuty:
        • Schema (Omm. Schema opcjonalnie): definicję schematu XML dla application / xml typu MIME.
        • Szyfrowanie (Omm: szyfrowanie opcjonalne.): Dodatkowy algorytm szyfrowania stosowany do zabezpieczenia ładunku (np AES256)
        • Opcjonalnie (wymagane, jeśli nie podano nazw)
        • Konieczność: Obsługuje parser podczas przetwarzania pamięci i używane jako zastąpienia brakujących nazw.
        • przykładowy kod pokazujący blok z XML ładowności ("application / xml"), Brak szyfrowania ("Żaden") Oraz dodatkowa definicja schematu XML ("http://www.w3.org/2005/Incubator/omm/schema/sample.xsd"):
        • Twórca
          • Cel: Wskazuje datę utworzenia bloku i tożsamość twórcy. Równa Dublin Core "Twórca" (Patrz http://purl.org/dc/elements/1.1/creator).
          • Typ: pierwiastek strukturalną, zawierający informacje o dacie i podmiot (patrz przykład kodu).
          • wymagany
          • Konieczność: Służy do pozyskiwania drewna, pochodzenia i celów sprawdzających prawnych.
          • przykładowy kod pokazujący informacje utworzenia podmiotu twórcy "195505177" typu "DUNS" i znacznik czasu ("30 stycznia 2011 18:30"):
          • Współpracownik
            • Cel: Wskazuje datę wkładu grupowego i tożsamości wpłacającego. Równa Dublin Core "Współpracownik" (Patrz http://purl.org/dc/elements/1.1/contributor).
            • Typ: pierwiastek strukturalną, zawierający informacje o dacie i podmiot (patrz przykład kodu).
            • Opcjonalny
            • Konieczność: Służy do pozyskiwania drewna, pochodzenia i celów sprawdzających prawnych.
            • przykładowy kod pokazujący informacje wpis podmiotu kontrybutora "user@example.com" typu "e-mail" i znacznik czasu ("31 stycznia 2011 08:12"):
            • Tytuł
              • Przeznaczenie: zapewnia wyraźny tekst, wielojęzyczne i czytelny dla człowieka krótkie (lt; 255 znaków) tytuł zawartości bloku. Równa Dublin Core "Tytuł" (Patrz http://purl.org/dc/elements/1.1/title).
              • Typ: String.
              • atrybuty:
                • Lang (XML. Lang wymagane): wskazujący język tytułowego tekstu (ISO 639-1).
                • wymagany
                • Konieczność: Używane do przedstawienia czytelnego tekstu ludzkiego do użytkowników końcowych.
                • przykładowy kod pokazujący dwa tytuły w języku angielskim i niemieckim:
                • Opis
                  • Przeznaczenie: zapewnia wyraźny tekst, wielojęzyczne i opis czytelny dla człowieka (długa wersja tytułu) za zawartość bloku. Równa Dublin Core "Opis" (Patrz http://purl.org/dc/elements/1.1/description).
                  • Typ: String.
                  • atrybuty:
                    • Lang (XML. Lang wymagane): wskazujący język opisu tekstu (ISO 639-1).
                    • Opcjonalny
                    • Konieczność: Używane do przedstawienia czytelnego tekstu ludzkiego do użytkowników końcowych.
                    • przykładowy kod pokazujący dwa opisy w języku angielskim i niemieckim:
                    • Rodzaj
                      • Równa Dublin Core "Rodzaj" (Patrz http://purl.org/dc/elements/1.1/type).
                      • Typ: String (Dublin Core "Rodzaj")
                      • Opcjonalny
                      • Konieczność: Dodatkowe informacje o Dublin Core systemów świadomych.
                      • przykładowy kod pokazujący typ bloku rdzenia Dublin "Zbiór danych":
                      • Przedmiot
                        • Cel: Darmowe tagi tekstowe i ontologia koncepcje (RDF lub OWL) do opisania ładunek bloku. Zagnieżdżanie znaczników umożliwia tworzenie hierarchii znaczników. Zagnieżdżone znaczniki mogą być przetwarzane tylko jako domyślne znaczniki ale również nosić Rodzic / dziecko semantycznej (patrz przykład dla tagu "E12 jest subconcept DIN jest subconcept norm"). Przedmioty tekstowe są oparte na Dublin Core "Przedmiot" (Patrz http://purl.org/dc/elements/1.1/subject).
                        • Typ: strukturalny element kodujący ontologię, hierarchicznych znaczników tekstowych (patrz przykład kod).
                        • Opcjonalny
                        • Konieczność: pozwala na swobodne tagging bloków.
                        • przykładowy kod pokazujący tag przedmiot ontologii opartych ("http://o.org/def.owl#ManufacturerData"), Oraz dwa znaczniki tekstowe oparte. Pierwszy z nich jako prosty tekst ("Składniki") A drugi jako koncepcji tekstu hierarchiczny ("norms.din.e12")
                        • Połączyć
                          • Cel: Jeśli ładunek blok nie jest wbudowany bezpośrednio w strukturę XML, a następnie link może być dostarczone do wskazania związku z out-pozyskiwane bloku ładowności w dowolnym miejscu.
                          • Typ: Link do zewnętrznego zasobu (zazwyczaj URL).
                          • atrybuty:
                            • Typ (Omm: typ wymagane.) Określający rodzaj łącza (np URL)
                            • Mieszania (Omm. Mieszania opcjonalnie) SHA-256 wartości hash połączonych danych do celów integralności danych w celu zapewnienia, że ​​dane zostały niezmodyfikowanej.
                            • Opcjonalnie (wymagane, jeśli nie "ładowność" jest podawany)
                            • Konieczność: Umożliwia outsourcing dużych danych użytkowych do zasobów zewnętrznych.
                            • przykładowy kod pokazujący link do zewnętrznego źródła ("http://www.w3.org/2005/Incubator/omm/samples/p1/ext.xml") Typu "URL" i dodatkowa wartość hash ("d32b568cd1b96d459e7291ebf4b25d007f275c9f13149beeb782fac0716613f8"):
                            • ładowność

                              • Cel: Umożliwia przechowywanie ładunku inline jako alternatywa dla połączonej strukturze.
                              • Typ: CDATA (zwykły tekst lub struktury XML).
                              • atrybuty:
                              • Kodowanie (Omm: kodowanie opcjonalnie). Wskazuje kodowanie binarne używane do tego ładunku (np "base64")
                            • Opcjonalnie (wymagane, jeśli nie "Połączyć" jest podawany)
                            • Konieczność: Jazda na ładowność, bez konieczności jakiejkolwiek pamięci zewnętrznej.
                            • przykładowy kod (1) pokazuje prosty tekst jako ładowności:
                            • przykładowy kod (2) pokazując base64 zakodowany tekst jako ładowności:
                            • przykładowy kod (3) pokazuje zastrzeżoną osadzoną strukturę XML jako ładowności:
                            • Poniższa ramka pokazuje kompletną próbkę dla OMM bloku z kilku metadanych linku i informacji bloku danych (tylko dla tego przykładu, ponieważ łącza i ładowności zwykle nie pojawiają się w tym samym bloku):

                              Figura 3: OMM Tabela treści zawiera podzestaw metadanych każdym bloku.

                              Wpis ToC polega na podzbiorze atrybutów metadanych wykonania mM bloku (patrz figura 3). Wymagane jest, aby dzielić się odwołuje atrybuty identyfikacyjnych OMM bloku ("ID" i albo "Przestrzeń nazw", "Format" lub oba z nich). Za pomocą tego samego identyfikatora, w bloku i spisu treści TOC wejście połączone z odpowiednim bloku. Ponadto atrybuty "Twórca" i "Tytuł" Zaleca się na wejściu ToC, jeśli są one określone w odpowiednim bloku. Wszystkie pozostałe atrybuty są opcjonalne, ale można ustawić w spisie treści, w celu zapewnienia dodatkowego wsparcia dla poszukiwania pamięć obiektów.

                              Poniższy przykładowy kod XML przedstawia możliwe stół wejścia treści dla OMM bloku wymienione w punkcie 3.2:

                              Format pamięci przedmiot obejmuje niewielki zestaw szablonów dotyczących ładowność OM Block. Jeśli blok jest odniesienie do takiego szablonu, jest on oznaczał "znormalizowany blok", Te bloki albo mają szczególną funkcję dotyczącą pamięci obiektu (a zatem realizować aspekt OMM) lub adres podstawowych aplikacji z pamięci obiektów. Ogólnie rzecz biorąc, standaryzowane bloki mają na celu ułatwienie komunikacji pomiędzy różnymi aplikacjami działającymi w tej samej pamięci obiektu.

                              Poniższy przykład ilustruje, jak dwa identyfikatory są przypisane do obiektu, jednego typu "URL" ("http://www.w3.org/2005/Incubator/omm/samples/p2"), A jeden z typów "e-mail" ("p2@producer.org").

                              Warto zauważyć, że implementacje tych przykładów – które zostały zbadane w działaniach związanych z Sekcji 1.1 – liczyć na różnego rodzaju urządzeniach interakcji i architektur pamięci masowej. Dopasowane różnorodność sytuacji, które mogą wymagać dostępu do OMM, mogą nawet zmienić w jednej aplikacji. Na przykład, scenariusz opisany w rozdziale 4.5 mogą wymagać hybrydowy dostęp za pośrednictwem urządzenia mobilnego za pomocą technik, jak również za pomocą aplikacji sterowania Desktop dla przełożonego, oba połączone za pomocą hybrydowy infrastruktura udziałem OMM przechowywanie na artefaktem (poprzez inteligentne etykiety) i serwer WWW. Aspekty te są pomijane w kontekście tego dokumentu ze względu na skupienie się na aspekcie modelowania OMM, ale może wymagać dalszej uwagi.

                              Poniższy przykład kodu XML wprowadza zawartość pamięć (OMM nagłówka i OMM spisu treści i link do bloków z tej pamięci) do przypadków zastosowań opisanych poniżej:

                              • Sygnatury dotyczące konkretnych zdarzeń produkcyjnych
                              • Routing startu / mety routingu
                              • Rozpoczęcie produkcji / wykończenie produkcja
                            • Informacje o historii procesu
                              • Routing udany skończony
                              • Routing zakończył z błędami
                              • Kontrola jakości sukces
                              • niespodziewane wydarzenia
                              • Informacje o środowisku proces
                                • Używane narzędzia
                                • Zaangażowani pracownicy i ich umiejętności
                                • Zużycie energii
                                • W różnych sytuacjach (na przykład detalicznych, przedsiębiorstw społecznych, kolektorów) jest często postrzegane jako pożądane posiadanie informacji na temat pochodzenia pochodzenia obiektu lub poprzednich interakcji z obiektem. Wiedza o historii obiektu może mieć wpływ na zachowanie konsumentów i dodać wartość do obiektu. Przykładem tego są dodawane informacje na temat producenta produktu, takie jak w rzetelnego sklepu towarowego, informacje o poprzednich właścicieli obiektu w sytuacjach, które dotyczą towarów używanych i ogólnie interakcji ludowej z produktem ponad trakcie jego cyklu życia , Informacja ta może obejmować różne pochodzenie nośników i może być otwarty zakończył się w jej strukturze.

                                  Rysunek 4: Tales of Things zatrudnia wspomnienia obiektów w celu wspierania ludzi w komunikacie o obiektach.

                                  OMM chce wspierać korzystanie z wielu identyfikatorów i klasyfikacji. OMM oferuje standardową identyfikatory bloku. który ułatwia przechowywanie identyfikatorów i klasyfikacji, w ramach bloku danych bloku, elementy XML.

                                  Przyszłe scenariusze przemysłowej i automatyki obejmie zdecentralizowanych procesów produkcyjnych. Na przykład, podwykonawcy będą wybierane w locie. Aby wesprzeć tę nową elastyczność pożądane jest, aby zebrać wszystkie informacje o produktach specyficznych związanych z produkcją i przechowywać go na części produktów jako część pamięci obiektu.

                                  OMM nadaje się do opisania pojedyncze produkcje kroki i zadania manipulacji, które muszą być wykonywane na indywidualne produktu. Tylko takie podejście do zarządzania wiedzą produkt skoncentrowany, w których produkty komunikować działania manipulacyjne one require ("Wypełnij 3 tabletki typu A i blisko kosza z kapelusza") Lub strategie dyspozytorskie ("Wolę krytycznych czas pracy") Do systemów produkcji, umożliwia efektywne kształtowanie wytrzymałe i elastyczne zdecentralizowanych procesów produkcyjnych.

                                  Najprostszą formą decentralizacji procesu produkcji mogą być realizowane z pamięci obiektu, który posiada tylko konkretne informacje o produkcie statyczne (na przykład identyfikator produktu, kolor produktu, znacznik czasu produkcji, jakości produktu). Na każdym etapie produkcji, informacja jest odczytywany z pamięci obiektu i według czynności manipulacyjnych i manipulacyjnych operacje są uzyskiwane w kontroli procesu, a następnie wykonywane na produkcie. Dlatego też, informacje o produkcie i w pamięci dla obiektu, może być uznany za "bierny" a algorytmy sterowania i obsługi są realizowane w kontroli procesu (każdego modułu produkcji).

                                  Ta sprawa używać adresów zdecentralizowanych systemów do produkcji masowej, co pomaga utrzymać wysoki stopień automatyzacji w procesie produkcyjnym. Różnice między poszczególnymi produktami przechowywanymi w OMM jest ograniczona do tego, co zautomatyzowana linia produkcyjna może osiągnąć.

                                  W scenariuszach produkcji części składowe są często składane w celu utworzenia obiektu wyższej cenie. W przypadku obiektów wysokiej klasy, takich jak motoryzacja, turbin lub tomografów komputerowych uzasadnione jest założenie, że nawet elementy są na tyle cenne, aby mieć własną pamięć obiektów. Przykładem może być skrzynia biegów samochodu lub sekcji niskiego ciśnienia turbiny.

                                  Chociaż nowy zmontowany przedmiot dostanie własną pamięć obiektu, informacje o zgromadzonych komponentów musi pozostać dostępne i zmienna. W przypadku rozsądnego postępowania powinno być możliwe zbudowanie struktury danych, która odzwierciedla przedmiotów montażu. Jeśli części produktów o dużej wartości nie, te części są naprawiane lub wymieniane. Musi zatem istnieć możliwość, aby zmienić strukturę odzwierciedlającą obiekty montażu. Części mogą być dodane lub usunięte, połączeń pomiędzy elementami mogą być zmieniane. Jeżeli część opuszcza obiekt (zdemontowane) Pamięć obiektu powinien odzwierciedlać jego pełny cykl w tym jego życia jako części obiektu. To znaczy. część należy przypomnieć, gdzie to było. Jako odpowiednik cały obiekt powinien również mieć możliwość zalogowania się z informacjami na temat swoich zdemontowanych części. (Np Samochodami powinny "wiedzieć" że silnik został zastąpiony dwa razy. Ponowne zainstalowany silnik powinien wiedzieć, jeśli został wcześniej zainstalowany w innym samochodzie).

                                  Rysunek 5: Pamięć przedmiot służy do udokumentowania historii zespołu złożonego obiektu.

                                  Poniższy przykład pokazuje XML OMM blok, który opisuje dwa linki do innych wspomnień obiektów. lt; Omm: namespacegt; identyfikuje ten blok jako struktura bloku. Dwa odniesienia w polu danych są identyfikatory z atrybutu relacji (dodatkowa"hasPart"), Co pokazuje, że obecny obiekt posiada jedną część dodanej ("http://www.example.com/omm/samples/part1") A inna część była, ale nie jest już częścią ("http://www.example.com/omm/samples/part2"). Te części z kolei będzie miało bloku strukturę z relacją odwrotną ("jest częścią"), Co nie jest widoczne w tym przykładzie (ponieważ jest elementem innej pamięci obiektów).

                                  W scenariuszach przemysłowej i automatyki, pożądane jest, aby mieć możliwość dodawania informacji do obiektu wspomnienia, które powinny być dostępne do odczytu publicznej ponieważ jest przeznaczona wyłącznie do jakiejś specjalnej grupy użytkowników. Na przykład, użytkownik może chcieć pamięci obiektu, aby dodać informacje o poufnych procesów produkcyjnych, dane licencyjne oparte lub informacji przeznaczonych do dwustronnej komunikacji.

                                  Poniższy przykład pokazuje XML blokiem z AES256 zaszyfrowane dane binarne zakodowane jako tekst Base64. Połączenie danych przechowywanych w lt; Omm: namespacegt; i lt; Omm: creatorgt; pozwala użytkownikom stwierdzić, czy są one w stanie odszyfrować ten blok czy nie (na przykład nazw "encSample" i twórca "user@example.com" oznacza odpowiedni klucz AES).

                                  OMM XG stwierdza, że ​​jednolity model zbiorów informacyjnych dotyczących artefakty mogą być osiągnięte, i proponuje strukturę takiego modelu pamięci obiektu. Przypadki użycia tego modelu są pokazane na podstawie realizacji XML podstawie tego modelu, format pamięci obiektów. Jeśli chodzi o przyszły kierunek tego dzieła, grupa formułuje następujące zalecenia:

                                  1. Zalecenie ("Model – standaryzowane bloki"): Normalizacja bloków pamięci dla poszczególnych zastosowań (patrz punkt 3.4) może wymagać dalszej dyskusji. Z jednej strony, dodatkowe bloki (na przykład znormalizowane dla poszczególnych domen lub etapach cyklu życia produktu) może być wprowadzona w celu ułatwienia komunikacji między uczestnikami procesu. Z drugiej strony, bardziej skomplikowanym technicznie mogłoby zwiększyć wysiłki niezbędne do zintegrowania modelu pamięci obiektu do istniejących systemów. Dlatego OMM XG zaleca zbadanie na podstawie wniosków OMM, czy i jakie bloki powinny być unormowane.
                                  2. Zalecenie ("model – pochodzenie") Jak wspomniano w punkcie 2.4. Postęp w zakresie modelowania pochodzenia może sugerować dostosowania aspektów proweniencyjnych w modelu pamięci obiektu i obiektu formatu pamięci. OMM XG założona kontakt o pochodzeniu grupy roboczej W3C i zaleca, aby zbadać ten temat we współpracy z tą grupą.
                                  3. Zalecenie ("format"): Format pamięci obiektu stosowane w kontekście tego dokumentu opiera się na określonego schematu XML. Jednak inne formaty mogą wdrożyć model pamięci obiektu, jak również. Na przykład, jego podobna struktura i leczenie metadanych może kwalifikować formatu Atom Syndication jako narzędzie do wyrażania model pamięci obiektu. W celu zilustrowania możliwości takich alternatywnych definicji, OMM XG przygotowane przykłady alternatywnych formatów pamięci obiektu ze szczególnym naciskiem na osadzanie pamięć obiektów na stronach internetowych, na przykład na podstawie RDFa. lub HTML5 i Mikrodane.
                                  4. Zalecenie ("Format binarny"): OMM XG zaleca się poświęcić uwagę na kwestie otwarte zgodnie z kolejnością prac określonym w punkcie 1.2. Te podkreślają rolę środowiska sprzętu i oprogramowania, gdzie model pamięci obiektu będzie wdrożony. Jak to opisano w rozdziale 2.5. Pojemność i etapy produkcji ograniczenia urządzeń znajdujących się w takim środowisku sugerują bardzo wydajny format pamięci obiektu, na przykład na podstawie reprezentacji binarnej. W celu zbadania tego tematu, OMM XG przeprowadzono pierwsze eksperymenty dotyczące OMM formacie binarnym.
                                  5. Zalecenie ("berło"): Niektóre przypadki użycia sugerują, że format pamięci obiektu można napotkać na urządzeniach, a także struktur sieciowych i interakcji hybrydowego obejmujących zarówno aspekty mogą wystąpić (patrz np punkt 4.5). Dlatego grupa zaleca, aby dodać dodatkowy cel Kartę – specyfikację danego modelu API pamięci obiektu, który wspiera i ujednolica interakcji z urządzeń posiadających pamięć obiektów. W pierwszym etapie, grupa założona kontakt z W3C Working Group Device API w celu omówienia tego celu.

                                  W wyniku tych uwag OMM XG zaleca, aby kontynuować dochodzenie tematykę modelowania pamięci obiektu w W3C – w ramach działań afinicznych w tematach o których mowa w pkt 1.4 lub jako przedmiot nowej działalności.

                                  Chcielibyśmy podziękować Jörg Neidig, Thorbjørn Hansen Markus Miche Boris Brandherm, Jörg Baus i Massimo Romanelli za ich radą i wsparciem.

                                  RELATED POSTS

                                  • Mangostan Sok brzoskwiniowy aromatyzowane napoje, sok brzoskwiniowy.

                                    7up.com canadadry.ca canadadry.com canadadrymotts.ca canadasnationalcocktail.ca clamato.com crushcanada.ca crushsoda.com dpsgaccounts.com dpsgannualreport.com dpsgproductfacts.com…

                                  • małe karaluchy

                                    Organiczne, naturalne, nietoksyczne Roach sterowania Karaluchy lub karaluchy są jednymi z najbardziej znienawidzonych szkodniki wtargnąć do domu, a te sprężyste małe zwierzęta mogą być nie…

                                  • Owce 101 co jeść owce, kozy co jeść i pić.

                                    Co jest na obiad? Trawa, koniczyna i forbs Głównie owce jedzą trawę, koniczyna, forbs i inne rośliny łąkowe. Są one przede wszystkim miłości forbs. W rzeczywistości, to zwykle ich pierwszy…

                                  • Nowotwory rdzenia kręgowego, złośliwy guz.

                                    PODSTAWOWE nowotwory rdzenia: Ogólne: guzy kręgosłupa zawierać 0,04% wszystkich nowotworów, a około 10% wszystkich nowotworów kostnych. Wiek prezentacji jest bardzo predykcyjna łagodny kontra…

                                  • Rośliny od A do Z listy roślinom do listy oo.

                                    Opis zawartości, tworzenia i wykorzystania Lista roślin następuje. Lista roślin nie jest doskonały i reprezentuje w toku. Naszym celem było stworzenie „best effort” listę, aby wykazać postępy i…

                                  • Podnoszenie Memories Ostatecznym …

                                    Dziś rano będę wywiad na kilka audycji radiowych w całej Kanadzie o idei Toyless Bożego Narodzenia, więc pomyślałem, że podzielę listę na blogu non-zabawkami Pomysły na prezenty, które mogą…

                                  Comments are closed.