This sounds like a common data architecture problem and I can imagine several different ways you might have implemented it and a couple possible solutions. I think the best approach is if you could share more about the format of schema.csv. Include a snippet of the header and a couple of obfuscated records (ie. change any data that is customer identity or information sensitive).
The, you might share if you have any other data sources you are joining that are salient to the records in schema.csv. For example, left joining catalog.csv with schema.csv on schema_id. This might help identify if you are joining on an inadequate key or other relationship that produces inappropriate records - ie. records with too many size attributes.
I think your best bet is to add a record manipulator to break your 1 source attribute "Weight" into 3 source attributes, "Weight-ml", "Weight-mg", "Weight-kg". Then in your property mapper component, you can map each of these 3 source attributes to the appropriate Endeca dimension for each. This will solve the erroneous double-tagging you're experiencing today.
The solution is straightforward. The challenge lies in the sometimes less-than-intuitive XML-based logic of the record manipulator. The manipulator should do the following:
1) For each incoming record, check if the Weight coming in is kg, mg, or ml.
2) Create a source attribute (aka. source property) that gets added to the record depending on what type of weight (e.g. Create "Weight-kg" with a value equal to the original source attribute "Weight"'s value.)
Then in the property mapper, you can map the ml, mg, and kg Weight source properties to the Endeca ml, mg, and kg dimensions.
Check out the VOID IF and VOID CREATE functions from the manipulator syntax guide here: http://docs.oracle.com/cd/E28912_01/DeveloperStudio.612/pdf/DataFoundryExpRef.pdf
As per Documentation
About range filters
Range filter functionality allows a user, at request time, to specify an arbitrary, dynamic range of values
that are then used to limit the records returned for a navigation query.
The remaining refinement dimension values for the records in the result set are also returned. For
example, a range filter would be used if a user were querying for wines within a price range, say
between $10 and $20.
It is important to remember that, similar to record search, range filters are simply modifiers for a
navigation query. The range filter acts in the same manner as a dimension value, even though it is
not a specific system-defined dimension value.
You can use a range filter in a query on record properties and on dimensions.
Configuring properties and dimensions for range filtering
Using range filters does not require Dgidx or Dgraph configuration flags.
Range filters can be applied to either properties or dimensions of the following types:
*• Properties of type Numeric (Integer, Floating point, DateTime) or type Geocode*
*• Dimensions of type Numeric that contain only Integer or Floating point values.*
So is i have created ranges for string property with values( 440 mg/1kg/440ml), so it is tagging the records in both 440 mg and 440 ml range. is there any other way to get this done.
Can you please be more specific detailing the range value you created? You state that you "have created ranges for string property with values( 440 mg/1kg/440ml)", but I am not sure I understand how that is a range value. What are the low and high ends of the ranges you've created? Per my earlier post, I am suggesting that you create a different range dimension for milligrams, kilograms, and milliliters.