- From: Stephane Fellah <fellah@pcigeomatics.com>
- Date: Tue, 26 Oct 2004 14:28:59 -0400
- To: "Graham Klyne" <gk@ninebynine.org>
- Cc: <www-rdf-interest@w3.org>
- Message-ID: <8ED21571324EB145933ACCD22B86AC3607CB4E@bach.ncr.pcigeomatics.com>
Graham,
Thank you for your reply. The Pan/Horrocks paper is not satisfying my
requirements because it is focused mainly on datatypes. My proposal is
going beyond datatypes, because it makes explicit other interpretation
properties. You can add unit of measure or a meaning (semantic) to the
literal (ex: some literal string may have a meaning in a taxonomy ("oak"
in a vegetation taxonomy for example)).
The canonic version of Literal as I described would be able to do this.
My changes does not required to change the RDF Model, it just requires
to change the representation of Literal in RDF API implementation.
Literal is defined as subclass of Resource in RDFS. Existing RDF API can
be extended by adding support of interpretation properties and having
Literal as subclass of Resource, instead of a separate type. In this
way, we could also perform some inferencing and query on literal
interpretation properties.
My suggestion only proposes the addition of a syntactic sugar in RDF/XML
syntax that allows to express interpretation properties as attributes of
DatatypeProperty in a very compact way.
Best regards
Stephane
-----Original Message-----
From: Graham Klyne [mailto:gk@ninebynine.org]
Sent: Tuesday, October 26, 2004 3:34 AM
To: Stephane Fellah
Cc: www-rdf-interest@w3.org
Subject: 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-d
e
>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 18:29:32 UTC