Warning:
This wiki has been archived and is now read-only.

Who Reads Our Documents

From OWL
Jump to: navigation, search

Descriptions of examples of readers who would be reading our user facing documents.

Each description should identify somebody who would read one of our documents. Describe what it is expected they know before they read the document, what you hope they would know after reading it, e.g. what actions they would be interested in and able to do with the new information. If you think one of the current documents is of the sort that would accomplish the goals of the person, then say so. These descriptions should be signed - we want to know who in the WG thinks what, since some of the difficulty in deciding what documents produce arise from differing goals and expectations.

Ideally, once we have these descriptions we can

  • Evaluate them together to see whether we agree that these reader descriptions are realistic.
  • Decide together who we think are the set of readers the WG will attempt to address.
  • Periodically refer back to these chosen descriptions to help guide the construction of given documents.
  • Perhaps find actual representatives of these sorts of readers to review our documents and give us feedback about whether the documents work for them.

Someone who wants to know differences between OWL 1.0 and OWL 1.1

  • May be managerial or technical
  • Needs a place to start

(Peter F. Patel-Schneider)

An RDF hacker

  • Can't/won't read formal semantics etc.
  • Understands XML a little or not at all.
  • Understands RDF fairly well.
  • Understands OWL 1.0 a tiny bit.
  • Usual lot of confusions about some of the layering issues - e.g. unclear about use of qnames in RDF.
  • They want to pick out one or two features of OWL 1.1 (maybe subproperty chain) and use that feature without having to understand everything.

(Jeremy Carroll)

A XML hacker

  • Can't/won't read formal semantics etc.
  • Understands XML fairly well.
  • Understands RDF a little or not at all.
  • Usual lot of confusions about some of the layering issues - e.g. unclear about use of qnames in RDF.
  • Wants an easy to read intro, with examples to copy and paste.
  • They want to pick out one or two features of OWL 1.1 (maybe subproperty chain) and use that feature without having to understand everything.

(Jeremy Carroll)

Scientific Database Leadership

SR is PI or co-PI on grants from the NIH that, all-told, total several tens of millions of dollars. One of SR's projects involves gathering and integrating data from many laboratories funded by the NIH, in one area of biomedicine. Although familiar with the construction of ontologies, SR wants to figure out how he might exploit ontologies to better work with his data, and understand how OWL can fit in to the picture. As much of the managed data is currently maintained in relational databases, examples that show how to use OWL in conjunction with databases, or to migrate from databases would be particularly helpful. SR needs an overview of what sorts of things one can do with OWL, as well as an overview of the technology so that a decision can be made as to whether it seems like it is worth evaluating. If the decision is yes, SR must have understood enough so that people in the organization can be found that might be suited to doing that evaluation and can be directed towards what they should be reading in order learn more about OWL. (Alan Ruttenberg)

Previous User

A previous user who has come to rely on the OWL 1.0 documents. They may be working with limited resources and may be associated with a project that used OWL 1.0 and is deployed. They may be looking to see if OWL 1.1 is ready for them to switch to. They would like to use their previous methodology for doing the update and thus would like to have the documents they previously relied on for their previous work updated before doing the update. They also need to assure their management that the cutover will not be more costly than it needs to be and that the cutover is worth the cost of the update. There are a number of application developers who have mentioned that they rely on the Overview for its feature list, examples, and hyperlinking, the Guide for examples, and the reference for technical but informal details. To minimize the fear that OWL 1.1 is significantly different, and thus requires a significant learning curve, it may be beneficial to provide some continuity in the document transition. For example, the simple examples in the overview for 1.0 can be maintained where simple examples are desired in the 1.1 docs. (Deborah McGuinness)

Earth and Space Science Researcher

A scientist who is interested in using semantic technologies to perform information integraton. They may have heard that OWL can be used to represent their information. They are looking for a quick overview of what OWL is and (initially) simple examples of how it can be used for information integration. They may be additionally looking to see who may have already used it successfully in a related area. Some of these users are already using OWL and have come to depend upon certain documents as part of their design and maintenance process.(Deborah McGuinness)

Skeptical Potential User

