RE: Smart Literal proposal

Hi,

I read the different references related to interpretation properties and
none of them seems to be satisfactory because none of them propose a
canonical (or normal) form to represent the interpretation properties of
a literal.
Using specific datatypes for each combinaison of datatype and unit of
measure does not allow software to process this information in an
interoperable way. 

I have found three issues in RDF Issue List that are closely related to
my problematic:

http://www.w3.org/2000/03/rdf-tracking/#rdfms-literals-as-resources
http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects
http://www.w3.org/2000/03/rdf-tracking/#rdfs-lang-vocab

In the document,
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Feb/0476.html,
there is the following excerpt below:

------------------------------------------------------------------------
-
18: Issue rdfms-literalsubjects

Should the subjects of RDF statements be allowed to 
be literals?

Propose:

  o  the WG resolves that the current syntaxes (RDF/XML, 
     n-triples, graph syntax) do not allow literals as subjects.

  o the WG notes that it is aware of no reason why literals
    should not be subjects and a future WG with a less 
    restrictive charter may extend the syntaxes to allow
    literals as the subjects of statements.

See:
  http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects

--

The above resolution was updated (one word change from agenda text).

Clarification was asked by DanC whether for any entailments in the
model theory, statements ended up with literal subjects.  DanC's
example was does

 { <age> rdfs:range rdfs:Literal. <bob> <age> "23". }

 entail

 { "23" rdf:type rdfs:Literal }

JanG and PatH responded that no, it would not happen and that there
are guards in the model theory to stop the above case.

---- (end of excerpt) --------------------------------

I disagree with the entailment above because it uses the value of
literal as a subject. I think the entailment should create an anonymous
node.

We would have: 

{ <age> rdfs:range rdfs:Literal. <bob> <age> "23". }

This should entail

{ 
  A1 rdf:type rdfs:Literal, 
  A1 rdf:lexicalForm "23"
} 

or may be 

{ 
  A1 rdf:type rdfs:Literal, 
  A1 rdf:value "23"
} 
(if we want to use rdf:value for representing the lexical form, below I
use rdf:lexicalForm).

where A1 is an b-node !

May be the RDF WG would have come with a different conclusion by
considering this alternative.

By doing so we would have an extensive way to handle interpretation
properties such 

{ <age> rdfs:range rdfs:Literal. <bob> <age> "23" ^^xsd:float }

would entail

{ 
  A1 rdf:type rdfs:Literal, 
  A1 rdf:lexicalForm "23", 
  A1 rdf:datatype &xsd;float 
}

The example I sent before with the uom:


<Road rdf:id="Road1">
  <length gml:uom="urn:opengis:uom:meter"
rdf:datatype="&xsd;float">10</length >
<Road>

Would entail:

{  
    Road1 length A1, 
    A1 rdf:type rdfs:Literal, 
    A1 rdf:lexicalform "10", 
    A1 rdf:datatype &xsd;float; 
    A1 gml:uom urn:opengis:uom:meter 
}

A1 being an anonymous node.

You could use xml:lang the same way. The value of xml:lang may
represented by resource, which could have subclass en-us subclass of en.
Entailement can then occur on the Literal properties too.

For example:

<Person rdf:id=P1>
   <name xml:lang="en-us">Tim</name>
</Person>

