|
On 9/21/13 2:17 PM, David Eddy wrote:
Kingsley -
On Sep 21, 2013, at 1:39 PM, Kingsley Idehen wrote:
SQL RDBMS engines are horrible
when it comes to security. Just down right horrible. They
use literal identifiers for their objects, they are
utterly challenged by semantics
Does anything in the SW stack provide any more semantics
than flat files, RDBMSs or inverted list structures.
RDF enables you express fine-grained entity relationship semantics.
So to answer you question, it's an emphatic yes!
In the context of legacy portfolios (collections of
applications), one of the great challenges is tracking down
what is the same & what is different.
Yes, you will have records for the same customer split across a
plethora of databases associated with a plethora of apps. Thus, you
need to deal with co-reference, and it goes something like this:
1. decouple the data from the apps -- i.e., use existing data access
middleware to achieve that goal
2. build an entity relationship graph oriented shim (view) over the
the data via the data access middleware
3. apply linked data principles to the view -- i.e., use HTTP URIs
to "refer to" (or denote) entities in the entity relationship graph
4. embellish the shim (view) with entity relationship semantics --
basically, this is where co-reference semantics come into play e.g.,
via owl:sameAs relations
5. leverage reasoning (materialized or using dynamic evaluation)
within query languages (e.g., SPARQL) when working with the entity
relationship graph based view.
Net effect of 1-5 is that "Customer" data is no longer a fragment
splattered across application and database combos. You end up with a
concrete "Customer" entity that's usable as a focal point for
applications and services.
The above also implies that Update, Inserts, and Deletes can
continue to be handled by existing apps and services. You simply use
the views to drive analysis and other activities that directly
impact enterprise agility e.g., being able to answer questions about
customers much quicker.
Obviously just because the label is the same does not say
the thingys are the same & just because the labels are
different does not say they're different.
See my comment above. You keep on coming back to this point, and I
keep on regurgitating the same response in different ways. Your
problem is surmountable. It's basically Semantic Web 101.
Example (as before)... how do I know that M0760 and
MSTR-MENSA-FL are actually the same thing? And just within
this single file there are approximately 1,700 such labels.
They aren't devoid of context. If they were devoid of context they
wouldn't even be in the system or at least not visible to anyone who
could contemplate their ambiguities etc..
Does the SW stack address that Gordian Knot?
It has a URI for it:
<http://dbpedia.org/resource/Gordian_Knot> .
It is also described here with faceted browsing enabled:
<http://dbpedia.org/describe/?uri=http://dbpedia.org/resource/Gordian_Knot>
.
The Semantic Web stack does include tools for dealing with problems
that have been presumed to be intractable, during a different time
when IT infrastructure was much different than it is today :-)
Kingsley
_________________________________________________________________
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
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
|
smime.p7s
Description: S/MIME Cryptographic Signature
_________________________________________________________________
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 (01)
|