Code Monkey home page Code Monkey logo

xdm's Introduction

Experience Data Model (XDM) Schema

CircleCI Greenkeeper badge

The Experience Data Model (XDM) is the language of digital experiences. XDM is a publicly documented specification, driven by Adobe to improve the interoperability, expressiveness, and power of digital experiences. This repository contains the source code for the formal specification of the XDM model, using the JSON Schema language.

Current Version

XDM is at version 1.31.4.

You can find more about our versioning in docs/introduction.md

XDM Visualization

See visualization of the master branch, which is refreshed every 12 hours.

Read the XDM Spec

Project Layout

The project is laid out in the following way:

  • docs: Markdown files that contain front-matter, introduction, and non-normative parts of XDM
  • schemas: JSON schema files that define out of the box cross user schemas
  • components: JSON schema files that define the AEP components used in the composition model to create schemas usable within UPS
  • extensions: JSON schema files that define vendor or solution specific components used within the composition model of AEP
  • package.json: a build file for npm that allows the generation of Markdown from the JSON Schema source files and (later) the generation of an AEM package to be deployed on the Adobe I/O Website
  • README.md: this file
  • CONTRIBUTING.md: guidelines for contributors, covering process, conventions and design guidelines

File Types

  • *.schema.json is the schema file, e.g. profile.schema.json – we pick the .json file extension for easy syntax highlighting in editors
  • *.example.*.json is an example file that will be validated against the *.schema.json file, and if successful, merged into the *.schema.json file as an "example" field at the root of the schema before it is converted into Markdown or published
  • *.invalid.*.json is an invalid example file that will be validated against the *.schema.json file. If the invalid file validates (false positive), the schema is too lax and the overall build will fail. invalid files will not be merged into documentation.

Tooling

The tooling project (e.g. for generating Markdown documentation, example validation, JSON Schema documentation inlining) is located in the adobe/jsonschema2md git repository.

Dependencies

You need:

  1. Node.js and npm
  2. curl

Validation of local changes prior to creating any Pull Requests to adobe/xdm

This project contains a minimal validation script that depends on NPM. You can use it to validate the JSON example files against the JSON Schema files after making changes to either.

From the root directory of the local repository run:

$ npm install
$ npm test

> [email protected] test /Users/fmeschbe/src/platform/xdm
> mocha
...

$ npm run lint
...

If you see warnings or error messages (or an non-zero exit code), fix them before making a pull request.

Naming Conventions

AEM Package Generation (optional)

With all dependencies installed, run the following commands from the root directory of the local repository:

$ npm install
$ npm run package

This will fetch all dependencies, then generate Markdown in the docs/reference directory and then generate an AEM package under xdm-docs.zip. The package can be uploaded using the command

$ npm run upload

upload will upload to the Adobe I/O Staging instance. To upload to production, use upload:prod instead.

The AEM password is not saved in this repository (of course), but you can set it using this command:

$ npm config set xdm-models:aem_password $AEM_PASSWORD

This is assuming $AEM_PASSWORD has been provided to your Continuous Integration system or set on the command line beforehand.

Running upload will only make the documentation visible on the "author" instance, this means visitors to the site cannot see any of the documentation. To publish it, run the npm run activate or npm run activate:prod commands.

A full process would then look like this:

$ npm config set xdm-models:aem_password $AEM_PASSWORD
$ npm install
$ npm test
$ npm run package
$ npm run upload
$ npm run activate

This will generate documentation, create an AEM package, install it on (stage) author, and activate it from there, so that visitors can read the documentation.

A Note on Dependencies

The package.json script will fetch a released version of the AEM Markdown Importer JAR using curl.

Links

Specifications

Vocabularies/Ontologies

License/Copyright

Copyright 2017 Adobe Systems Incorporated. All rights reserved. This work is licensed under a Creative Commons Attribution 4.0 International (CC BY 4.0) license.

You are free to:

  • Share — copy and redistribute the material in any medium or format.
  • Adapt — remix, transform, and build upon the material for any purpose, even commercially.

This license is acceptable for Free Cultural Works.

The licensor cannot revoke these freedoms as long as you follow the license terms.

Under the following terms:

  • Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
  • No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.

xdm's People

Contributors

