I have included into my ontology a specific data property which is of type xsd:DateTimeStamp as I am looking into this website which provides examples of supposedly acceptable literal values of that format http://www.datypic.com/sc/xsd11/t-xsd_dateTimeStamp.html
I copy pasted both those literal values suggested into my data property separately :
2004-04-12T13:20:00-05:00
2004-04-12T13:20:00Z
But unfortunately both the hermit and the pellet reasoner whine about an inconsistency there.
Can someone explain to me why this is wrong and provide a valid literal value example that would pass the reasoners ?
I am using the OWLTime ontology and this is the 'in XSD Date-Time-Stamp' data property to be more precise, and the tool I use is protege 5.5.0
Both Data properties are correct, what was needed upon insertion in the box was to select from the drop down type list the "xsd:dateTimeStamp" then the reasoner stopped complaining. Although it is weird because in other custom occasions I did not deal with the same problem
Related
Also posted on super users:
I'm a spotfire novice trying to create a parameterized info link. Ultimate goal is to create a default template that may be customized to return specific rows in a very large table. I've not been able to cobble together enough information from online searches to get me from point A to Z.
Spotfire version is 7.11 on an Oracle 11.2 SE DB.
Currently I've got a date/time prompt in the info link that will be global to all users. What I need is to be able to further filter to 1 of 2 columns (one is real, the other a string) in order to minimize loading times. There are 17 other on-demand tables that are related to the main one. Limiting the initial query will greatly speed up performance.
In information designer for the information link, if I edit the SQL in the WHERE and explicitly define the value or string for the column, I get the rows I want. When I try to define it using an input parameter (?ParamName), I either get nothing when I reload or get asked to input a parameter "for testing".
Q1: In the document properties for the analysis, I've been adding in properties that I assume is supposed to get picked up by the query.
- What part do scripts play in passing this variable to the SQL?
- Do I just need to define a value for a property name or include a IronPython script? - If script is required, can I just define the parameter to pass?
Q2: In the info link SQL, what is the correct syntax for defining the parameter variable depending on the type (real v string)? If I use a string, I need to include LIKE in order to pick up the desired rows. If I use a real, is it possible to define it as a list of values?
Thanks in advance.
Though not exactly clear from your description, I think you should be able to accomplish your goals using the "Load on demand" dialog that is accessed either when you add your data table to your analysis, or subsequently using the Data Table Properties>Type of Data>Settings dialog.
Spotfire uses this dialog to dynamically modify your SQL. Thus, you do not need to explicitly include the LIKE statement in your SQL. Spotfire will add it in based on what you define in the On-Demand settings. For example, you could have an Input Field where you type a constraint that will be stored as a Document Property and then refer to that Document Property in your On-Demand settings to control the table loading.
I have a requirement to display a drop down menu for a String type in Hybris Management Console, restricting the value to some specific values.
As suggested in several forums, I tried to create this entry as an enumeration type but characters like '-' are to be allowed in the enumeration values, as this column receives some specific values which comprise of '-'.
How do I solve this issue?
The people advising you probably didn't understand your requirements. As such, an enumeration type is clearly not appropriate in this case. Consider the alternatives. Is there a Map Type available? What other type might allow you to achieve your goal?
Actually, you could use the hybris Enumeration. In hybris Enum Types have a code and a name. The code is the unique representation for this enum and cannot contain a "-". The name however is a localized representation of that value and can include every character your database is able to store. Have a look here:
https://help.hybris.com/6.5.0/hcd/8c895989866910148d6a802f06651702.html
Additionally, hybris enables you to dynamically create new enumeration values, which is kind of nice.
I've found filter_var to be extremely useful in validating and sanitizing user input with PHP, but I've yet to find anything even remotely as convenient in ColdFusion (more specifically, CF8).
Obviously I can hack together something using REReplace, but that would take significantly more time to code up and would be much uglier than using the pre-defined filters available in PHP. Is there a more efficient way or do I just need to bite the bullet?
There are three different options available to you. Since you're attempting to manage user input, I assume you're using forms. isValid most closely mimics your functionality, allowing you to check if a value specified matches either a data type or a regular expression and returns true or false, and includes attributes by default to define a range. It does not support the ability to create a custom 'filter' beyond defining a regular expression however.
The second option would be using cfparam tags on your POST processing page, which allows you to specify the existance of a variable, test against a data type or define a regular expression, and optionally assign a default value if the variable doesn't exist. If you attempt to process a page where the field is not defined and no default value is assigned however, ColdFusion throws an error.
Finally, you can do validation by using cfform and cfinput fields on your form itself; which allows for client-side data validation for existence and types (it also supports server-side validation but it's implementation is sloppy), regular expressions, and input masking: taking user-inputted data and conforming it to a specific format (like adding dashes to phone numbers and zip codes).
I have a Core Data model with a single transformable attribute. I also have this attribute use a custom NSValueTransformer, setup in the model properly.
When I use mogenerator to generate/update my machine and human files, the machine files for the entity containing this attribute always type the attribute to NSObject. In order for Core Data to use my custom value transformer, this type needs to be the type the transformer understands. Right now, I manually do this in the human file by redefining the property with the proper type. This does the job and gets the transformer working. However, I end up with several compile warnings regarding redefinition of the attribute.
One of the more recent releases of mogenerator specified in the release notes that transformable attributes are now supported. However, I haven't found any example syntax to enable this feature.
This should be better documented.
To set your generated attributes's type, select your desired attribute in the modeler and switch to the User Info tab. Then create a new element with a key of attributeValueClassName and a value of whatever you'd like.
Here's a screenshot:
I'm in the middle of trying to copy a custom content type from one web to another. I've googled around and found some examples that use FieldLinks and Fields. I'm kind of lost as to which one to use, since when I get the FieldLinks from my source web, I get 3 fields; while retrieving from Fields only returned me 2 fields... the custom field is missing. I'm pretty darn sure that I've added the fields at the proper level since I did it via the interface. But when retrieving it using code... the numbers just don't add up.
So besides from that strange problem, I want to know what is the difference between FieldLinks and Fields, and when dealing with them in Content Types (programmatically) which one should I use?
Thanks.
SPFields are fields themselves, while SPFieldLinks are references to the fields. This is a good read that will explain things in detail. In general practice, it is safer to use SPFieldLinks when you are working on the actual content type definition. However, I'll give a quick summary here.
Lists and Webs contain the actual fields with field data. A content type, on the other hand, only holds Field Reference, which simply points at the corresponding field in the list or web. This gets a bit confusing, because content types have both an SPFieldLinkCollection and an SPFieldCollection.
The SPFieldLinkCollection is used in the actual definition of the content type, and is what you would want to use in your situation of copying a content type from one web to another. SPFieldLinks correspond to the actual elements in the XML Schema for a content type.
Comparatively, when you call on a content type's SPFieldCollection and retrieve a Field from it, what is actually happening is that the content type is checking the corresponding field reference, and then looking up in the list/web to get the actual field. Basically, think of the SPFieldCollection in the same way a lookup works: it is worthless without both the lookup value and the lookup source.