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/jena-dev/
>>
>>    *
>>    * To unsubscribe from this group, send an email to:
>>    *
>> <mailto:jena-dev-unsubscribe@yahoogroups.com?subject=Unsubscribe>jena-dev-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 08:10:37 UTC