aarjain avatar anandphatak avatar bisin-adobe avatar cdegroot-adobe avatar chrisdegroot avatar cmathis avatar deckardrick avatar dmitry-shkolnik avatar fmeschbe avatar gabebarcelos-adobe avatar harleensahni avatar iewilliam avatar jbeckert avatar jbranson000 avatar jishah-adobe avatar jwen-adobe avatar kenadobe avatar kevinlind avatar kstreeter avatar lidiaist avatar mjasrotia avatar ogoldman avatar prabhum2 avatar ragarwal1974 avatar russstringham avatar seth0115 avatar stefan-guggisberg avatar themanikjindal avatar trieloff avatar usankara avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

xdm's Issues

Which version of JSON schema should we use?

I think we should standardize on which version of JSON schema we use while authoring our model schemas. Even though newer versions may be more expressive, there might not be adequate tooling around them yet.

Draft-04 has quite a wide support. If any newer version has adequate support we should move our models to that, or otherwise, let's settle for draft-04.

What are the schemas that are affected by the issue

All schemas in this repo

What are examples of products that are impacted by the issue

None

Patterns for Schema extensibility/inheritance

While we are waiting for #43 to come to fruition, I wanted to gather my thoughts for the second class of extensibility that is not covered in #43: introducing new schemas that "extend" core XDM schemas, allowing XDM consumers to know that a certain schema is compatible with the extended schema.

  • definitions work like mixins: you can combine multiple to build a complex schema
  • the properties at the root of a schema define a concrete schema, but limit re-usability
  • best practice for extensible schemas: use definitions and $ref them using allOf
  • best practice for non-extensible schemas: don't use definitions, put everything into the root of the schema
  • best practice for schema fragments (not directly instantiable): only use definitions but don't $ref them in the current schema
  • adjust the tooling to discover the three patterns and warn about deviations

Need to decide on naming convention for properties: camelCase versus snake_case

In PR82 there is a discussion on use of camelCase versus snake_case for property names. The README clearly calls out use of camelCase, except when the schema is based on an existing standard that uses a different convention. But it appears that several schemas, including the asset models, use snake_case.

We need to make a decision on which way to go here. I personally feel very strongly we use camelCase, since that is the generally used convention for JSON, and is the one used by both CDM and schema.org schemas. It is also what is currently used by all the experience/DMa models.

What are the schemas that are affected by the issue

All

What are examples of products that are impacted by the issue

All

Rendition retrieval needs to support params on GET

From another doc

A rendition resource may be retrievable, although user agents cannot specify the desired size. This permits user agents to fetch a rendition in a single request, when a rendition is available for the given asset and only at some default size determine by the server. User agents that wish to obtain renditions at a particular size should first use a HEAD (or other) request to obtain a full set of rendition links.

This seems to imply that a client can't pass any parameters to the GET on a rendition - that is extremely problematic for custom renditions

PersonName is not i18n-friendly

As discussed in #46, the CDM PersonName as it stands does not work outside the US and English-speaking Canada. We need to work with Microsoft on a fully i18n-friendly PersonName that can cover all languages that our customer's customers speak.

Define workflow for localization

We need to define how we store/manage localized model definitions, and work out how we support the localization team in their work.

Clean up keywords and subjects

#40 (comment)

@lrosenthol I think we should clean up the descriptions of dc:subject, xmp:keywords and amp:machineKeywords to better reflect the current state of things, not how the XMP designers imagined things would play out. Could you take a stab at it?

Clarify Layer Styles

In https://git.corp.adobe.com/AdobeCloudPlatform/xdm/blob/master/schemas/assets/layer.schema.json#L22 the description indicates:

A layer style is one or more effects applied to a layer or layer group. You can apply one of the preset styles provided with Photoshop or create a custom style. Photoshop provides a variety of effects—such as shadows, glows, and bevels—that change the appearance of a layer’s contents in a non-distructive way. Layer effects are linked to the layer contents. When you move or edit the contents of the layer, the same effects are applied to the modified contents. For example, if you apply a drop shadow to a text layer and then add new text, the shadow is added automatically to the new text.

What is unclear:

  • What are example values for layer styles?
  • How can layer styles be concatenated if there are multiple effects?
  • Should we have a style property for layer-group.schema.json too?

Extensibility model for enums

As pointed out by @masinter in #51 – we need an extensibility model for enum values. Right now, all our enums are "hard enums", i.e. an unknown value is a validation error.

In some part of the asset schema, we have "soft enums", i.e. without any validation, but a list of known values.

Exclude Escape Characters from Property Names

What are the schemas that are affected by the issue

all

What are examples of products that are impacted by the issue

all products that need to escape certain characters in property names.

xdm:createDate & xdm:modifyDate required?

