Re: ISSUE: StructuredDatatypes

>The issue of the handling of structured (e.g complex XML and multimedia)
>datatypes by the Ontology Web Language was raised at the A'dam F2F. I have
>written it up, and given it a URI at
>http://www.openhealth.org/WOWG/IssueStructuredDatatypes
>
>Integrating structured (e.g. XML and multimedia) datatypes into the ontology
>web language falls within the charter and an explicit requirement of the
>Ontology Web Language.
>
>Dan Brickley has posted a terrific (IMHO) summary of the requirement:
>http://lists.w3.org/Archives/Public/public-webont-comments/2002Apr/0004.html
>
>The XML and before that, the SGML, communities have had a long interest in
>the graphical representation and manipulation of structured, including
>multimedia, information, which has been called "Groves" (Graphical
>Representation Of property ValuES) [1,2]. Such representations lead
>themselves naturally as RDF descriptions [3]. It has been the explicit hope
>that an RDF Schema description of the XML Infoset will allow "validation" of
>an RDF/Infoset representation of an XML document [4].
>
>I propose that WebOnt accept this challenge

I second that. That sounds REALLY interesting.

>(my preliminary work suggests
>that we are up to the task). Integrating XML and XML Schema datatypes in
>this fashion will provide a concrete and tangible benefit provided by OWL to
>the XML community, as well as properly allowing OWL to reason about
>structured XML and multimedia datatypes.
>
>RDF Core is developing MT extensions for simple or concrete datatypes. The
>proposal which is outlined below is not a duplication of this effort, rather
>directed at complex or structured datatypes. I will discuss why the approach
>taken by RDF Datatypes, while perfectly reasonable for concrete datatypes,
>cannot be directly extended to structured datatypes, primarily due to some
>technical details with respect to XML Schema.

It might be worth summarizing the technical assumptions made by the 
RDF datatyping proposal (which is now archived in a draft form and 
will be released soon). They are fairly minimal.

1. A datatype defines two RE domains (one of lexical forms, and one 
of datatype values) and a functional (many-to-one) computable mapping 
from the former to the latter.  It might also define a canonical 
(1:1) mapping and a canonical lexical space, but that is not required.

(The RDF MT extension provides ways to refer to the value space and 
the mapping, and to associate datatypes with literals so as to invoke 
lexical checks and/or to require that certain graph nodes denote 
datatype values.)

2. A datatype is identifiable by a uriref in some way that can be 
globally determined, and such urirefs can be recognized as being 
those that identify a datatype. (The exact mechanism is considered to 
be external to RDF and is not specified. The examples we give use 
qnames like 'xsd:number', but this usage is not intended to be 
definitive.)

Exactly what counts as a lexical form or a datatype value is not 
specified, but there is an implicit assumption that the lexical space 
of the datatype at least intersects with the set of RDF literals. 
Although strictly speaking this is not a formal requirement, any 
datatype which fails it couldn't be used to support any meaningful 
RDF entailments, since almost everything you said about it in RDF 
would be false or vacuous. However, if we were to extend the syntax 
so that other media type entities counted as "literals", then this 
scheme would seem to extend smoothly to that more general case. I 
love the idea of a logical language where some of the logical names 
can actually be movies.

Pat


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Wednesday, 17 April 2002 20:25:08 UTC