-
Notifications
You must be signed in to change notification settings - Fork 4
Terminology for Layers
This wiki page (in markdown) tries to capture the results of the first breakout.
Michael McCool, Dan Brickley, Milan M, Kerry Lynn. Juan Carlos Zuniga, Carsten Bormann
Meeting 4-5 today (Sunday, July 16), immediately after breakout session, to make notes and fill out outline.
Proposed terms and definitions to go here.
- Template
- Definition
An unorganized list of topics and ideas mentioned, to use as input.
- Need to consider audience, users, and use cases
- Already a set of tools and stacks in wide use; imperfect, but useful
- This is not the place for a comprehensive survey, but some example stacks would be useful.
- JSON-LD/JSON-Schema/JSON/CBOR
- RDFa/XSL/XML/EXI
- This is not the place for a comprehensive survey, but some example stacks would be useful.
- May be multiple layers even within structural layer
- One close to the serialization, then a more abstract model closer to the application
- Don't want to overcontrain structural model by serialization (syntactic model)
- Structural interop is a prerequisite for semantic interop.
- Reasons for layering:
- separation of concerns
- modularity
- reuse
- loose coupling
- May be multiple sources of semantics: device, link, third parties (multiple, official and unofficial)
- Instance and type identity useful to search for metadata (see also metadata types, lifecycle...)
- "It's only hypermedia if data and metadata are combined"
- Third-party semantics: Manufacturer, ingergrator, user
- Duplicated labor, consistency, integration issues
- What are economic incentives for generating metadata
- May be "pre-shared" semantics that may be implicit in "internal" ecosystem use
- Pre-shared metadata will have to be made explicit in some contexts eg during translation
- Translation
- Compare point-to-point O(n^2) vs intermediate O(n) approaches (and hybrids)
- Use of intermediary as analysis tool to get (generate, find, or specify/request) a point-to-point translator
- Goal should be to generate efficient translators, not go up through intermediary every time
- Intermediary needs to have broad semantic scope
Semantic Interoperability — understand what the data/actions mean (Probably rooted in ontologies, vocabularies)
Structural: Know how to find certain information, understand the composition (Information Model?, Data Model?, ASN.1, XSD, ...) Two levels:
- primitive -- constrained by serialization [data model]
- more abstract, still structural [information model]
Syntactic: parse/generate (Serialization; pretty much domain-independent -- comes from representation framework, BER, XML serialization, EXI, JSON, CBOR...)
-
(Needs all three) Application wants to:
- control one or more devices
- possibly discover the right device for that
- Service Composition
- Rule Systems
-
(Can do with 1 and 2) Universal remote (generic object browser, does not understand semantics) -- Human does the semantic reasoning
-
Translator (does need to understand semantics)
-
Machine learning, big data aggregation
-
Data vs. Metadata (actual metadata vs. syntactic/structural/semantic metadata; static vs. non-static)
- Separation of metadata
- Need to match up structure of data with structure of separate metadata then (cf. CSS selectors) -- requires structural interoperability
- Find them
- through a link from the data
- through some external matching
- Separation of metadata
-
"Semantic Model is in the head of the developer" vs. who is responsible for semantically annotating the data from a device... (need structural interoperability to be able to do that); manufacturer-provided vs. integrator-provided ("fifth floor" = context information)
Describing
- "the thing as manufactured" [information that should not have to be added by integrator]
vs.
- "the thing as integrated, with applied metadata"
Ontologies vs. Vocabularies vs. "Tagging dictionaries" (e.g., Haystack, cf. OCF RTs)