In the asset schemas, xmp:createDate and xmp:modifyDate are required. How can these be required? Where would the value come from if the asset has now xmp packet?

Missing examples for activity stream schemas

What are the schemas that are affected by the issue

schemas/external/activity-streams-2/xsd-anyURI.schema.json has 0 examples
schemas/external/activity-streams-2/link-rel.schema.json has 0 examples
schemas/external/activity-streams-2/activity.schema.json has 0 examples
schemas/external/activity-streams-2/mime-media-type.schema.json has 0 examples
schemas/external/activity-streams-2/collection.schema.json has 0 examples
schemas/external/activity-streams-2/xsd-duration.schema.json has 0 examples
schemas/external/activity-streams-2/link.schema.json has 0 examples
schemas/external/activity-streams-2/xsd-nonNegativeInteger.schema.json has 0 examples
schemas/external/activity-streams-2/object.schema.json has 0 examples
schemas/external/activity-streams-2/rdf-langString.schema.json has 0 examples
schemas/external/activity-streams-2/date-time.schema.json has 0 examples
schemas/external/activity-streams-2/xsd-dateTime.schema.json has 0 examples
schemas/external/activity-streams-2/uri.schema.json has 0 examples
schemas/external/activity-streams-2/person.schema.json has 0 examples
schemas/external/activity-streams-2/service.schema.json has 0 examples
schemas/external/activity-streams-2/group.schema.json has 0 examples
schemas/external/activity-streams-2/image.schema.json has 0 examples
schemas/external/activity-streams-2/type.schema.json has 0 examples
schemas/external/activity-streams-2/page.schema.json has 0 examples
schemas/external/activity-streams-2/xsd-string.schema.json has 0 examples
schemas/external/activity-streams-2/document.schema.json has 0 examples
schemas/external/activity-streams-2/id.schema.json has 0 examples
schemas/external/activity-streams-2/organization.schema.json has 0 examples
schemas/external/activity-streams-2/language-tag.schema.json has 0 examples
schemas/external/activity-streams-2/collection-page.schema.json has 0 examples
schemas/external/activity-streams-2/context.schema.json has 0 examples
schemas/external/activity-streams-2/application.schema.json has 0 examples

Access Control Policy

Note: This is not a concrete pull-request yet but serves to help discuss the topics of pull-request #43

JSON Schema, JSON-LD @context (2 variants), 2 examples

This pull request serves to explore the idea that we define both JSON-LD contexts and JSON Schemas for our models:

  • The JSON Schema defines the data model properly, where each property has its own top-level definition.
  • The accesscontrolpolicy.jsonld defines the Context referring to the definitions and using JSON-LD compact URIs to define the terms used in the JSON Schema
  • The accesscontrolpolicy-alternate.jsonld defines the Context just refering to the definitions using the @vocab special property implying non-namespaced properties to "resolve" to the @vocab property IRI.

The JSON-LD context IRIs used actually are in JSON Schema reference form. So that actually resolving these IRIs should turn to the actual property definition in the JSON Schema file.

The nice thing about this hash-notation is that when converting this to HTML, we can use simple HTML anchors derived directly from the JSON Schema file.

Clean up double-definitions in Activity Streams

@majindal in the activity-streams schemas, there are a number of definitions imported from RDF and XSD that largely mirror existing JSON Schema constructs. We would benefit from having this simplified by directly using the corresponding JSON Schema constructs and to remove the superfluous type definitions.

This repo needs a style guide.

We need to add a style guide to this repo that auto applies at the time of a git commit or push. Plus, tabs vs spaces, bring out the pitchforks people.

What are the schemas that are affected by the issue

None

What are examples of products that are impacted by the issue

None

Is Asset Rating user editable?

Right now, it is marked as not user editable, but that conflicts with the description that says the asset rating has been set by a user.

Clean up Address and Geo

Looking at the experience-cloud-staging branch and have a couple of suggestions for Address and Geo that go beyond cosmetics.

Address is now extending Geo, this allows us to reduce a lot of redundant info.

  • Is there a good reason for cutting off the country part of stateProvinceISO? Keeping it would make it easier to describe the data (just ISO 3166-2) and it's unlikely that someone wants to look at region independently from country.
  • Are there objections against moving stateProvinceISO up to Geo, replacing the current (free-form) stateProvince?

Clarify state_province in geo.json

What are the schemas that are affected by the issue

common/geo.schema.json

What are examples of products that are impacted by the issue

All products that read geo-information.

What is the issue

