W3C home > Mailing lists > Public > public-owl-comments@w3.org > October 2008

Re: supported datatypes in OWL 2

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Wed, 15 Oct 2008 15:21:18 +0100
Message-Id: <042C6F01-1B61-4345-8D70-B6F9D6C82BE4@cs.man.ac.uk>
To: public-owl-comments@w3.org

Jos,

Actually, if you look at the definition of ID, you'll see that they  
are just certain kinds of strings (from a value space point of view).  
They are nominally typed and some applications trigger off that  
nominal typing (e.g., an id consistency checker).

	http://www.w3.org/TR/xmlschema-2/#ID
	http://www.w3.org/TR/xmlschema-2/#IDREFS

[Definition:]   ID represents the ID attribute type from [XML 1.0  
(Second Edition)]. The ·value space· of ID is the set of all strings  
that ·match· the NCName production in [Namespaces in XML]. The  
·lexical space· of ID is the set of all strings that ·match· the  
NCName production in [Namespaces in XML]. The ·base type· of ID is  
NCName.

[Definition:]   IDREFS represents the IDREFS attribute type from [XML  
1.0 (Second Edition)]. The ·value space· of IDREFS is the set of  
finite, non-zero-length sequences of IDREFs. The ·lexical space· of  
IDREFS is the set of space-separated lists of tokens, of which each  
token is in the ·lexical space· of IDREF. The ·itemType· of IDREFS is  
IDREF.

I'm not sure we want to have lists, but ok. Entities are different:


	http://www.w3.org/TR/xmlschema-2/#ENTITY

[Definition:]   ENTITY represents the ENTITY attribute type from [XML  
1.0 (Second Edition)]. The ·value space· of ENTITY is the set of all  
strings that ·match· the NCName production in [Namespaces in XML] and  
have been declared as an unparsed entity in a document type  
definition. The ·lexical space· of ENTITY is the set of all strings  
that ·match· the NCName production in [Namespaces in XML]. The ·base  
type· of ENTITY is NCName.

Note:  The ·value space· of ENTITY is scoped to a specific instance  
document.

We might be able to handle this by having entities declare their  
corresponding DTD (where each DTD is a type. Hrm. If we presume that  
the general set of DTDs contains at least one DTD with every NCName  
declared as an unparsed entity (a truth, actually), then every NCname  
has been so declared as an unparsed entity in *some* DTD. Ergo, bare  
ENTITY is just another nominal type for NCName.

At the very least we should add clarificatory text.

Of course, I don't see a *huge* benefit to these guys, but I guess I  
could imagine that when scraping from some XML you might pull out a  
set of names and what to be able to represent that. Or if you  
generate xml you might want to distinguish between the NCNames that  
are entities or ids and those not...

Cheers,
Bijan.
Received on Wednesday, 15 October 2008 14:18:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 October 2008 14:18:34 GMT