I have a field "taxonomy" and I would like to pass it to Omniture. This Taxonomy field can have multiple values and I would like to calculate the count for each of the taxonomy separately. Let me explain my question with an example:
Item can be associated with multiple taxonomy. Letz say we are talking about an item called "Item1". This item can be associated with taxonomy "Tx1","Tx2","Tx3".
So the js code will be like,
s.prop1 = "Item1"
s.prop2 = "Tx1, Tx2, Tx3"
I was expecting omniture to store individual buckets/counters for "Tx1" "Tx2" and "Tx3". But Omniture created one bucket for "Tx1, Tx2, Tx3". I hope there is a way to treat them separately. Ideally I would not like to pass the taxonomies separately in separate prop variables.
I would appreciate if someone can point me in the right direction.
Thanks,
Rag
Actually Omniture does support list-style props, aptly called a list prop. You have to talk to Client Care to enable it for your prop, and you will need to specify a delimiter to use (like the comma). Then you would populate it exactly as you are doing, except without the space between the comma and value. ("a,b,c" not "a, b, c").
An alternative is the list eVar as Racheet mentioned. The difference is that a list prop sends in values and each value is within a prop variable scope, vs. the list eVar values are recorded with an eVar scope.
If you decide to do it w/ a list eVar instead of list prop, read up on how Omniture handles the allocation for them..there are some implications to consider with them only being able to be set to first or last allocation...
Omniture does have the functionality you're looking for from version 15 onwards. Unfortunately it won't do it in a prop. You need to use a slightly different variable type. The variable you're looking for is a list eVar.
Every implementation has three of these available:
s.list1
s.list2
s.list3
Here's the blog post where Omniture introduced them.
You can also find information on them in Knowledge Base article 10549 from inside the Adobe Marketing Cloud interface.
Related
Help me to resolve the query for Dialogflow agent!
I've defined an entity called "ProgrammingLanguages" and assigned 2 different reference values with common synonyms like below :
Android - Mobile OS, Mobile Development, Google
iOS - Mobile OS, Mobile Development, Apple
Already defined a intent with parameter named "ProgrammingLanguages" along with isList selected "Yes"
Now when I ask my agent "Show me the list of mobile os", it always returns "Android" only! when I replaced the sequence for values inside entity, it started showing me "iOS", That means, it's always taking the first value and didn't show all the values with similar synonyms for that particular entity!
Could someone help me to understand this behaviour?
Thanks,
This will not work correctly. You cannot put same synonyms for different Entity values. If you are using the same synonyms that means the two entities are same.
isList is used to capture multiple values for a parameter like if I am collecting brand names of cars, my entity will be car_brands and user can provide single value or multiple like Ferrari, Benz, Bugati, BMW or only Suzuki.
If you ask your agent "Show the list of mobile os" that means, it should return Android and iOS. Entities are not used to return response values. They are used to capture category for which you want bot/agent to return value.
In your case,
create an Entity and put all the above synonyms under one say "mobileOS".
when the user uses synonyms, mobileOS will be the captured parameter.
use it to decide and return all the mobile OS.
You don't need to enable isList as you are not collecting a list of values from the user.
Default a submitter (uploader) of a document can add self chosen keywords to that document.
It is also possible to configure DSpace in a way that the submitter has to choose from one or more predefined keywords (controlled vocabulary).
The DSpace manual seems to suggest that you - when configuring - have to choose between free and predefined keywords.
I would like to give the submitter the possibility to choose between one or more predefined keywords. But also that he or she can add one or more self chosen keywords.
Is that possible?
The hierarchical taxonomy feature gives you exactly this:
https://wiki.duraspace.org/display/DSDOC5x/Authority+Control+of+Metadata+Values#AuthorityControlofMetadataValues-HierarchicalTaxonomiesandControlledVocabularies
You can see it in the demo installation on the "subject" field: you have a lookup feature that allows lookup in a tree of subjects, but manually entered values are possible as well.
screencast:
http://screencast.com/t/0Cth3mORwxd
I personally would set this up to use two different metadata fields.
Something like dc.subject.whateverdescribesyourlistoffixedterms -- or even localschema.subject.whateverdescribesyourlistoffixedterms -- for the list of terms the user should select from. Note, for "whateverdescribesyourlistoffixedterms" I would choose something related to the name of the list of terms if at all possible (see example below).
dc.subject for "standard" user-supplied keywords
Then just add both to your input forms, perhaps going with Bram's suggestion of a hierarchical taxonomy for the first.
To give you better advice on what's most appropriate, it would be great if you could give some more details about what you're trying to achieve. For example
Is your list of fixed keywords something that's used beyond your own organisation? If yes, this strongly points to having its own metadata field to me, with the qualifier something that's related to the name of the classification system -- eg, dc.subject.anzsrc for the Australia/New Zealand fields of research codes.
Do you want to mix the two types of keywords in browse/facet options? You can do this even when they're in two separate fields. Have a look at the Discovery search filters & sidebar facets documentation and see how that puts dc.contributor.author and dc.creator into the author facet. The documentation for browse indexes has a similar example in the author browse.
Are both types of subject keywords required for submission? Both optional? One type required, the other type optional? You say in a comment (if I read you correctly) that you want the fixed keywords to be mandatory during submission, while the free-text keywords should be optional. That means they must be in separate metadata fields because otherwise you wouldn't know, if the submitter gives keywords, whether they are from the fixed list of terms or not. If you use separate fields, you can make eg dc.subject.anzsrc a required field in the submission form and dc.subject an optional one.
I was reading the Lua 4.0 manual and I came across this "tag" thing but I have no idea what it is referring to.
http://www.lua.org/manual/4.0/manual.html#3
That's the section where it mentions it but I still have no idea what the manual is talking about.
TL;DR: Tags are the precursor to modern-day meta-tables. Where now the event-handler-pairs are stored directly in the meta-table using normal table-manipulation, as it is a normal table, then we used those tags, normal though unique numbers, and special data-structures, which restricted the events we could set, and had a different interface.
One of the disadvantages of tags was they could not be garbage-collected as they were normal numbers, and thus their associated data could not either.
Quoting the important parts of section 3 "types and tags":
Besides a type, all values also have a tag.
Each of the types nil, number, and string has a different tag. All values of each of these types have the same pre-defined tag. As explained above, values of type function can have two different tags, depending on whether they are Lua functions or C functions. Finally, values of type userdata and table can have variable tags, assigned by the programmer (see Section 4.8). The tag function returns the tag of a given value. User tags are created with the function newtag. The settag function is used to change the tag of a table (see Section 6.1). The tag of userdata values can only be set from C (see Section 5.7). Tags are mainly used to select tag methods when some events occur. Tag methods are the main mechanism for extending the semantics of Lua (see Section 4.8).
So, think of tags as unique ids.
Every value has a tag, depending on its type:
All values of the types nil, number, string, function (C-flavor), function (Lua flavor) have a type-specific tag set on the C side.
All values of the types table and userdata have tags too, but those are set by the programmer for each value indepent from any other.
tag returns the tag, settag sets it for table and userdata, newtag creates a new one.
And looking at section 4.8 "tag methods", we understand that those unique ids are just used for comfortably associating all values of the same Lua type (or for tables and userdatas of the same semantic user-type) with special behavior:
Lua provides a powerful mechanism to extend its semantics, called tag methods. A tag method is a programmer-defined function that is called at specific key points during the execution of a Lua program, allowing the programmer to change the standard Lua behavior at these points. Each of these points is called an event.
The tag method called for any specific event is selected according to the tag of the values involved in the event (see Section 3). The function settagmethod changes the tag method associated with a given pair (tag, event). Its first parameter is the tag, the second parameter is the event name (a string; see below), and the third parameter is the new method (a function), or nil to restore the default behavior for the pair. The settagmethod function returns the previous tag method for that pair. A companion function gettagmethod receives a tag and an event name and returns the current method associated with the pair.
Which just boils down to settagmethod and gettagmethod being used to manage a mapping from tag+event to handler, and the runtime using that as an extension point.
As LHF mentions below, there's a wealth of additional detail and history in The evolution of Lua, for example how the tag-methods evolved from the previous extension-mechanism of "fallbacks", which did not support different behavior for separate groups of values, instead being global.
Is it possible to translate the display name of choice list items defined for LightSwitch entity properties?
I would like to be able to show different users translated display names in their language when they are viewing the SAME record, and also show translated names in the autocomplete combo box when they are editing a record.
Not really, no. The values are stored in the LSML file & aren't able to be modified at runtime. If you need to translate the values, then you'll need to use a lookup table (possibly by using a custom RIA service) instead of a Choice List.
The advantage of a Choice List is that it's very quick & easy to set one up.
The down side of a Choice List is the lack of flexibility, or even reusability (you have to define the values for the list every time you want to use it somewhere).
How can i create a queryset and view (#contacts in my situation) in rhomobile to list ActiveRecord objects alphabetically?
I'm trying to do this implementation;
A -> Contacts starts with A
B -> Contacts starts with B etc.
Final look: http://jquerymobile.com/demos/1.0b1/#/demos/1.0b1/docs/lists/lists-divider.html
Thanks
The simplest thing for you would be to sort your queryset and place listdividers (as you would do with jQuery Mobile) in your ERB file whenever the next element starts with a letter that is different from the one of the previous element (this could be achieved through a for-each loop).
I am assuming that you are using the Contacts API from Rhodes (Rhomobile). In that case there actually is an example here where they sort the contacts according to display_name. It should however be noticed that the display_name property only is available on the Android platform. You may therefore want to substitute it with the first_name or last_name properties that are supported on all platforms.
You can find another reference that explains sorting in Ruby here.