[seek-kr-sms] datatypes support in growl ???

Ferdinando Villa ferdinando.villa at uvm.edu
Fri Aug 6 08:58:05 PDT 2004


I guess RDF typed literals are the gate to extensibility, allowing, e.g.
to support GIS WKT shapes as literals in ontologies - and I also guess
that it would be bad not to have support for these in GrOWL, but of
course the urgency of that should be the decision of whoever is using
and developing ontologies right now. And their use in our eventual
reasoning platform, as noted before, depends on non-trivial extensions.

On Fri, 2004-08-06 at 11:47, Shawn Bowers wrote:
> Here is the text on OWL-DL and datatypes:
> 
> http://www.w3.org/TR/2004/REC-owl-guide-20040210/#Datatypes1
> 
> I guess I don't understand exactly what you mean that ultimately it 
> depends on Kepler, and the datatypes needed in Kepler ... what are you 
> thinking on that?
> 
> shawn
> 
> 
> 
> 
> Serguei Krivov wrote:
> 
> > Hi All,
> > Rich and I have been discussing the support for datatypes in growl which
> > is related to the question about namespaces. As we all decided erlier,
> > we shall remove namespace field from gui , but we shall d replace it by
> > "concept space" that  will show merely namespace prefix. This would
> > allow distinguishing imported concepts from local ones. For the   the
> > data value node this will be different- since we have a range of
> > datatypes, we could select them via combo box, rather then mentioning
> > just the namespace.  Apparently all datatypes used in OWL come from XML
> > Schema-datatypes. 
> > 
> > Do we need support all datatypes from XML Schema-datatypes?
> > Do we need support other then XML Schema-datatypes datatypes? 
> > 
> > The way how growl gui will work depends on the answer to these questions
> > and at the moment I do not really know where to use combos and where to
> > use text fields
> > 
> > Rich has provided one answer on this question. Please see the discussion
> > below and comment on it. The final answer should come from Kepler group-
> > what datatypes you need to be supported?
> > 
> > Thanks,
> > Serguei
> > 
> > 
> >> Rich, This in fact a very important thing and I have been confused
> >>about it. Is this true that all data values we have come from
> >>xml-schema? If it is then we need to use uri-base window in a
> > 
> > different
> > 
> >>way for data values and for other things. I think the following.
> >>
> >>1. In both cases it will be combo.
> >>2. For other things then data value combo will contain a list of all
> >>specified namespace prefixes (besides xml-schema)
> >>3. For data values combo will contain a list of xml-schema data types
> >>(we also need to do type check during editing)
> >>
> >>4. From prefix and from label I could create short name. It is
> >>straightforward addition with two exception- (1)When prefix=default
> >>short name is =label (2) when we deal with data value node the
> > 
> > procedure
> > 
> >>is different.
> >>
> >>5. From short name the uri could be created.
> >>
> >>Does this have sense to you?
> >>
> > 
> > 
> > In an abstract sense, data types in OWL don't have to come from
> > xml-schema,
> > but from a practical standpoint they always do.  The type system is
> > independent of the OWL language and so could be anything, but so far all
> > the
> > tools support the built-in xml schema types.  In fact no tools that I've
> > seen even support the full range of extensible/user definable data types
> > allowed by xml schema.
> > 
> > The behavior you describe for data value types makes sense.  For other
> > nodes, there's an issue that we haven't addressed yet, and I think it
> > means
> > that you don't need to worry about having a combo box for the namespace.
> > When working on an ontology with imports, I think it only makes sense to
> > allow the user to edit nodes in the base ontology, not the imports -
> > nodes
> > from imports should be entirely read-only.  Also, when the graph is
> > saved,
> > imported nodes should not be saved (not what currently happens - this is
> > now
> > the top of my todo list!).
> > 
> > I think this means that for non-data value nodes, the Base URI text box
> > (which is becoming the namespace text box) should not be not editable -
> > a
> > node is either created and edited in the current base uri (no namespace
> > prefix) or is imported from another namespace and is not editable.
> > 
> > 
> >>Also please let me know when real uri is created- Is it during saving?
> >>Sorry, I lost track of it.
> > 
> > 
> > When you load from a file, the nodes have URIs, but when you create the
> > node
> > in the editor, it has no URI until it is saved, and the URI is generated
> > on
> > the fly.
> > 
> > 
> >>Thanks,
> >>serguei
> >>
> > 
> > 
> > _______________________________________________
> > seek-kr-sms mailing list
> > seek-kr-sms at ecoinformatics.org
> > http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms
> 
> _______________________________________________
> seek-kr-sms mailing list
> seek-kr-sms at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms
-- 
Ferdinando Villa, Ph.D., Associate Research Professor, Ecoinformatics
Gund Institute for Ecological Economics and Dept of Botany, Univ. of Vermont
http://ecoinformatics.uvm.edu




More information about the Seek-kr-sms mailing list