Mathew,
I agree that this is usually the path people take. (01)
Ken,
Thank you for providing these points.
Initially, the goal of the Semantic Web was to make the information on
the web machine-readable. Annotating text with definitions in
sub-ontologies plays a major role in that, and Linked Data is suppose
to link all these definitions together. One can certainly view each
definition (or definitions within a single system) as a sub-ontology,
and by linking them you get one broader upper ontology. The
definitions and links evolve over time, with various degree of version
control and documentation. Keeping all this working is difficult, but
the list you provided covers the pitfalls and solutions well. (02)
Regarding Frank's post on the W3C forum, the conversation continued in
the last few days. See the continued thread here, starting with
Michael Uschold's comment:
http://lists.w3.org/Archives/Public/semantic-web/2011Oct/0000.html (03)
I also asked Frank directly. (04)
My impression is that two key factors played a role. (05)
1) It was simply easier to build a custom SOA ontology than use a
standard one and customize it to fit the existing process. (06)
2) This transition was to be done over several years (it took 4), and
in carefully conducted increments. This is why flexibility was
particularly important. (07)
I think that if someone was starting from scratch, it would be
beneficial to use an existing SOA ontology, at least as a starting
point. The ability to develop it over time and adopt it to evolving
needs would be a key requirement. One thing that would be lost is the
consistency with the original, unless there was a specific need to
keep it consistent. (08)
In this case, what would encourage someone to keep the consistency? (09)
Perhaps instead of requiring someone to adopt the whole ontology,
allow them to just use a sub-ontology that fits their specific need.
To address one of Ken's point, a description should only be as concise
as absolutely needed. Too strict of a definition may discourage
someone from adopting it, opting for creating a new one that fits
their use case better. (010)
A "general" version of a definition may also be an option. This
"general" definition would map to different definitions defined by
context. (011)
Using Michael Uschold's examples from the W3C thread here:
http://lists.w3.org/Archives/Public/semantic-web/2011Oct/0023.html
[quote]
If you need alternative interpretations then create them. If you don't know
whether a hospital is:
1. the building that health care is provided in
2. the legal organization that owns the building
3. the legal entity that has a number of beds registered for a specific kind
of medical services (012)
Then create three different things with three different names and define
them accurately.
[end quote] (013)
Having these definitions to choose from in standard ontology would be
great, but someone has to define them first. Otherwise a mechanism for
easily extending the original for others to use would be required. (014)
On 2 October 2011 11:44, Ken Laskey <klaskey@xxxxxxxxx> wrote:
> If I recall, the original idea for the Semantic Web was not all-inclusive
> ontologies but a collection of small ontologies that described specialized
> aspects of the world. I think that is what Frank Carvalho has documented.
> It is also very consistent with the work we have done in service
> description. Our guiding assumptions are the following:
> . There is no one "right" description for all time. Any template for
> describing any resource is a snapshot in time.
> . There is no single "right" description to satisfy all stakeholders.
> There will be an overlap in what various stakeholders find important but
> each stakeholder group is likely to have unique interests. Segregating
> portions of description and allocating specific segments to specific
> stakeholder groups will result in duplication and unreasonable constraints
> on the use of available description.
> . Different stakeholders may associate different values to a
> descriptive property, where the values are concurrently valid. For example,
> someone concerned with an OMB (Office of Management and Budget) form A300
> will choose values for business functionality from the Federal Enterprise
> Architecture (FEA) Reference Models whereas someone with expertise in the
> discipline associated with the functionality will find a precise technical
> term more useful.
> . There is likely no unique use for any element of description.
> Different stakeholder groups will use descriptive information in different
> ways for purposes they find relevant. For example, the concept of zip codes
> was created by the Post Office to streamline mail delivery but is now a key
> for store locators for businesses, locale indicators for weather, "chip"
> identifiers for map segments.
> . Providers and consumers of description must use the same
> vocabularies or have ways to mediate among vocabularies if relevant matches
> are to be accurately identified. Thus, it is necessary to unambiguously
> declare the semantics being used. This applies to both the properties used
> for description and the values assigned to the properties. If the values
> are numeric, it is necessary to unambiguously indicate the units of measure.
> . Description elements and values should be reusable across classes of
> resources. For example, color can be an element of description for any
> resource where the idea of color applies, and the value red should be
> equally applicable across resource classes. Value definitions may be
> prescribed through well-documented taxonomies or other collections of terms
> and relationships.
> . Description should be concise. Long text passages are difficult to
> check for exact matches and are difficult to keep synchronized across
> multiple descriptions if a change is introduced as part of some use. A URI
> used to indicate retrievable text is easy to compare and multiple uses of
> the same URI remain synchronized if the retrievable text changes.
> . There will always be a legacy collection of descriptions based on
> previous versions of descriptive property sets and previous versions of
> description values. The more success we have in getting descriptions created
> today means more legacy to accommodate future change.
>
> The net effect of applying these principles is we can consistently describe
> numerous resource classes using common tools, can generate new description
> property sets leveraging what we learned from existing ones, and evolve
> quickly and consistently as our experience grows.
>
> Remember, the best standards are not necessarily the ones that exactly
> specify what you can do and how you should do it. Rather, the most enabling
> standards nail down a consistent way to express and use variations that were
> not conceived when the standard was first developed.
>
> Ken
>
> ---------------------------------------------------------------------------
> Dr. Kenneth Laskey
> MITRE Corporation, M/S H305 phone: 703-983-7934
> 7515 Colshire Drive fax:
> 703-983-1379
> McLean VA 22102-7508
>
>
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
> [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Bart
> Gajderowicz
> Sent: Thursday, September 29, 2011 2:39 PM
> To: [ontolog-forum]
> Subject: [ontolog-forum] SOA organised with RDF - Use Case
>
> I thought this post from Frank Carvalho was interesting as an
> application of ontologies to keep dynamic data and metadata organized.
>
> http://lists.w3.org/Archives/Public/semantic-web/2011Sep/0167.html
>
> It's only RDF, but I find it interesting that a standard SOA ontology
> is described as a problem. Instead each "type of metainformation has
> its own ontology".
>
> Are standard/upper ontologies only practical for more expressive
> ontology languages?
>
> Is this a unique domain-ontology that simply wouldn't benefit from a
> standard/upper ontology?
>
> --
> Bart Gajderowicz, MSc.
> Ryerson University
> http://www.scs.ryerson.ca/~bgajdero
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>
>
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>
> (015)
--
Bart Gajderowicz, MSc.
Ryerson University
http://www.scs.ryerson.ca/~bgajdero (016)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (017)
|