The current name and description are a bit unclear. state and province describe the US/Canadian perspective, and I can derive that in Germany it would probably be the "Länder" administrative unit.

What is unclear:

Define a standard Address entity that aligns with Microsoft CDM

We need an XDM Address entity that aligns well with Microsoft CDM. @masinter has taken a look at what was defined early on by DMa and what is currently part of the CDM schema and had these recommendations:

Address: Layers don't align. CDM is a Compound data type, while XDM core Address entity includes metadata like "primary" and "type"; CDM puts things like that inline where the address is used, e.g. HomePostalAddress. CDM fields seem more I18N friendly. They even disagree about number of lines in the "Street" part of an address. Recommendation: Rename XDM Address such that it is an Entity (wiwth audit properties). Rather than trying to settle between 4 and 5 lines at the Schema level, generalize street to be an array of lines, perhaps 2 (min) or 4 (max). Separate XDM's Address (DeliveryAddress) with 'primary', 'type', status, geo, audit, etc.

Address should align as much as possible to allow for easy data interchange between XDM and CDM.

I propose that the Address entity look something like the following:

{
    "id": "core/Address.schema.json",
    "$schema": "https://git.corp.adobe.com/experience-platform/sdm-specification/blob/master/json/schema.json",
    "title": "Address",
    "type": "object",
    "description": "A postal address. Address could relate to a persons home, work, preferred store location etc.",
    "properties": {
        "street1": {
            "title": "Street 1",
            "type": "string",
            "description": "Primary Street level information, apartment number, street number and street name."
        },
        "street2": {
            "title": "Street 2",
            "type": "string",
            "description": "Optional street information second line."
        },
        "street3": {
            "title": "Street 3",
            "type": "string",
            "description": "Optional street information third line."
        },
        "street4": {
            "title": "Street 4",
            "type": "string",
            "description": "Optional street information fourth line."
        },
        "city": {
            "title": "City",
            "type": "string",
            "description": "The town, city, village or other metropolitan identity of the address."
        },
        "region": {
            "title": "Region",
            "type": "string",
            "description": "The region, county, or district portion of the address."
        },
        "stateProvince": {
            "title": "State or province",
            "type": "string",
            "description": "The state, province, region, territory portion of the address."
        },
        "postalCode": {
            "title": "Postal code",
            "type": "string",
            "description": "The postal code, zip code of other postal ordering for the address. Note, if zip codes are used either the base zip or zip+4 format can be used."
        },
        "country": {
            "title": "Country",
            "type": "string",
            "description": "The name of the government-administered territory."
        }
    }
}

Method of defining tags or keyword

What are the schemas that are affected by the issue

https://ns.adobe.com/xdm/assets/asset
but might be its own schema or impact other schema.

What are examples of products that are impacted by the issue

AEM and other products that store content that needs to be tagged.

While the assets schema has xmp:keywords and xmp:machineKeywords which might be used to tag an asset with a keyword, there is no XDM way of describing a keyword or organising a keyword into an ontology of tags, even if that ontology is flat.

Many products that store content organise that content using tags and organise those tags into an ontology. Some examples:

Example 1.
In a DAM, Photographs may be tagged with "cars" which would be organised as a narrower term for "vehicles" and cards would contain narrower terms of "performance", "family".

Example 2.
In a Drugs dictionary, Documents containing medical advice for prescription drugs may be tagged with the family of drug and the families of drugs that cause adverse interactions, hence a patient taking Asprin, classified as a salicylate and a nonsteroidal anti-inflammatory drug would alerted that it has a serious interaction with Ketorolac, by virtue of Aspirin being a NSAIDs. Each tag would be defined in a managed ontology.

Example 3.
In an audience targeting platform, the segments into which browsers are placed would be related to one another.

The structure of defined tags or keywords needs to support both hierarchical (DAG) and non DAG type graphs, although most uses are probably for hierarchical relationships rather than multi faceted relationships between the keyword or tag definitions.

The ask is for
a) A schema to define the tags and keywords
b) a mechanism to define the relationships between those definitions.

Fix unresolved references

Running XDM through jsonschema2md discovers a couple of unresolved references. Generally this is where links in a property declaration or array item declaration have been made to a type's definitions object, not to the type itself.

This includes:

  • Language Alternative
  • Copyright
  • Resource Event
  • Font
  • Personname

Define collaboration comments/annotations

From the discussion in #53 an important side-track has spun up:

