On 1 Feb 2014, at 17:03, Kingsley Idehen wrote:
On 2/1/14 7:11 AM, David Price wrote:
On 31 Jan 2014, at 20:41,
Kingsley Idehen wrote:
On 1/31/14 12:37 PM, David
Price wrote:
On 31 Jan 2014, at 16:37, Kingsley Idehen wrote:
On 1/31/14 9:43 AM,
David Price wrote:
On 30 Jan 2014, at 14:20, Hans Teijgeler
wrote:
Dear David
and Matthew,
Using a
non-humanreadable string for an ID has
its merits, that are probably not the
first thing you, both English
speaking, would think of. If I refer
to RDS45093 a person whose native
language is not English can refer to a
translation of the skos:prefLabel
(in English) in his/her language, if
provided by their standardization body
or else. If we would start with IDs in
English we would be in deep trouble in
certain regions of the world.
Next to the
ID you can have one skos:prefLabel
per ID and as many skos:altLabels as
you need.
Hi Hans,
For data, artificial URIs are fine. For
classes and properties in an ontology they are
not. Even a non-English speaker will have
better luck distinguishing
PersonOrOrganization vs Organization rather
than RDL94950595 vs RDL9459869 when reviewing
an ontology or writing SPARQL. Adding
properties as labels useful for presentation
in a user interface does nothing wrt the issue
I raise.
Cheers,
David
David,
When describing a property, class, or individual, I
use the following practice:
1. include an rdfs:label relation -- also look to
skos:prefLabel when what's being described has many
known labels (very common in our buzzword laden
world)
2. include an rdfs:comments relation
3. include a dcterms:description relation -- if
rdf:comments doesn't suffice in regards to what's
being described in prose
4. where possible include a foaf:depiction relation.
Using Linked Data based structured data
representation patterns: 1-4 enable HTTP URIs [1],
HTTP URLs [2], and WebIDs [3] that denote whatever I
am describing to remain opaque. Thus, if anyone
needs to know what I am describing they simply
de-refrence the identifiers.
Links:
[1] http://bit.ly/1edQEKp
-- HTTP URI
[2] http://bit.ly/1bHGrQu
-- HTTP URL
[3] http://bit.ly/1elKLcn
-- WebID .
Hi Kingsley,
We use 1-3 regularly along with prefLabel, etc..
However, as I replied to Hans, that does not address
the requirements wrt URIs and there's no reason to
think what works for Linked *Data* works for ontology
classes and properties that are part of an enterprise
app.
Cheers,
David
David,
Being able to de-reference what a term denotes is
universally valuable. What's special about ontologies and
the enterprise? There's nothing about looking-up definitions
of terms via HTTP that's unique to ontologies or
enterprises. It's just data :-)
Hi Kingsley,
Ontology classes and properties in an enterprise app are
quite often *not* just data. As I've said several times, they
are software artefacts that play a very similar role to Java
classes. In these cases, they are an integral part of
high-performance, high availability apps. The enterprise apps
we are delivering have users sitting there waiting for things
to happen in the U/I that performs complex functions, and from
their point of view performance is never good enough.
Dereferencing things for no good reason really means giving
them reasonable performance is next to impossible.
We have a very different perception of the notion of an enterprise.
Actually, not. I have no interest at all in discussing what "enterprise" means.
I'm trying to explain that there are kinds of *apps*, which I have called "enterprise applications", with characteristics that imply specific requirements and rules governing the kind and development of ontologies upon which they are based. I've also suggested that what apparently works in the linked data world is not suitable for these kinds of apps. Nothing more than that ... remember this discussion started because of my requirement for human readable URIs.
Cheers, David
In my world view, an enterprise is ultimately always trying to
attain and sustain agility levels (relative to investors, employees,
market opportunity, partners, and competitors) through data access,
integration, and management.
An ontology is data that represents the description of entity types,
relation types, entity relationships in a given domain, as perceived
by the ontology designer.
Ontologies exist for enterprise domains such:
Accounting, Business Development, Marketing, Support, Supply Chain
Management etc..
It may be that most Ontolog folks are not delivering what
I'm calling "enterprise apps" - apologies if I'm using that
term differently from others.
Maybe, but do understand that a majority of Ontolog folks have many
years of enterprise experience. This isn't a collection of academics
for which the word "enterprise" is some mysterious terms for which
experience is scant, at best.
These are not research projects or lightweight apps where
people browse around Linked Data in a browser.
An HTTP user agent (e.g., a browser) is one mechanism for exploring
an ontology (definition oriented entity relations) and instance data
(entity relations) produced using terms from said ontology. A
browser can easily enable you determine that one entity identifier
in the Account System and another in the Business Development
system actually share a common referent: as a consequence, enabling
you send one email rather than two+ when trying to dispatch relevant
communication to that entity. Likewise, it can help you determine
that coreference relations are missing etc..
In SAAS cases, these apps are provided with contractual
service level agreements including things like financial
penalties failing to meet 99 percent availability and
performance monitoring. So, nothing is included in their
architecture or development that adds risk, slows down
performance, increases the cost of development, adds to the
cost of maintenance, etc.
Enterprises have used HTTP, CORBA, OLE, and many other protocols for
eons to tackle issues that we see on the public Web today. The Web
is the new kid on the block, not the fundamental concepts associated
with Ontology, Distributed Computing, Distributed Objects etc... The
Web technology stack just makes this more open (i.e., platform
independent and extensible) thereby enabling data to flow more
freely, subject to data access polices (ideally based on attribute
based access controls).
Kingsley
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
Community Portal: http://ontolog.cim3.net/wiki/
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
Community Portal: http://ontolog.cim3.net/wiki/
|