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

Fri Aug 6 09:19:22 PDT 2004

 It isn't clear to me though that we should be trying to mimic what is
in 
ptolemy ... and instead we should have datatypes that are needed for 
defining ontological information.  Ultimately, it isn't clear to me I 
guess that we want to be representing data *in* the ontology at all, 
other than data that is ontologically descriptive.

Not sure if that makes any sense, though.

shawn

It has sense to me because I think it has sense to use ontologies as
ontologies along with services that they provide. Adding some extra
things could make reasoning undecidable. I was not really sure about
limits of extensibility of owl datatypes. Yet if we are eligible to use
something inside ontologies without going too far to owl-full, then why
not to use that creatively.

serguei

Serguei Krivov wrote:

>  I mean that if growl to be used as editor  for semantic annotations,
> then it is good to know what is needed for semantic annotations. On
the
> other hand if we decided to restrict growl to owl-dl and the dataypes
> recommended for owl-dl are subset of XMLSchema-datatype mentioned in
> this url, then perhaps we should deal just with those subset.
> 
> Serguei 
> 
> 
> -----Original Message-----
> From: seek-kr-sms-admin at ecoinformatics.org
> [mailto:seek-kr-sms-admin at ecoinformatics.org] On Behalf Of Shawn
Bowers
> Sent: Friday, August 06, 2004 11:47 AM
> To: Serguei Krivov
> Cc: seek-kr-sms at ecoinformatics.org
> Subject: Re: [seek-kr-sms] datatypes support in growl ???
> 
> 
> 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

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