A potential user who knows something about XML and RDF. They have information integration needs. Because of project timeline demands, they are pre-disposed to not take on new technology unless it is required. They are looking to see if OWL is worth the effort to adopt. Potentially valuable documentation would be a (new) document providing examples of how OWL adds benefit over what can be done with RDF(S) and XML. (Deborah McGuinness)

Database Federation Engineer

RN has been building a database federation scheme. The scheme involves designing an XML schema that describes the fields and values in a variety of databases, and associated query tools that, from a query interface, can write queries (in several variants of SQL) to databases that have relevant information. Those results are presented as a single integrated view . He hears that OWL and Semantic Web technologies might be a suitable technology for implementing the same functionality and making it available using Web standards, but doesn't know where to start. (Alan Ruttenberg)

(From the XQuery Page [1]) 30,000 Foot View, CIO, CTO, Journalist

What does OWL 1.1 do? Does it apply to web pages? web data? relational data? Where in the Enterprise Architecture stack does it belong? If I adopt OWL 1.1, what software components will I be able to replace? Is it a query language? How is it different from XQuery and SQL? Does it belong to the business logic layer? How is it different from Production Rules Engines? Does using OWL 1.1 simplify application software complexity and enable easier maintenance of application software? (Vipul Kashyap)

(From the XQuery Page [1]) Systems Analyst or Architect

How can OWL 1.1 help in Data Integration? Can it be used to seamlessly integrate data from different sources stored using different formats and models such as XML, relational databases, RDF? When should I use OWL 1.1 over SQL/XQuery for a data integration task? How can OWL 1.1 be used on the back end of a web server to generate reports? How can I use OWL 1.1 to enable real time decision support in the enterprise and why is it better than other statistical/probabilistic/neural network techniques on one hand and production rules systems on the other? How can OWL 1.1 supported reasoning classification, subsumption, etc. help me where query processing specifications such as XQuery and SPARQL cannot? (Vipul Kashyap)

(From the XQuery Page [1]) Users: Choosing an Implementation

There are likely to be multiple implementations of OWL 1.1 based reasoners, both stand alone and integrated with query processors such as SPARQL. Guidance on support model, platforms supported, price and performance (Vipul Kashyap)

(From the XQuery Page [1]) Implementors

These are typical things an implementors would need such as Test Suite, Formal Semantics and Inference, Conformance Statements and other documents (Vipul Kashyap)

Biomedical Informatician

A biomedical informatician would like to create an ontology that helps in clinical decision support at the point of care. I would like to re-use pre-existing controlled vocabularies such as Snomed, Foundational Model of Anatomy, etc. to be able to characterize some clinical phenomena such as location of fractures in various parts of the bones. The critical issue is that the clinical viewpoint is different from the anatomical (FOMA) and pathology (Snomed). How can OWL 1.1 help me in this regard. In particular, the challenges are pre-existing vocabularies that are not represented in OWL and are under-specified leading to multiple OWL encodings of the same set of knowledge. How can OWL 1.1 help me in this regards? (Vipul Kashyap)

Information Modeler/Information Architect

As an Information Modeler/Architect, I am charged with developing a set of Enterprise Information Models, that would form components of an Information Architecture underlying the SOA based system architecture. The key benefits of these Enterprise Information Models is that they "standardize definitions" across the enterprise and provide the basis for information interoperability across multiple enterprise services and applications. Some key benefits that accrue from a robust information architecture layer, is the minimization of transformation operations between enterprise models and local application specific data/implementation models, flexibility of enterprise information systems. How can OWL 1.1 support these objectives and what are the associated best practices in doing so. (Vipul Kashyap)

The typical MDA (Model Driven Architecture) practitioner falls under this heading. MDA practitioners tend to be senior software architects within an organization, charged with developing an integrated set of platform-independent models of an application or system's business functionality and behavior, so that they can be reused across a variety of implementation platforms. Recent developments in semantically-enabled software engineering demonstrate the benefit of modeling the business vocabularies (and/or ontologies) relevant for a particular domain independently from the software and rules development, and reusing the same consistent vocabulary across multiple applications or services. See workshop proceedings from ISWC 2005 (Workshop on Semantic Web Enabled Software Engineering (SWESE)), ISWC 2006 (2nd International Workshop on Semantic Web Enabled Software Engineering (SWESE 2006)), and ESWC 2007 (3rd International Workshop on Semantic Web Enabled Software Engineering (SWESE 2007)) for papers on relevant work. We have found that practitioners typically refer to the OWL Reference Manual to answer most questions they have when developing applications, and only use the abstract syntax and semantics documents to confirm what they thought they knew, or for deeper understanding when needed. They also look at the Overview document (and sometimes the Guide, though less frequently), for additional examples. ( Elisa Kendall)