The normal (canonical form would become:

{ P1 rdf:type Person, 
  P1 name A1,  
  A1 rdf:type Literal
  A1 rdf:lexicalform "Tim" 
  A1 rdf:datatype  &xsd;string
  A1 xml:lang en-us
}

The language would need to be represented as a Class in order to support
subclass relationship (note that xml:lang has been thrown in RDF without
an explicit representation in RDF model).

<xml:Lang rdf:id="en">
   <iso-name>en</iso-name>
<xml:Lang>

<xml:Lang rdf:id="en-us">
  <iso-name>en-us</iso-name>
  <rdfs:subclassOf rdf:resource="en">
</xml:lang>

This would entail:

{ P1 rdf:type Person, 
  P1 name A1,  
  A1 rdf:type Literal
  A1 rdf:lexicalform=Tim 
  A1 xml:lang en-us
  A1 xml:lang en (entailed on xml:lang) 
)

I think technically it won't be a huge change required in existing RDF
parsers such as Jena to support this extension. The problem is know
whether it is compatible with RDF Model or not. If not, does it make
sense to add this normal form in the model in a future release ?

Cheers

Stephane Fellah
Web Chief Architect
PCI Geomatics


-----Original Message-----
From: charles@w3.org [mailto:charles@w3.org] 
Sent: Sunday, October 24, 2004 6:22 AM
To: Graham Klyne
Cc: Stephane Fellah; www-rdf-interest@w3.org
Subject: Re: Smart Literal proposal


You could just use rdf:datatypes which are defined as being a length in
metres expressed as a "float". See
http://www.w3.org/2001/sw/Europe/200409/geox for some examples of how I
set about doing this.

I asked DanC why he did InterpretationProperties instead and he said it
was because cwm had a bug in handling datatypes. I believe Jena, for
example, has no such problem. I also think they are useful things...

cheers

chaals

>
> Stephane,
>
> (I'm responding to just the first few lines of your message.  I
haven't
> studied your example.  Please ignore if not helpful.  Also, trimmed
reply
> list.)
>
> See also, "interpretation properties":
>    http://www.w3.org/DesignIssues/InterpretationProperties.html
>
> #g
> --
>
> At 16:23 22/10/04 -0400, Stephane Fellah wrote:
>
>>Hi,
>>
>>
>>
>>I am trying currently to qualified literal with more attributes than
>>xml:lang and rdf:datatype.
>>
>>
>>
>>In RDF, there are two three types of literal.
>>
>>
>>
>>* Plain Literal, which consists of a string with an optional attribute
>>xml:lang
>>
>>* Typed Literal, which is a string with rdf:datatype attribute.
>>
>>* XML Literal, which is a literal representing an XML literal.
>>
>>
>>
>>Sometimes, it is necessary to qualified further a typed Literal
without
>>creating a resource. For example, a unit of measure or a codespace
>>(taxonomy) in which the value belongs to (tree name taxonomy for
>> example).
>>The only way to describe these attributes in the current RDF
>>specification, is to create an anonymous resource having these
different
>>properties. This makes the serialization of RDF in XML pretty lengthy
and
>>ugly to read by human.
>>
>>
>>
>>Here an example (in a sloppy syntax, I apologize)
>>
>>
>>
>><Road>
>>
>>    <length>
>>
>>         <value rdf:datatype="&xsd;float">10</value>
>>
>>         <gml:uom rdf:resource="urn:opengis:uom:meter">
>>
>>    <length>
>>
>>    <surfaceType>
>>
>><value>asphalt</value>
>>
>><gml:codespace rdf:resource= urn:ataxonomyofsurfacetype />
>>
>>    </surfaceType>
>>
>><Road>
>>
>>
>>
>>A more elegant way to serialize this would be:
>>
>>
>>
>><Road>
>>
>>       <length gml:uom="urn:opengis:uom:meter"
>> rdf:datatype="&xsd;float">10</length >
>>
>>       <surfaceType  gml:codespace=
>> urn:ataxonomyofsurfacetype >asphalt</surfaceType>
>>
>><Road>
>>
>>
>>Please note that this syntax will bridge some gaps with current XML
>>document syntax defined in XML schema.
>>
>>
>>
>>The problem with this syntax is that RDF parsers such as ARP or Jena,
>>would return an error because no other property attribute can be used
>> with
>>rdf:datatype.
>>
>>
>>
>>In RDFS, a literal is a subclass of Resource, however most of RDF API
>> does
>>not use the same hierarchy. In Jena for example, Literal is subclass
of
>>RDFNode and not Resource. So it does not provide the ability to add
>>additional properties to a literal. However, if we follow the
ontology, I
>>should be able to add either annotation property to Literal or
subclass
>>the class Literal with additional properties (probably would be in OWL
>>Full in this case).
>>
>>
>>
>>If a Literal was a subclass of resource, the former RDF example could
be
>>represented in a canonical way:
>>
>>
>>
>><Road>
>>
>>    <length>
>>
>>         <Literal>
>>
>>            <rdf:datatype rdf:resource="&xsd;float"/> (this is an
>> extension of rdf)
>>
>>            <rdf:lexicalform>10</rdf:lexicalform>  (this is an
extension
>> of rdf)
>>
>>            <gml:uom rdf:resource="urn:opengis:uom:meter"/>
>>
>>         <Literal>
>>
>>    <length>
>>
>><Road>
>>
>>
>>
>>Note that rdf:datatype and rdf:lexicalform does not seem to be defined
in
>>RDFS or RDF, but may be needed to support RDF API.
>>
>>
>>
>>This form would be equivalent to the previous compact example. The
only
>>constraint we would have to the literal interface is to have
properties
>>with resource URI or string values. May be they should be annotation
>>properties. Technically, tuning existing a parser to support this
>>extension would not be a big job. The question is whether this is
valid
>>with RDF semantics or not.
>>
>>Is there any reason why this could not be done ? Does my reasoning
make
>>sense ? Is the proposal acceptable to improve RDF specification? Does
not
>>anyone experiment such an approach ?
>>
>>
>>
>>Best regards
>>
>>
>>
>>Stephane Fellah
>>
>>Web Chief Architect
>>
>>PCI Geomatics, Hull, QC
>>
>>
>>
>>Yahoo! Groups Sponsor
>>ADVERTISEMENT
>>
>>
>>----------
>>Yahoo! Groups Links
>>    * To visit your group on the web, go to:
>>    *
>>
<http://groups.yahoo.com/group/jena-dev/>http://groups.yahoo.com/group/j
ena-dev/
>>
>>    *
>>    * To unsubscribe from this group, send an email to:
>>    *
>>
<mailto:jena-dev-unsubscribe@yahoogroups.com?subject=Unsubscribe>jena-de
v-unsubscribe@yahoogroups.com
>>
>>    *
>>    * Your use of Yahoo! Groups is subject to the
>> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
> ------------
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact
>
>

Received on Monday, 25 October 2004 20:28:48 UTC