RE: Smart Literal proposal

At 16:28 25/10/04 -0400, Stephane Fellah wrote:
>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.

I believe this is true.

>Using specific datatypes for each combinaison of datatype and unit of
>measure does not allow software to process this information in an
>interoperable way.

Well, it might, per the Pan/Horrocks paper [1] I mentioned in response to 
Chaals.

[1]  Horrocks, I. and J. Pan, "Web Ontology Reasoning with Datatype 
Groups", 
2003.  http://www.cs.man.ac.uk/~horrocks/Publications/download/2003/PaHo03a.pdf

But this is indeed just a proposal.  As yet, we're still a long way from a 
single specification for uniform handling of heterogeneous literal forms.

You go on to ask for changes in software implementations to support 
extensions to the standard...

>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).

You don't appear to be disagreeing with the entailment as described.

What you describe is certainly possible, but it's not how RDF is currently 
defined.  The restrictions noted are specifically w.r.t. literals in 
subject position.  They don't prohibit expression of the same idea in 
different ways, e.g., using (as you suggest) bnodes.

You are free to define a "lexicalForm" property (but not in rdf: 
namespace!) that is entailed in the way you suggest (under your intended 
interpretation for that property), for which (I think) the relevant 
inferences can be expressed using a Jena inference engine rule.  I'm not 
sure if that leads you where you wish to be.

In short, RDF doesn't prevent you from doing what you describe, it just 
doesn't do it all for you (yet).

#g
--

>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
> >
> >

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Tuesday, 26 October 2004 08:29:10 UTC