Content Enrichment - Updating System Defined Managed Properties (Author, Department)

Question

Hi
I've been running into a couple of oddities whilst working with the content enrichment web service.   Initially I worked through the sample here:
http://msdn.microsoft.com/en-us/library/jj163982.aspx#SP15ContentEnrich_configure, which shows how to update the "Author" managed property.   In our case this is something we'd like to do but I haven't been able to get this to work at
all with the system defined "Author" managed property.
When we crawl the content everything seems happy enough however we don't get the extra author value "ExampleService" appearing against the "Author" managed property.   I've setup a 'replica' of the "Author" property
"AuthorReplica", which has the same crawled property mappings etc and the enrichment service happily updates the values of this when I run a full crawl.  
To further test this I've rebuilt the Search Service as well as also starting up a brand new seperate SharePoint instance.   In all cases I can happily update the "AuthorReplica" managed property but the system defined "Author"
property won't update at all.  
I noticed that their is some type of relationship between the "Author" managed property and the "DisplayAuthor" property and I wonder if this could be related.   I also notice with the "Author" managed property, that
it provides an user lookup type box when you display it as a refiner.   Perhaps their is some further processing occuring with this Managed Property further along which knocks out the update I make.
A second oddity that I've noticed has been with the "Department" property.   In our case we have instances where content may cover multiple departments.   To enable this I have updated the "Department" property to
"Allow multiple values".   When I then attempt to update the department property I receive the error: "The item failed due to an error occurring when sending or receiving data to the external content processing enrichment web service."  
Again, I've created a replica of the "Department" managed property called "DepartmentReplica" which allows multiple values, and this property happily updates using the same code.
Hopefully this all makes sense.
Regards
Pete

Answer 1

Hi petecuttriss,
my colleague explained to me with quite complicated method, but the summary that i can get is this issue is by design, so the behaviour is expected.
consideration:
if the author property is easily changed, then it may affect other feature that may use that as base point.
explanation:
In this case while the indexing was mapping and being indexed properly based on the defined crawl
property the actual issue was display based and related to how the teaser summary was being defined and displayed based on the query.
By default the body attribute of the Search index-profile has a static fallback summary defined by the internal teaser field.  This static fallback summary is what is displayed whenever a query is being performed which
doesn't return any hits over the actual defined body field content(for example a query matching a term in the title or
author of a document).  Instead of returning the query context sensitive summary of the body with the highlighted query term, the defined fallback static summary is displayed.
So in this specific use case the dynamic summary based on the managed
property (body in this case) is only being used if the query submitted actually has a hit in the
managed properties content(i.e. the defined body).  Otherwise the defined fallback
managed property content is always being used(i.e. the default ‘teaser’
managed property content). 
Here are some example query results illustrating this using the two sample docs you provided with the teaser
managed property defined as the fallback hit highlighted summary for body:
Search for "John"(returns both docs with the fallback teaser summary since the query term is not in the body):
20120126-205524-205418a.html
Just got child of eden for the xbox after hearing great reviews about it.
Authors: System Account Date: 2/2/2012 Size: 4KB
http://moss14/Shared Documents/20120126-205524-205418a.html
20120126-205524-205418b.html
BlogPostID:288 BlogAuthor:john.a.evangelista BlogTitle:Check for Alerts BlogBody: Check for Alerts? BlogCategory:BusyBee,2-2 BlogCategoryS:;BusyBee;2-2; PostCategoryR:BusyBee;#2-2 BlogNumComments:0 BlogPublishedDate:7/28/2011 11:37:00 AM BlogModifiedDate:7/28/2011
11:37:00 AM BlogViewCount:10
Authors: System Account Date: 2/2/2012 Size: 3KB
http://moss14/Shared Documents/20120126-205524-205418b.html
Search for "Alerts"(only returns the one blog doc, teaser displayed is based on the body since alerts is contained in the body):
20120126-205524-205418b.html
Check for Alerts?
Authors: System Account Date: 2/2/2012 Size: 3KB
http://moss14/Shared Documents/20120126-205524-205418b.html
Search for "Eden"(only returns the one blog doc, teaser displayed is based on the body since eden is contained in the body):
20120126-205524-205418a.html
Just got child of eden for the xbox after hearing great reviews about it. Update: It is really cool!?
Authors: System Account Date: 2/2/2012 Size: 4KB
http://moss14/Shared Documents/20120126-205524-205418a.html
We can see in these query results when the search term is actually contained in the body content that the teaser returned is based directly on the body content(which is the mapped blogbody content).  Otherwise the teaser returned is from the static
hit highlighting summary fallback(literally the ‘teaser’ managed
property).
The problem in this case is that the "teaser" managed
property is internally generated by the indexing pipeline and
doesn't necessarily reflect the contents of crawled properties being mapped to the body field.  This difference initially caused the impression that sometimes the default body content was incorrectly being used instead of the mapped BlodyBody content. 
The only way to guarantee that the result list teaser summary shown is always going to be based on the body would be to set the body as its own hit highlighting fallback(as is the default case with some properties like ‘title’ for example).
Because body is a very important managed
property and making changes to it (like mapping a crawled
property) and modifying the way the indexing pipeline normally populates it can potentially produce unexpected results.  For all content sources which share the body
managed property the decision was made to not modify the body content and to let the indexing pipeline
populate it automatically.  From the testing performed it was confirmed that the indexing pipeline was already populating the body using a number of the defined blog crawled properties including BlogBody.
If you wanted to always display the contents of a particular crawled
property as a part of the results list display you can always just create a new
managed property and map those crawled
property contents to it(assuming a mapping did not already exist).  Then just display that
managed property as a part of your results.
The only remaining point of potential concern was if not mapping the BlogBody and BlogBodyNoHtml crawled properties to the CrawledPropertiesContent
managed property would prevent them from being used to
populate the body field by the indexing pipeline.
After removing all the blogbody crawled property related mappings to the body and crawledpropertiescontent
managed properties I re-crawled the two blog sample documents I was provided with some spy stages inserted into the indexing pipeline so I could see exactly what was being inserted into the BODY attribute.  This is what the body
managed property populates and what is mapped to the default context full-text-index that all the “free text” searches are being performed against.
Regards,
Aries
Microsoft Online Community Support
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.