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

Serguei Krivov Serguei.Krivov at uvm.edu
Fri Aug 6 09:41:53 PDT 2004


 I think we both are right in a way. In 
http://www.w3.org/TR/rdf-schema/#ch_literal  (see first two subsections)
I found:" Each instance of rdfs:Datatype is a subclass of rdfs:Literal".
This implies that rdfs:Literal is a superclass to all datatypes,
including xsd datatypes. But then
In context of owl dl (uri Shawn have sent 
http://www.w3.org/TR/2004/REC-owl-guide-20040210/#Datatypes1  )
this probably  mean a superclass of all owl-dl SUPPORTED datatypes (???)

serguei


As far as I understand it (which may be very little) rdfs:Literal can be
untyped (strings) or have one or more datatype URIs that can point to
any type with no restrictions - I found some explanation at 
http://jena.sourceforge.net/how-to/typedLiterals.html. Still, counting
on this ecologist's understanding of subtle KR points is never a good
idea.

On Fri, 2004-08-06 at 12:09, Serguei Krivov wrote:
> As I understand it now - rdfs:Literal is just one datatype  and  is
also
> recomende for owl-dl (and so we must support it). As I understand it,
> rdfs:Literal could be a string or a number. Is it that simple? Please
> correct me if I missed any point.
> 
> serguei
> 
> 
> 
> 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

_______________________________________________
seek-kr-sms mailing list
seek-kr-sms at ecoinformatics.org
http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms




More information about the Seek-kr-sms mailing list