I'm using OWL API 4.1. I add annotation with type XSD:string like that:
OWLAnnotationProperty annotationProperty = this.getDf().getOWLAnnotationProperty(annotationPropertyIri);
OWLLiteral lit = this.df.getOWLLiteral(annotationValue, range);
OWLAnnotation annotation = df.getOWLAnnotation(annotationProperty, lit);
this.getMng().applyChange(new AddOntologyAnnotation(this.getOnt(), annotation));
... I checked that here lit="test"^^xsd:string. But after I saved ontology (in ttl format) - there in no type ending - ^^xsd:string:
...
<http://semanticweb.rocks/whole-dataset-name/wheat-02> a owl:Ontology ;
dc:description """test""" ;
dc:source """http://mail.ru"""^^xsd:anyURI .
...
If I use other type (e.g. xsd:anyURI ) instead of ^^xsd:string the ending ^^xsd:anyURI is presented.
What is matter with ^^xsd:string?
The xsd:string type can be skipped for string literals, when there is no language tag. A literal typed with xsd:string is identical to a plain literal with no language tag.
If you load the ontology back into an OWLOntology, I expect you to see a test^^xsd:string literal attached to the ontology.
Related
I have in my database a set of records that concentrates information about my .W's, e.g. window name, parent directory, file name, procedure type (for internal treatments purposes), used to build my main menu. With this data I'm developing a new start procedure for the ERP that I maintain and using the opportunity in order to rewrite some really outdated functions and programs and implement new functionalities. Until now, I hadn't any problems but when I started to develop the .P procedure which will check the database register of a program that was called from the menu of this new start procedure - to check if it needs to receive fixed parameters to be run and its data types - I found a problem that I can't figure out a solution.
In this table, I have stored in one of the fields the parameters needed by the program, each with his correspondent data type. The problem is on how to pass different data types to procedures based only on the stored data. I tried to pre-convert data using a CASE clause and an include to check the parameter field for correct parameter sending but the include doesn't work as I've expected.
My database field is stored as this:
Description | DATATYPE | Content
I've declared some variables and converted properly the stored data into their correct datatype vars.
DEF VAR c-param-exec AS CHAR NO-UNDO EXTENT 9 INIT ?.
DEF VAR i-param-exec AS INT NO-UNDO EXTENT 9 INIT ?.
DEF VAR de-param-exec AS DEC NO-UNDO EXTENT 9 INIT ?.
DEF VAR da-param-exec AS DATE NO-UNDO EXTENT 9 INIT ?.
DEF VAR l-param-exec AS LOG NO-UNDO EXTENT 9 INIT ?.
DEF VAR i-count AS INT NO-UNDO.
blk-count:
DO i-count = 0 TO 8:
IF TRIM(programa.parametro[i-count]) = '' THEN
LEAVE blk-count.
i-count = i-count + 1.
CASE ENTRY(2,programa.parametro[i-count],CHR(1)):
WHEN 'CHARACTER' THEN
c-param-exec[i-count] = ENTRY(3,programa.parametro[i-count],CHR(1)).
WHEN 'INTEGER' THEN
i-param-exec[i-count] = INT(ENTRY(3,programa.parametro[i-count],CHR(1))).
WHEN 'DECIMAL' THEN
de-param-exec[i-count] = DEC(ENTRY(3,programa.parametro[i-count],CHR(1))).
WHEN 'DATE' THEN
da-param-exec[i-count] = DATE(ENTRY(3,programa.parametro[i-count],CHR(1))).
WHEN 'LOGICAL' THEN
l-param-exec[i-count] = (ENTRY(3,programa.parametro[i-count],CHR(1)) = 'yes').
OTHERWISE
c-param-exec[i-count] = ENTRY(3,programa.parametro[i-count],CHR(1)).
END CASE.
END.
Then I tried to run the program using an include to pass parameters (in this example, the program have 3 INPUT parameters).
RUN VALUE(c-prog-exec) ({util\abrePrograma.i 1},
{util\abrePrograma.i 2},
{util\abrePrograma.i 3}).
Here is my abrePrograma.i
/* abrePrograma.i */
(IF ENTRY(2,programa.parametro[{1}],CHR(1)) = 'CHARACTER' THEN c-param-exec[{1}] ELSE
IF ENTRY(2,programa.parametro[{1}],CHR(1)) = 'INTEGER' THEN i-param-exec[{1}] ELSE
IF ENTRY(2,programa.parametro[{1}],CHR(1)) = 'DECIMAL' THEN de-param-exec[{1}] ELSE
IF ENTRY(2,programa.parametro[{1}],CHR(1)) = 'DATE' THEN da-param-exec[{1}] ELSE
IF ENTRY(2,programa.parametro[{1}],CHR(1)) = 'LOGICAL' THEN l-param-exec[{1}] ELSE
c-param-exec[{1}])
If I suppress the 2nd, 3rd, 4th and 5th IF's from the include or use only one data type in all IF's (e.g. only CHAR, only DATE, etc.) the program works properly and executes like a charm but I need to call some old programs, which expects different datatypes in its INPUT parameters and using the programs as described OpenEdge doesn't compile the caller, triggering the error number 223.
---------------------------
Erro (Press HELP to view stack trace)
---------------------------
** Tipos de dados imcompativeis em expressao ou atribuicao. (223)
** Nao entendi a linha 86. (196)
---------------------------
OK Ajuda
---------------------------
Can anyone help me with this ?
Thanks in advance.
Looks as if you're trying to use variable parameter definitions.
Have a look at the "create call" statement in the ABL reference.
http://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dvref/call-object-handle.html#wwconnect_header
Sample from the documentation
DEFINE VARIABLE hCall AS HANDLE NO-UNDO.
CREATE CALL hCall.
/* Invoke hello.p non-persistently */
hCall:CALL-NAME = "hello.p".
/* Sets CALL-TYPE to the default */
hCall:CALL-TYPE = PROCEDURE-CALL-TYPE
hCall:NUM-PARAMETERS = 1.
hCall:SET-PARAMETER(1, "CHARACTER", "INPUT", "HELLO WORLD").
hCall:INVOKE.
/* Clean up */
DELETE OBJECT hCall.
The best way to get to the bottom of those kind of preprocessor related issues is to do a compile with preprocess listing followed by a syntax check on the preprocessed file. Once you know where the error is in the resulting preprocessed file you have to find out which include / define caused the code that won't compile .
In procedure editor
compile source.w preprocess source.pp.
Open source.pp in the procedure editor and do syntax check
look at original source to find include or preprocessor construct that resulted in the code that does not compile.
Okay, I am getting a little bit lost (often happens to me with lots of preprocessors) but am I missing that on the way in and out of the database fields you are storing values as characters, right? So when storing a parameter in the database you have to convert it to Char and on the way out of the database you have convert it back to its correct data-type. To not do it one way or the other would cause a type mismatch.
Also, just thinking out loud (without thinking it all the way through) wonder if using OOABL (Object Oriented ABL) depending on if you Release has it available wouldn't make it easier by defining signatures for the different datatypes and then depending on which type of input or output parameter you call it with, it will use the correct signature and correct conversion method.
Something like:
METHOD PUBLIC VOID storeParam(input cParam as char ):
dbfield = cParam.
RETURN.
END METHOD.
METHOD PUBLIC VOID storeParam(input iParam as int ):
dbfield = string(iParam).
RETURN.
END METHOD.
METHOD PUBLIC VOID storeParam(input dParam as date ):
dbfield = string(dParam).
RETURN.
END METHOD.
just a thought.
I was using mybatis-3.1.1 and there was no issue in the following code.
DAO Implementation
#Override
public ItunesPriorityReportDates getWeeklyPriorityDates(Date reportRunDate){
ItunesPriorityReportDates itunesPriorityReportDates = new ItunesPriorityReportDates();
Map<String,Object> weeklyPriorityDatesParamMap = new HashMap<>();
weeklyPriorityDatesParamMap.put("reportRunDate", reportRunDate);
log.debug("Report Run Date : " + reportRunDate);
this.getItunesAnalysisMapper().getWeeklyPriorityDates(weeklyPriorityDatesParamMap);
itunesPriorityReportDates.setAriaWeekStartDate((Date)weeklyPriorityDatesParamMap.get("ariaWeekStartDate"));
itunesPriorityReportDates.setAriaWeekEndDate((Date)weeklyPriorityDatesParamMap.get("ariaWeekEndDate"));
itunesPriorityReportDates.setitunesAccountPeriodStartDate((Date)weeklyPriorityDatesParamMap.get("itunesAccountPeriodStartDate"));
itunesPriorityReportDates.setitunesAccountPeriodEndDate((Date)weeklyPriorityDatesParamMap.get("itunesAccountPeriodEndDate"));
return itunesPriorityReportDates;
}
Mapper
public ItunesPriorityReportDates getWeeklyPriorityDates(Map<String,Object> weeklyPriorityDatesParamMap);
Mapper XML.
<select id="getWeeklyPriorityDates" parameterType="java.util.HashMap" statementType="CALLABLE">
{CALL external_reporting.itunes_sales.get_weekly_priority_dates(#{reportRunDate mode=IN, jdbcType=DATE},
#{ariaWeekStartDate mode=OUT, jdbcType=DATE},
#{ariaWeekEndDate mode=OUT, jdbcType=DATE},
#{itunesAccountPeriodStartDate mode=OUT, jdbcType=DATE},
#{itunesAccountPeriodEndDate mode=OUT, jdbcType=DATE}
)
}
</select>
After upgrading to mybatis-3.2.5 now it is passing null as DATE to Oracle procedure.
Can you please help me with this? Not sure whether I have to update my mapper XML and include something to tell it to parse correctly.
I am using java.util.Date in java.
Thanks
Chirag
Got solution from Eduardo Macarron (myBatis developer)
I got it. It is an interesting finding. Have a look at the expression you posted.
{reportRunDate mode=IN, jdbcType=DATE},
There is no comma separating the property name and the mode!
What is happening is that 3.0 and 3.1 admitted using an space as a separator, though that was undocumented, untested and at least in my case unknown :)
3.2 parsing code was improved and now it supports a well defined grammar:
Inline parameter expression parser. Supported grammar (simplified):
inline-parameter = (propertyName | expression) oldJdbcType attributes
propertyName = /expression language's property navigation path/
expression = '(' /expression language's expression/ ')'
oldJdbcType = ':' /any valid jdbc type/
attributes = (',' attribute)*
attribute = name '=' value
And the space is not a valid separator (so properties can in fact be called "input date").
This change was unwanted but was introduced in 3.2 one year ago so I am afraid we cannot go back.
I hope you just missed the comma and that was not intentional. Sorry!
I get it on some level, but I have yet to see an example that didn't bring up more questions than answers.
http://rhnh.net/2011/01/31/yaml-tutorial
# Set.new([1,2]).to_yaml
--- !ruby/object:Set
hash:
1: true
2: true
I get that we're declaring a Set tag. I don't get what the subsequent hash mapping has to do with it. Are we declaring a schema? Can someone show me an example with multiple tag declarations?
I've read through the spec: http://yaml.org/spec/1.2/spec.html#id2761292
%TAG ! tag:clarkevans.com,2002:
Is this declaring a schema? Is there something else a parser has to do in order to successfully parse the file? A schema file of some type?
http://www.yaml.org/refcard.html
Tag property: # Usually unspecified.
none : Unspecified tag (automatically resolved by application).
'!' : Non-specific tag (by default, "!!map"/"!!seq"/"!!str").
'!foo' : Primary (by convention, means a local "!foo" tag).
'!!foo' : Secondary (by convention, means "tag:yaml.org,2002:foo").
'!h!foo': Requires "%TAG !h! <prefix>" (and then means "<prefix>foo").
'!<foo>': Verbatim tag (always means "foo").
Why is it relevant to have a primary and secondary tag, and why does a secondary tag refer to a URI? What problem is being solved by having these?
I seem to see a lot of "what they are", and no "why are they there", or "what are they used for".
I don't know a lot about YAML but I'll give it a shot:
Tags are used to denote types. A tag is declared using ! as you have seen from the "refcard" there. The %TAG directive is kind of like declaring a shortcut to a tag.
I'll demonstrate with PyYaml. PyYaml can parse the secondary tag of !!python/object: as an actual python object. The double exclamation mark is a substitution in itself, short for !tag:yaml.org,2002:, which turns the whole expression into !tag:yaml.org,2002:python/object:. This expression is a little unwieldy to be typing out every time we want to create an object, so we give it an alias using the %TAG directive:
%TAG !py! tag:yaml.org,2002:python/object: # declares the tag alias
---
- !py!__main__.MyClass # creates an instance of MyClass
- !!python/object:__main__.MyClass # equivalent with no alias
- !<tag:yaml.org,2002:python/object:__main__.MyClass> # equivalent using primary tag
Nodes are parsed by their default type if you have no tag annotations. The following are equivalent:
- 1: Alex
- !!int "1": !!str "Alex"
Here is a complete Python program using PyYaml demonstrating tag usage:
import yaml
class Entity:
def __init__(self, idNum, components):
self.id = idNum
self.components = components
def __repr__(self):
return "%s(id=%r, components=%r)" % (
self.__class__.__name__, self.id, self.components)
class Component:
def __init__(self, name):
self.name = name
def __repr__(self):
return "%s(name=%r)" % (
self.__class__.__name__, self.name)
text = """
%TAG !py! tag:yaml.org,2002:python/object:__main__.
---
- !py!Component &transform
name: Transform
- !!python/object:__main__.Component &render
name: Render
- !<tag:yaml.org,2002:python/object:__main__.Entity>
id: 123
components: [*transform, *render]
- !<tag:yaml.org,2002:int> "3"
"""
result = yaml.load(text)
More information is available in the spec
Using 2.9.0.1
<b time={None}>Hello</b>
=>
<b >Hello</b>
i.e. there is a space after the b in the starting tag.
This makes no sense from an XML perspective.
Is this "feature" supposed to happen?
Thanks.
It happens because of toString implementation of scala.xml.Elem, to be more specific
in object scala.xml.MetaInf method buildString which looks like following:
def buildString(sb: StringBuilder): StringBuilder = {
sb.append(' ')
toString1(sb)
next.buildString(sb)
}
So it's firstly adds a white space to string representation of element, and only after that appends next attribute, so if an attribute is present as class member but doesn't have any string representation you'll end up with one extra space before closing bracket
Actually, it is allowed. See Extensible Markup Language (XML) 1.0 (Fifth Edition), 3.1 Start-Tags, End-Tags, and Empty-Element Tags. From there:
STag ::= '<' Name (S Attribute)* S? '>'
Where S is whitespace and Attribute is an attribute definition. The same is true for end elements:
ETag ::= '</' Name S? '>'
So this is allowed. Whether or not it's what you want is another thing :-)
I have a custom class module in VBA (Access) that is supposed to handle a large amount of external data. Currently I have two functions Read(name) and Write(name, value) that allows to read and set dynamic properties.
Is there a way to define a more syntactic way to read and write those data? I know that some objects in VBA have a special way of accessing data, for example the RecordSet, which allows to read and set data using myRS!property_name. Is there a way to do exactly the same for custom class modules?
The exclamation mark syntax is used to access members of a Scripting.Dictionary instance(you'll need to add a reference to Microsoft Scripting Runtime through Tools > References first). To use this syntaxyou'll need to be storing the information internally in a dictionary.
The quickest way to use it in a class is to give your class an object variable of type Scripting.Dictionary and set it up as follows:
Option Explicit
Dim d As Scripting.Dictionary
Private Sub Class_Initialize()
Set d = New Scripting.Dictionary
End Sub
Private Sub Class_Terminate()
Set d = Nothing
End Sub
Public Property Get IntData() As Scripting.Dictionary
Set IntData = d
End Property
Now you can access properties using myinstance.IntData!MyProperty = 1... but to get to where you want to be you need to use Charlie Pearson's technique for making IntData the default member for your class.
Once that's done, you can use the following syntax:
Dim m As MyClass
Set m = New MyClass
Debug.Print "Age = " & m!Age ' prints: Age =
m!Age = 27
Debug.Print "Age = " & m!Age ' prints: Age = 27
Set m = Nothing
Okay, thanks to Alain and KyleNZ I have now found a working way to do this, without having a collection or enumerable object below.
Basically, thanks to the name of the ! operator, I found out, that access via the bang/pling operator is equivalent to accessing the default member of an object. If the property Value is the default member of my class module, then there are three equivalent statements to access that property:
obj.Value("param")
obj("param")
obj!param
So to make a short syntax working for a custom class module, all one has to do is to define a default member. For example, I now used the following Value property:
Property Get Value(name As String) As String
Value = SomeLookupInMyXMLDocument(name)
End Property
Property Let Value(name As String, val As String) As String
SetSomeNodeValueInMyXMLDocument(name, val)
End Property
Normally, you could now access that like this:
obj.Value("foo") = "New value"
MsgBox obj.Value("foo")
Now to make that property the default member, you have to add a line to the Property definition:
Attribute Value.VB_UserMemId = 0
So, I end up with this:
Property Get Value(name As String) As String
Attribute Value.VB_UserMemId = 0
Value = SomeLookupInMyXMLDocument(name)
End Property
Property Let Value(name As String, val As String) As String
Attribute Value.VB_UserMemId = 0
SetSomeNodeValueInMyXMLDocument(name, val)
End Property
And after that, this works and equivalent to the code shown above:
obj("foo") = "New value"
MsgBox obj("foo")
' As well as
obj!foo = "New value"
MsgBox obj!foo
' Or for more complex `name` entries (i.e. with invalid identifier symbols)
obj![foo] = "New value"
MsgBox obj![foo]
Note that you have to add the Attribute Value.VB_UserMemId = 0 in some other editor than the VBA editor that ships with Microsoft Office, as that one hides Attribute directives for some reason.. You can easily export the module, open it in notepad, add the directives, and import it back in the VBA editor. As long as you don't change too much with the default member, the directive should not be removed (just make sure you check from time to time in an external editor).
See this other question: Bang Notation and Dot Notation in VBA and MS-Access
The bang operator (!) is shorthand for
accessing members of a Collection or
other enumerable object
If you make your class extend the Collection class in VBA then you should be able to take advantage of those operators. In the following question is an example of a user who extended the collection class:
Extend Collections Class VBA