ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Constructs, primitives, terms

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "doug foxvog" <doug@xxxxxxxxxx>
Date: Fri, 16 Mar 2012 11:27:21 -0400
Message-id: <572aa03409c016f95b5a39694a04cc93.squirrel@xxxxxxxxxxxxxxxxx>
On Wed, March 14, 2012 14:42, Kingsley Idehen wrote:
> On 3/14/12 8:43 AM, David Eddy wrote:
>> On Mar 14, 2012, at 8:10 AM, David Price wrote:    (01)

>>> What they've likely been told is
>>> that, compared to other identification mechanisms, HTTP URIs have very
>>> nice characteristics and so are a good choice in many scenarios:    (02)

>> What does the organization (or an individual) do when HTTP/URI is not an
>> inherent part of the environment?    (03)

>> This is feeling like the drunk looking for his car keys under the
>> street lamp because that's where the light is.    (04)

>> There's a HUGE amount of organizational software functionality that's no
>> where near web protocols.    (05)

> Yes, and the whole lot can be mapped to URIs.    (06)

This is trivially true.  Each program module which defines terms could be
given a unique namespace (NS) and then each term (T) defined in that
namespace could be assigned the URI: NS#V .    (07)

The difficulty comes in matching the term to some externally defined
term.  Once such a match is done, the local URIs could be replaced with
the external URI or the two could be equated with owl:sameAs.    (08)

> And when resolution is a
> requirement HTTP is there of cost-effective exploitation if WAN scale of
> the InterWeb is relevant.    (09)

> I think people misunderstand what URIs are and how they affect data
> access and data integration.    (010)

> In different guises, blending disparate structured data    (011)

By "structured data", do you include traditional structured data which
appears in file records, data bases, and spreadsheets?  Or are you
restricting yourself to RDF-structured data?  Since you are discussing
converting traditional software to URIs, i'm guessing that you include
traditional structured data as well as SW-structured data.    (012)

> boils down to establishing identifiers for:    (013)

> 1. data objects
> 2. data object access addresses.    (014)

By "data object" do you mean OOP objects, which have attached methods;
normal CS objects, including data base cells, variables, constants, arrays,
strings, and floats; instances of RDF-S definitions for particular
classes; or
something else?    (015)

I would suggest that blending traditional structured data from disparate
sources involves far more than establishing URIs for cells, columns, and
rows of databases and addresses for the content of such data.    (016)

What is needed is URIs for the semantic entities and classes which the
structured data explicitly or implicitly refers to.  Sometimes a record or
database column or row refers to an individual or class for which data
might be shared.  Sometimes it refers to a relation which should have
a URI.  But other times one set of columns for a single row in a database
(or set of fields in a file record) refer to one entity, while another set
in the same row/record refers to another entity.    (017)

A database or file field may be restricted to providing information about
a certain type of thing, even if the field filler is a text string.  Are such
restrictions considered to be "data objects"?  Fields are often restricted
to being filled by different codes, each of which has a specific meaning.
Do such codes require unique URIs?  What about cases in which the
same string is a code for different things in different fields?  What about
the case in which different codes in different fields represent the same
type of thing?    (018)


> The above bring portability and dexterity to:    (019)

> 1. data object representation models
> 2. data object representation formats
> 3. data object access protocols.    (020)

I agree that shared URIs enable such portability.    (021)

> Context fluidity is a timeless challenge for data access and
> integration. The above take us a long way towards alleviating
> said challenges.    (022)

In that the use of URIs would encourage coders not to broaden, narrow,
or otherwise alter the meaning of/restrictions on a field?    (023)

> Today, we hear a lot about BigData or 'Big Data' and very little about
> the fundamental realities associated with:    (024)

> 1. exponential growth of data volume
> 2. exponential growth of data velocity
> 3. exponential growth of data variety (heterogeneity)
> 3. exponential growth of data location disparity.    (025)

> You can't deal with these matters without URIs in your arsenal.    (026)

URIs seem to me to address the first point #3.  I don't see offhand how
growth of volume and velocity of homogeneous data or even growth
in the number of homogeneous sensors (and thus data location) requires
the use of URIs.    (027)

> Ontologies, Inference Rules, Data Objects etc.. can all be combined in
> powerful ways that enable subject matter experts solve complex data
> integration problems. When done right, the end products of said efforts
> scale by fitting naturally into virtuous Linked Data clouds    (028)

I agree that data encoded in ontologies can fit naturally into constrained
Linked Data clouds.  This would especially be the case if the clouds
easily represented ternary and higher-arity relations as well as ordered
lists.    (029)

> as exemplified burgeoning Web of Linked Data.    (030)

I am not convinced that the burgeoning Web of Linked Data exemplifies
"virtuous" LD "done right".  I see massive heterogeneity  with multiple
URIs promulgating for the same classes, the same relations, and the
same individuals.  I see linked data removed from context.    (031)

> Note, when I refer to Linked
> Data I am not implying a use-case that only applies to the public HTTP
> network aka. the World Wide Web.    (032)

Context-restricted and context-identified Linked Data could be more
useful, imho.  That which i find appearing on the WWW does not have
these features.    (033)

> My mantra is very simple re. contemporary data access and integration
> matters: URI Everything and Everything is Cool! :-)    (034)

I've got a hammer; it'd be great if the rest of you turned everything into
nails!  8)#    (035)

-- doug    (036)

>> ___________________
>> David Eddy
>> deddy@xxxxxxxxxxxxx
________________________________________________    (037)


> 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
>
>
>
>
>
>
>
> _________________________________________________________________
> 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
>    (038)



_________________________________________________________________
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    (039)

<Prev in Thread] Current Thread [Next in Thread>