Time Ontology in OWL
Jerry R. Hobbs and Feng Pan, W3C Working Draft
Members of W3C's Semantic Web Best Practices and Deployment Working Group have released the First Public Working Draft for "Time Ontology in OWL." The document presents an ontology of temporal concepts, OWL-Time (formerly DAML-Time), for describing the temporal content of Web pages and the temporal properties of Web services.
The ontology provides a vocabulary for expressing facts about topological relations
among instants and intervals, together with information about durations, and about datetime information. It also demonstrates in detail, using the Congo.com and Bravo Air examples from OWL-S, how this time ontology can be used to support OWL-S, including use cases for defining input parameters and (conditional) output parameters.
A use case for meeting scheduling is also shown. In the appendix we also describe a time zone resource in OWL we developed for not only the US but also the entire
world, including the time zone ontology, the US time zone instances,
and the world time zone instances.
http://www.w3.org/TR/2006/WD-owl-time-20060927/
See also the W3C news item: http://www.w3.org/News/2006#item172
Tuesday, October 10, 2006
Time Ontology in OWL
Friday, August 18, 2006
XML Pipelining for Mathematical Computation
.....
XML Pipelining for Mathematical Computation
R. Alexander Milowski
Exposing a single computation on the Internet via a web service can be challenging. To do so, the input and output of such a service needs to be codified, typically in an XML Schema, and code needs to be written to translate to and from XML. Further, computations need to be interfaced and run with their results formulated into XML. To complicate matters further, there is the whole process of packaging such a system for deployment of some web services platform.
While many web services frameworks focus on the interfaces, what is at the core of exposing a web service is the processing of an XML vocabulary (the request elements). Each vocabulary is associated with a set of actions--implicitly or explicitly--to make a wanted computation to take place. Unfortunately, XML isn't always that simple to process and usually this involves writing a "pile of code". This forces the development of web services to be only in the domain of the expert programmer and not that of a Research Mathematician.....
great content....
XML Pipelining for Mathematical Computation
R. Alexander Milowski
Exposing a single computation on the Internet via a web service can be challenging. To do so, the input and output of such a service needs to be codified, typically in an XML Schema, and code needs to be written to translate to and from XML. Further, computations need to be interfaced and run with their results formulated into XML. To complicate matters further, there is the whole process of packaging such a system for deployment of some web services platform.
While many web services frameworks focus on the interfaces, what is at the core of exposing a web service is the processing of an XML vocabulary (the request elements). Each vocabulary is associated with a set of actions--implicitly or explicitly--to make a wanted computation to take place. Unfortunately, XML isn't always that simple to process and usually this involves writing a "pile of code". This forces the development of web services to be only in the domain of the expert programmer and not that of a Research Mathematician.....
great content....
Monday, August 14, 2006
SEDA
stumbled upon
SEDA: An Architecture for Highly Concurrent Server Applications. at least the paper section contains must read content if you think about scalable application server infrastructure.
SEDA: An Architecture for Highly Concurrent Server Applications. at least the paper section contains must read content if you think about scalable application server infrastructure.
Sunday, June 11, 2006
Technical Context and Cultural Consequences of XML
very interessting article from "IBM Systems Journal (Volume 45, Number 2, 2006)" in the context of "Celebrating 10 Years of XML".
read: http://www.research.ibm.com/journal/sj/452/adler.html
read: http://www.research.ibm.com/journal/sj/452/adler.html
Saturday, May 27, 2006
XProc / xml piplining / xml interop
the main drawback of xml processing / "xml pipelining" is the lack of any standardisation in this area.
there are already lots of implementation out there (see http://norman.walsh.name/2005/10/27/xmlProcModel) but most of them are more or less spike solutions or vendor driven island.
in my point of view the most interessting approach is XPL (http://www.w3.org/Submission/2005/SUBM-xpl-20050411/). reference implementation is available within orbeon presentation server (www.orbeon.com). not worth to take a look at.....
i wonder what does slow down the process of standardisation? main reason is that this topic is somehow underestimated. as already mentioned it covers the missing piece of the puzzel xml interop.
there are many useful xml processing standards already available:
- xslt (http://www.w3.org/Style/XSL/)
- XQuery (http://www.w3.org/TR/xquery/)
- XUpdate (http://www.smb-tec.com/xmldb/xupdate/index.html)
- DOM (http://www.w3.org/DOM/)/ SAX (http://de.wikipedia.org/wiki/Simple_API_for_XML) and corresponding implementations in several programming languages
- WSDL (http://www.w3.org/TR/wsdl)
- ....
but there is no standard describing the orchestra of these components. because each of those standards are functional components must be assambled to get a application.
thus leads to many different approaches to build up xml based applications, each of them are less more or less sufficient but non of them can be exchanged with each other or in other words non platform can extend an application developed based on a different platform.
xml pipelining can break down this limitation using same approach as unix pipes provides for bytes streams but on a higher level of abstraction (means xml provides more semantic than byte stream provides).
hopefully XProc succeed in terms of time and penetration....
alex
there are already lots of implementation out there (see http://norman.walsh.name/2005/10/27/xmlProcModel) but most of them are more or less spike solutions or vendor driven island.
in my point of view the most interessting approach is XPL (http://www.w3.org/Submission/2005/SUBM-xpl-20050411/). reference implementation is available within orbeon presentation server (www.orbeon.com). not worth to take a look at.....
i wonder what does slow down the process of standardisation? main reason is that this topic is somehow underestimated. as already mentioned it covers the missing piece of the puzzel xml interop.
there are many useful xml processing standards already available:
- xslt (http://www.w3.org/Style/XSL/)
- XQuery (http://www.w3.org/TR/xquery/)
- XUpdate (http://www.smb-tec.com/xmldb/xupdate/index.html)
- DOM (http://www.w3.org/DOM/)/ SAX (http://de.wikipedia.org/wiki/Simple_API_for_XML) and corresponding implementations in several programming languages
- WSDL (http://www.w3.org/TR/wsdl)
- ....
but there is no standard describing the orchestra of these components. because each of those standards are functional components must be assambled to get a application.
thus leads to many different approaches to build up xml based applications, each of them are less more or less sufficient but non of them can be exchanged with each other or in other words non platform can extend an application developed based on a different platform.
xml pipelining can break down this limitation using same approach as unix pipes provides for bytes streams but on a higher level of abstraction (means xml provides more semantic than byte stream provides).
hopefully XProc succeed in terms of time and penetration....
alex
Tuesday, May 16, 2006
Process Management System
today is stumble accross INTALIO and their Process Management System (bpms) through a post in Orbeon mailing list.
they relaunching their product suite as open source contribution which not worth to take a look into if you talking about buisness integration.
as assigned on their web side they implemented WS-BPEL 2.0 and BPEL4WS 1.1.
new platform (especially the open source edition) currently just announced but i'm very curious about the outcoming.....
alex
they relaunching their product suite as open source contribution which not worth to take a look into if you talking about buisness integration.
as assigned on their web side they implemented WS-BPEL 2.0 and BPEL4WS 1.1.
new platform (especially the open source edition) currently just announced but i'm very curious about the outcoming.....
alex
Monday, May 15, 2006
TRENT: definition
what does TRENT reallly means. TRansform conTENT into value. nice marketing slang ..... but if you have to deal with information processing that is the main goal your are faced with.
content creation, content storage, content retrieval, content publishing but its all about the value the content provides to a particular actor.
content more general can be specified as an information object valid in a certain context. to be more concrete this means that a given word / information object "red" is only content if it is assigned as a property to a object "car" which specifies the context of this object.
to standardise content processing XML must be considered as a conceptional abstruction to describe and access information objects. XML provides a unique and reusable way how to process / access content.
therefore TRENT is all about XML processing or technology derived / extent XML processing technologies.
because information processing also means to orchestra more than one certain operation on the content you also have to think about an conceptional solution for assembly many dedicated processing calls to information objects.
thus problems can be addressed with well-known pipelining approach which in our case ends up in xml pipelining approach.
thus means
- TRENT is all about transformation of content
- transformation of content is all about pipelining
- content is all about XML
- TRENT is all about XML processing using xml pipelining
Alex
content creation, content storage, content retrieval, content publishing but its all about the value the content provides to a particular actor.
content more general can be specified as an information object valid in a certain context. to be more concrete this means that a given word / information object "red" is only content if it is assigned as a property to a object "car" which specifies the context of this object.
to standardise content processing XML must be considered as a conceptional abstruction to describe and access information objects. XML provides a unique and reusable way how to process / access content.
therefore TRENT is all about XML processing or technology derived / extent XML processing technologies.
because information processing also means to orchestra more than one certain operation on the content you also have to think about an conceptional solution for assembly many dedicated processing calls to information objects.
thus problems can be addressed with well-known pipelining approach which in our case ends up in xml pipelining approach.
thus means
- TRENT is all about transformation of content
- transformation of content is all about pipelining
- content is all about XML
- TRENT is all about XML processing using xml pipelining
Alex
Subscribe to:
Posts (Atom)