Also, comments (which you have in content) are a completely separate thing (aka neither content nor asset) that I am working to define (as part of the Collaboration pieces of ACP). A comment (not unlike a layer or artboard) is a container for content/assets, not a type of either.
FYI: The basis for the model for comment is https://www.w3.org/TR/annotation-model/ - the W3C standard model for annotations/comments on which the ACP commenting system (aka RedHawk) is based.
@lrosenth

This is coming just at the right time, because the type of comment that I had in mind when I suggested /content/usergenerated-comment.schema.json is a type of user generated content that you would make as a reader in response to a blog post or facebook post. (the stuff that people refer to when they say "always skip the comments")

The type of comment that @lrosenth seems to have in mind is more an editorial comment that is part of the production of an asset (but can also be applied to content, as illustrated by annotations in AEM).

It is clear that we have another example of the duality that we've already seen between @noahe's collaboration profile and @kstreete's customer/visitor profile.

Let's identify the commonalities and differences between the approaches taken in collaboration systems and moderation systems and define a schema for collaboration comments/annotations.

Use @id instead of custom ID properties

As we rely on JSON-LD semantics more heavily (see also #43), I thought it made sense to follow JSON-LD conventions when it comes to IDs and:

  • use the @id property to identify the current object, instead of in addition to *_id properties that differ from schema to schema
  • use URIs (specifically IRIs) to identify objects instead of having an off-band resolution mechanism

This pull request applies this convention to the asset schema category.

Use dc:title instead of xdm:title

We currently have our own xdm:title, which is semantically equivalent with schema.org#title, so we should use that instead

What are the schemas that are affected by the issue

Page

What are examples of products that are impacted by the issue

  • AEM

Initial draft proposal for Directory XDM schema

This is an early draft proposal for the Directory XDM schema based on the ACP Directory Resource definition at https://git.corp.adobe.com/pages/AdobeCloudPlatform/api-spec/repository_api/directory_resource_syntax.html.

We hope to use this PR is to kickstart the review process and get early feedback and guidance. We still have many questions on how a Directory XDM schema would fit in with the existing schema structure defined in this git repo. Here are some of our questions:

  • Should there be a 1:1 relationship between ACP mimetype and XDM schema? For example, we'll need a Directory schema to support the ACP directory mimetype "application/vnd.adobecloud.directory+json".

  • Should XDM schema include definitions for ACP hypermedia links? I don't see hypermedia links defined in the current Asset schema definition.

  • What is component-container.schema.json? Is it a generic schema for containers like a Directory?

  • If there needs to be a separate schema for XDM Directory, where should this Directory XDM schema definition go in the schema structure defined in https://git.corp.adobe.com/AdobeCloudPlatform/xdm/tree/master/schemas? Should we define a new directory.schema.json under the "content" folder there?

Define user-generated content comments

From the discussion in #53 an important side-track has spun up:

Also, comments (which you have in content) are a completely separate thing (aka neither content nor asset) that I am working to define (as part of the Collaboration pieces of ACP). A comment (not unlike a layer or artboard) is a container for content/assets, not a type of either.
FYI: The basis for the model for comment is https://www.w3.org/TR/annotation-model/ - the W3C standard model for annotations/comments on which the ACP commenting system (aka RedHawk) is based.
@lrosenth

This is coming just at the right time, because the type of comment that I had in mind when I suggested /content/usergenerated-comment.schema.json is a type of user generated content that you would make as a reader in response to a blog post or facebook post. (the stuff that people refer to when they say "always skip the comments")

The type of comment that @lrosenth seems to have in mind is more an editorial comment that is part of the production of an asset (but can also be applied to content, as illustrated by annotations in AEM).

It is clear that we have another example of the duality that we've already seen between @noahe's collaboration profile and @kstreete's customer/visitor profile.

Let's identify the commonalities and differences between the approaches taken in collaboration systems and moderation systems and define a schema for user-generated content comments, as opposed to the collaboration comments defined in #65 – but ideally with enough overlap and use of a common base model like the W3C Annotation Model

Use examples instead of meta:example

JSON Schema uses the examples keyword and jsonschema2md only supports example, not meta:example.

Change all the meta:example instances to examples. Note that examples must be an array.

Schema filename unification needed

While most of the complex names are in kebab-case (e.g. schemas/assets/copyright-owner.schema.json), some are still in concatenated lowercase. Files need to be renamed, $id property changed respectively and $ref in other files updated.

What are the schemas that are affected by the issue

schemas/common/eventenvelope.schema.json
schemas/common/identityprovider.schema.json
schemas/context/personname.schema.json

schemas/context/person.schema.json
  18:  "$ref": "https://ns.adobe.com/xdm/context/personname",

schemas/common/principal.schema.json
  16: "$ref": "https://ns.adobe.com/xdm/common/identityprovider#/definitions/xdm:name"

Document how XDM models and entities are internationalized

We need to document how XDM models and entities will allow multi-lingual metadata to be defined for properties that are used to provide end user facing strings such as title and description.

JSON Schema has an open issue on how this might be achieved and JSON-LD defines how string internationalization should occur in their w3 spec.

I personally like the JSON schema proposal nest as it allows for the use of $ref to externalize the localized strings which will decouple the localization from the model definitions. Unfortunately, the proposal has yet to be accepted in to the JSON and the conversation in the issue seems to have trailed off over a year ago.

Once we align on the approach we'd like to take I'll open a PR with the documentation changes.

Thanks.

modelling self service

What are the schemas that are affected by the issue

None - new schema

What are examples of products that are impacted by the issue

Ethos, marketing.adobe.com provisioning and deployment in general, self service.

I have been asked to try and represent the terminology in https://wiki.corp.adobe.com/display/~asaar/Self+Service+-+Terminology+and+Data+Model in XDM in a way that works for all of Adobe, not specific to AEM and probably not specific to deployment on Ethos. (ie including self service environments outside the Adobe Platform).

Verify and adjust the definition of "content"

From the discussions in #42 and #53 it comes clear that the definition of /content in /schemas/content/content.description.md might be in need of a revision.

To keep the discussion focussed and constructive, I'm separating the discussion of the name and grouping of "content", from the discussion of individual elements of "content", so that issues like #42 can be merged, even if we decide to change the schema location from /content to /somewhereelse later on.

Please propose pull request, referencing this issue, that:

  • adjust the content.description.md
  • (if needed) rename the content folder
  • (if needed) move the current contents of content (no pun intended) into the proposed place
  • follow generally industry-accepted definitions of "content" or other terms introduced
  • support these definitions through external references in relevant literature, existing standards, etc.

Modeling Confidence in XDM Data

Based on a conversation with @nangia: a key aspect of digital marketing is that the identity of the consumer is largely probabilistic. Whether products make it explicit or not, the data that we have about a consumer is messy, and largely untrusted. A profile is typically constructed from multiple data sources, including:

  • direct user input (although users regularly enter false information in online forms)
  • inferred from user behavior (with implicit inaccuracy)
  • acquired from third-party data sources (with implicit inaccuracy)
  • through rule-based or probabilistic merging of profiles (with explicit inaccuracy)

Therefore, a system that represents consumer profiles in a digital marketing world needs to be able to express the inaccuracies, eventual contradictions, and missing data that occurs in the real world. This is a key differentiator from the way how collaboration systems or CRM systems look at the world (they have an inherent assumption of clean data).

We need a way to express these scenarios in JSON.

What are the schemas that are affected by the issue

  • Profile

What are examples of products that are impacted by the issue

  • Adobe Target
  • Adobe Analytics
  • Adobe Audience Manager
  • Adobe Media Optimizer
  • Adobe Social

Identity Provider/Principal needs clean-up

While working on #51 I noticed some inconsistencies in the principal schema. It references the xdm:name property from Identity Provider, implying that it is the identity provider's name. In reality, it looks like it is the principal's name, which is confusing.

Principal should have a property xdm:provider which points to the Identity Provider.

What are the schemas that are affected by the issue

  • Principal
  • Identity Provider

What are examples of products that are impacted by the issue

  • all

Clean Up Audit Trail

I've made some cosmetic changes to Audit Trail already in 8e4de5f, but I think more is needed.

  1. Audit Trail right now is not a trail, it's simply a last modified date (+etc.). This is an inaccuracy
  2. Just like assets and content have the last modified date (+etc.) they should be part of the core entity. This is an inconsistency
  3. Audit Trails are referencing a "batch ID", but what that batch ID points to and what a "batch" looks like is never specified. This is an omission.

We should fix (3) right away, by modeling a batch or bulk update (maybe treat the bulk update as an Event Envelope) and decide if we want to go down the route of (1), i.e. make AuditTrail an array or (2), i.e. drop the xdm:audit property and instead merge the audit trail properties into the schemas that currently have the xdm:audit property.

@kstreeter and @jwen-adobe, your feedback is appreciated.

What are the schemas that are affected by the issue

In branch experience-cloud-staging:

  • address
  • audit trail
  • person
  • email address
  • phone number
  • profile

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.