Developer who is interested in using OWL

The developer is interested in determining how OWL might help in supporting a supply chain application. The developer has been pointed to Protege as the appropriate to tool to use in building ontologies, but wants non-Protege documentation (perhaps to see what else there is besides Protege or what Protege doesn't do). The developer has problems with the OWL 1.0 documents because they don't speak the same language as Protege. (Peter Patel-Schneider)

A (relatively) non-technical business user

This user is a decision maker in their organization and has a hazy understanding of the distinction between HTML and XML. They have heard about ontologies or the semantic web, perhaps by attending the Semantic Technology Conference. They are interested in the relative advantages of using OWL over other technologies, but don't always have a clear notion of the tasks to which it may be applied to. They need to get a general enough sense of what OWL can do and what strategic advantages using OWL in their organization might bring. They need help distinguishing hype from substance and in translating generalities into their specific situation. Bijan Parsia

Someone like Christopher Rose

Chris first became involved in OWL by way of investigating what higher-level representations might exist for electronic components. ESL, (electronic system-level design), it turns out, is a very domain-specific representation for electronic components, but on finding OWL, Chris is asking what advantages it might have in this domain, both by creating hierarchical classifications and for the potential for machine reasoning.

Chris has an engineering backround which includes programming, particularly in object-oriented and scripting languages. He chose to first model an alpha taxonomy in OWL (the ITIS taxonomy for North America) as a clean, non-trivial example. He is attempting to write a Ruby Gem which will dump a valid OWL file, given as input some particular Ruby objects. He has questions relating to the LRM and what is valid OWL syntax, and also relating to semantic modeling issues. He wishes there were a BNF representation included in the LRM which could be used in developing syntax checkers, parsers, etc.

See Neophyte question - modelling Alpha Taxonomies in RDF and Owl (Initially added by Alan Ruttenberg and then elaborated on, presumably, by Christopher Rose the subject, but not a WG member)

Someone like Hans Teijgeler

See email from Hans Teijgeler (Jim Hendler)

Manufacturing Technical Standards developer

One who has some knowledge of manufacturing systems and processes and develops standard data formats, models, and/or protocols which enable integration or replacement of manufacturing systems. Typically has been or still is a systems integrator, solution provider, system developer, or information modeler/architect. Probably has detailed familiarity with XML, EDI and/or some class of communications middleware. May have knowledge of one or more data modeling (e.g. NIAM/ORM or EXPRESS), object modeling (UML), or schema modeling languages. Probably cannot or will not read formal semantics. Probably is not familiar with RDF. Probably prefers to learn rdf/xml or some other standard syntax for OWL, rather than depend on a particular authoring tool's interface (though he or she will make use of authoring tools). Evan Wallace

Manufacturing Business Standards Developer

One who has knowledge of particular process, activity, and/or system in a manufacturing business. Will know something of the details of data related to that process or system but will likely prefer to use office applications (word processor and/or spreadsheet tool) to capture the information. Probably is not familiar with modeling languages or tools and may be openly hostile to such notations (and RDF and OWL would be outside of his experience or interest). However, in the context of developing consensus standards and with a competent information modeler to capture information and interpret the language for others, such people have come to appreciate a modeling or ontology language as enabling richer shared understanding and more precise agreement on what is being standardized.

(Ultimately, reaching users like this will be important for wide use of OWL in business. It's probably too much of a challenge to ask the "user facing" documents to reach this class of user. However, SBVR is a language being sold with some success to users with similar characteristics for similar uses. This shows that these users can be reached, that there is some urgency to reach them, and that "friendlier" syntaxes might help (though the last is clearly NOT a UFDTF concern). Creating more OWL knowledgeable information modelers (and other technically oriented users) to be catalysts for business types is a goal that the UFDTF can work toward. Evan Wallace

References

[1] http://www.w3.org/XML/Query/