properly addressing typed literals/plain literals

[GoogleCodeExporter]

range of generic properties is: (owl:Thing U literals) (in DL literals and 
owl:Thing are separated, so I prefer to assert this explicitly)

range of annotation properties is: [as above]

range of datatype properties is: literals

range of object properties is: owl:Thing

Literals can be: plain and typed. Properly refer them accordingly. (remember 
that:

- plain: label+language
- typed:  label+type

Obviously, the range is referred to the generic properties of these main types, 
and it can be restricted in the property description.

Probably, it would be the case to make a specific management for standard owl 
annotation properties. Note that (OWL 1 reference: 
http://www.w3.org/TR/owl-ref/)

"Annotation properties must not be used in property axioms. Thus, in OWL DL one 
cannot define subproperties or domain/range constraints for annotation 
properties."

Though, there are well known informal constraints on annotation properties:

owl:versionInfo    plain literal
rdfs:label         plain literal
rdfs:comment       plain literal
rdfs:seeAlso       URI
rdfs:isDefinedBy   URI

so the idea is: for these properties, hard-wire the informal contraints and let 
them have only this kind of types.

Original issue reported on code.google.com by stell...@info.uniroma2.it on 17 Oct 2010 at 5:25

[GoogleCodeExporter]

In getIndDescription response client need more specification about literal type 
i.e. if it is plain or typed.
In createAndAddPropValue and relateAndAnnotate requests, client need check by 
the server on type of added value (e.g. if range is a literal value xsd:int and 
client send as value the string "one" instead of 1). If type of value it's not 
valid the value will not be added.

Original comment by scarp...@info.uniroma2.it on 11 Nov 2010 at 6:26

[GoogleCodeExporter]

First requests provided:

property:getDomain and property:getRange

so, the info is not added to the general description of an individual for each 
of its properties (too heavy, what happens if a individual description has 50 
properties?), but can be obtained through the above requests, just when the 
user wants to add a value to them (much the same way as it is done with 
getRangeClassesTreeXML when a value is added to an object property).

Another important point is:
if the range is a datatype, then that datatype must be added to the value, 
unless it is: rdf:PlainLiteral, which means the property points to plain 
literals.

if there is no range, then the user should be able to choose whether he wants 
to add a given datatype or just add it as a plain literal (and, in case, 
provide the possibility to add a language tag).

I'm changing now the request for adding values, though the above can already be 
used for UI interaction. More info to come.

Original comment by stell...@info.uniroma2.it on 12 Nov 2010 at 11:58

[GoogleCodeExporter]

I changed the requests for creating and adding values:

consider the following:

in requests:
- createAndAddPropValueRequest
- removePropValueRequest
- addExistingPropValueRequest

whenever applicable, apply the following changes:

- parameter name change: rangeClsQName --> rangeQName

- parameter "type" values change: instead of just "literal", you need to 
specify either "plainLiteral" or "typedLiteral"

now parameters:

instanceQName, propertyQName, value, type

have been put as explicitly mandatory in the http request

Here follows an example of submission of a typed literal:

http://localhost:1979/semantic_turkey/resources/stserver/STServer?service=proper
ty&request=createAndAddPropValue&instanceQName=ArmandoStellato&propertyQName=st_
example:phoneNumber&value=100&type=typedLiteral&rangeQName=xsd:string

Original comment by stell...@info.uniroma2.it on 12 Nov 2010 at 3:41

[GoogleCodeExporter]

all changes above can be found in upload 84.
Here follows a brief algorithm on what to do with different properties:

- object properties:
you already know they point to resources, so pass immediately to the point 
described as: "RESOURCE VALUED ASSERTION"

- generic properties and annotation properties
phase 1: first you must understand what kind of element they point to.
If property is one of the following annotation properties:
owl:versionInfo    plain literal
rdfs:label         plain literal
rdfs:comment       plain literal
rdfs:seeAlso       URI
rdfs:isDefinedBy   URI
you already know the "de facto" type of range (plain literal or URIs, see above 
table)
so u can skip this phase; in all the other cases:
request property:getRange and:
- if range is a datarange (you have the static list in the client), then 
consider the value as a typeliteral, go to: "TYPED LITERAL VALUED ASSERTION"
- if range is rdf:PlainLiteral, consider the value plainLiteral, go to: "PLAIN 
LITERAL VALUED ASSERTION"
- if there is no range, let the user choose what to do (resource or literal, 
and which kind of literal: plain or typed), and then go to one of the three 
sections below :-)

- datatype properties
for sure the value is a literal, though still ask for the range to understand 
if it is a typed literal or a plainliteral. So, it's the same as before, with 
the sole exception that if the range is not available, the user can't choose 
the resource option, but only between typed literal and plain literal

PLAIN LITERAL VALUED ASSERTION:
add the value, and add an optional language tag with the usual lang parameter. 
Specify the type (type parameter) of value as plainLiteral (typedLiteral)

TYPED LITERAL VALUED ASSERTION:
if u received a range which is a datatpye: use that range you received for this 
property to pass it as the value of rangeQName parameter (which is now used for 
typed literals too, with this semantics, while it is still being used for 
properties pointing to resources for deriving their getRangeClassesTree)
otherwise, let the user choose the range from the list of datatypes (use one 
single method to produce this list, maybe in the future we will change how to 
produce this list, for the moment this is a static list available from the 
client)

RESOURCE VALUED ASSERTION:
request getRangeClassesTree and do the same as in the past version for object 
properties

one final remark, try not to ko the user with lot of questions and make the UI 
as smart and usable as possible

Original comment by stell...@info.uniroma2.it on 12 Nov 2010 at 4:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

modification to :
- generic properties and annotation properties
...<"famous" annotation properties part>...
in all the other cases:
request property:getRange and:
- if range is a datarange (such as xsd:string...you have the static list in the 
client), then consider the value as a typeliteral, go to: "TYPED LITERAL VALUED 
ASSERTION"
- if range is rdf:PlainLiteral, consider the value plainLiteral, go to: "PLAIN 
LITERAL VALUED ASSERTION"
- if range is owl:DataRange then invoke the proper service for getting the list 
of literals in the owl:DataRange
  - if range is a (any) resource (but not a datarange) then apply the RESOURCE VALUED ASSERTION
- if there is no range, let the user choose what to do (resource or literal, 
and which kind of literal: plain or typed), and then go to one of the three 
sections below :-)

Original comment by stell...@info.uniroma2.it on 23 Nov 2010 at 10:02

[GoogleCodeExporter]

Original comment by stell...@info.uniroma2.it on 23 Dec 2010 at 6:16

• Changed state: Fixed