10

Usually we recommend to use camelCasing for field XMLNames during Schema creation. However sometimes we see the opposite.

I have a field in schema that using PascalCasing in XML Name Description and I am trying to map it to Model Property with TRI v1.0.1. Based on documentation I was hoping to achieve it with explicit semantic mapping like this:

[SemanticEntity(Vocab = "http://schema.org", EntityName = "Product", Prefix = "s", Public = true)]
public class Product : EntityBase
{
...
[SemanticProperty("s:Description")]
public string Description { get; set; }
...
}

However it did not work for me. Is there something that I am missing?

  • what SemanticEntity annotation is added to the class where this property is part of? Could you edit your question and add the source code of the class too, so we know what vocabulary is meant by the prefix "s"? – Bart Koopman Feb 2 '15 at 9:14
  • Added source code of the class too – Stan Kroshchenko Feb 2 '15 at 19:36
3

I haven't tried using PascalCasing Schema fields myself, so not 100% sure if that will work. But since the standard in STRI is using camelCasing, I think it makes sense to stick to that standard, mixing the two is confusing to everybody wouldn't you say?

However looking at your annotation what is happening is the following:

  1. you annotate with the prefix "s", so I'm assuming there is a SemanticEntity annotated on the class with a vocabulary defined, most likely that is "http://schema.org"

  2. this means your Schema will need to be annotated with that vocabulary too, and the field will need to be annotated with the mentioned property as described in the documentation

However, I think you will be able to test this quicker if you just follow the process of mapping an Entity field to a Schema field with a different name.

So for example, if your Schema field was named "headline", you would use the following in your Entity class:

public string Headline { get; set; }

But if you wanted your Entity field to be named Subtitle for instance, you would then annotate it like this:

[SemanticProperty("headline")]
public string Subtitle { get; set; }

Now if I understand corrrectly, you have a Schema field Description, so I would suggest to simply try:

[SemanticProperty("Description")]
public string Description { get; set; }

If that doesn't work, then you can go the route of Semantic mapping via a vocabulary (which means using prefixes), but then don't use schema.org, since that does not have a field Description. You will have to use a custom vocabulary (you can simply use http://stan.org). Make sure you follow the documentation to map that vocabulary correctly on the Schema and annotate the field, and then don't forget to republish the settings (because else this new Schema mapping isn't known by the web application).

  • 1
    +1 to stan.org for Stan projects. Otherwise an organization can help make it clear who put in the mapping. :-) – Alvin Reyes Feb 2 '15 at 11:32
  • @AlvinReyes I would indeed suggest to use the customer name for their custom vocabulary, or use a public vocabulary if available and when it makes sense ;o). – Bart Koopman Feb 2 '15 at 11:51
  • Would the schema.org specification itself count as a vocabulary? I'm curious about other examples of a public vocabulary. – Alvin Reyes Feb 2 '15 at 16:20
  • @BartKoopman Does it mean that every time when we specify SemanticEntity attribute on our model, we also have to specify semantics on Schemas in CM? – Stan Kroshchenko Feb 2 '15 at 21:08
  • 1
    @StanKroshchenko not really (that sentence is perhaps a bit too broad and might be misleading), that is still assuming that the model class already has semantics set on it. So looking at the Article model, you could create a new Schema Blogpost, and map that to the Article model using the schema.org semantics. – Bart Koopman Feb 4 '15 at 9:27
6

Looks like you're seeing the default semantics when not "annotating" the view model:

When attempting to populate a View Model property from the Content Manager model, look for a Schema field with the same name, but using camelCasing instead of PascalCasing. For example, the property Headline is mapped to Schema field headline.

We annotate the Schemas with AppData (not visible in the CME). See part three of the docs, where it describes field mappings with a PascalCasing convention, done inline in the the Schema source (e.g. name="TextField" in the example).

I played with Bart Koopman's TridionWorld custom page to change these, see the source at: https://code.google.com/p/sdl-tridion-world/source/browse/AppData%20Custom%20Page/trunk.

Placing these under the CME (in IIS and matching folders) to browse and change the AppData in a GUI. For example I have the AppData extension files in:

%TRIDION_HOME%\web\CustomPage\AppData\

And in IIS:

SDL Tridion\CustomPage\AppData Where CustomPage is a folder and AppData is an application.

Someone else can confirm (Bart), but I believe The custom vocabularies (annotations) go in the left and Schema mappings go on the right (note the URL [CME URL]/CustomPage/AppData/):

Custom AppData Page

Edit: clarified field-level annotation is in the Schema source (.xsd) based on Bart's comment.

  • Schema annotation is appdata, field annotation is done inline the XSD, see the Article Schema for an example. When adding custom vocabularies, indeed, you add the vocabulary on the left in the custom page (under vocabularies) and define a certain prefix for it. You can then map a Schema to a type of that vocabulary on the right via the Schema mapping, using <typeof>prefix:type</typeof> – Bart Koopman Feb 2 '15 at 8:51
  • Semantic annotation on Schema and Schema fields are applied when we don't want to modify View Model in Web Application. In my case I want to control all mappings in Web App. – Stan Kroshchenko Feb 2 '15 at 19:59
  • Makes sense, especially if we wanted an STRI delivery setup against existing Schemas and content. I guess the next question is if we currently can't set these, what parts can we change versus what's a "product" request/issue (the repository's issues list is on GitHub). – Alvin Reyes Feb 3 '15 at 11:10
1

Based on Bart's answer I made it work by removing prefix from SemanticProperty attribute.

[SemanticEntity(Vocab = "http://schema.org", EntityName = "Product", Prefix = "s", Public = true)]
public class Product : EntityBase
{
...
[SemanticProperty("Description")]
public string Description { get; set; }
...
}

It means that SemanticProperty attribute for explicit mapping does not work with prefixes - that can provide structured content markup. In order to achieve it Semantic Mapping on Schema/Schema fields must be used.

  • 1
    If you use prefixes then your Vocab should match the Tridion schema namespace in order for the mapping to 'work'. As you say, alternatively you can also annotate your Tridion schemas with the schema.org semantics to drive the mapping. In your example above you could remove the schema.org semantics totally, or if you do want this in your rendered markup, add another [SemanticProperty("s:description")] annotation (as per schema.org/Product) – Will Price Feb 4 '15 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.