ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] URIs [was: Truth]

To: ontolog-forum@xxxxxxxxxxxxxxxx
From: Kingsley Idehen <kidehen@xxxxxxxxxxxxxx>
Date: Wed, 11 Jul 2012 12:00:20 -0400
Message-id: <4FFDA314.3070103@xxxxxxxxxxxxxx>
On 7/11/12 11:47 AM, doug foxvog wrote:
> On Tue, July 10, 2012 17:48, Kingsley Idehen wrote:
>> On 7/10/12 2:25 PM, doug foxvog wrote:
>>> On Tue, July 10, 2012 12:31, Kingsley Idehen wrote:
>>>> On 7/10/12 12:08 PM, doug foxvog wrote:
>>>>> On Sun, July 8, 2012 16:43, Kingsley Idehen wrote:
>>>>>> I think that URIs have already laid the seed for success. Its the
>>>>>> kernel
>>>>>> of the World Wide Web of documents, and it also facilitates a similar
>>>>>> Web of structured data. Personally, I don't think we need a design
>>>>>> competition, we just need to find a way to get everyone to see the
>>>>>> common ground that URIs provide -- when applied to structured
>>>>>> data -- at Web-scale.
>>>>> One problem with URIs in the linked data community is coreferencing.
>>>>> Time and again new URIs are generated for things (individuals,
>>>>> classes,  relations) for which URIs already exist.
>>>> No, that's an actual feature. You can deal with coreferences via
>>>> owl:sameAs or owl:inverseFunctionalProperty based reasoning and/or
>>>> custom rules.
>>> That's extra computation for those who know of the equivalences, and
>>> missing for those who don't.  Consider the computational complexity for
>>> reasoning with owl:sameAs.
>> ...
>> Computation complexity doesn't have to be in the end-users face, for
>> instance. Handling the complexity can be value provided by an
>> infrastructure oriented service.
>> This game is still all about good old lookups
> If the game you're playing is lookup, computational complexity for
> reasoning with owl:sameAs is minimal.  Computational complexity
> kicks in when owl:sameAs is used with classes and relations and
> reasoning is expected using rules that reference such classes and
> relations.
>
> That still does not handle the missing owl:sameAs assertions,
> which i mentioned above.    (01)

I don't have a problem handling owl:sameAs, owl:equivalentClass, 
owl:equivalentProperty etc.. re. a massive datasets we oversee.    (02)

We handle the computation complexity while giving data consumers data 
that incorporates the end product. To the user they just have a large 
graph.    (03)

>
>> and views enhanced by
>> discovery patterns and relationship semantics that constitute Web
>> accessible structured data.
>>>> Have many routes to the same data objects is never a bad thing.
>>> Actually, it is different data objects which (may) refer to the same
>>> thing.
>>> Many government view it to be a bad thing if there are many social
>>> security number data elements to the same data object (person).
>> Come on now, how have you arrived at that exemple bearing in mind the
>> existence of semantics for inverse functional relationships in OWL etc?
> It seemed to me that functional relationships (whether inverse or not)
> are in conflict with the assertion that having "many routes to the same
> data objects is never a bad thing".
>
> Never say "never"!   8)#    (04)

Have many IDs for the same thing isn't a bad thing, how about that? Its 
vital to the World Wide Web system.    (05)

>
>>>>>> If we the world has come to appreciate Hypertext, why can't it do the
>>>>>> same with Hyperdata -- what entity-attribute-value model enhanced
>>>>>> with de-referencable URIs delivers under the Linked Data moniker?
>>>>>    [Triple example with classes as arguments]
>>>>> Hyperdata also does not have to be restricted to triples:
>>>>>    [Quad example]
>>>>> Maybe subject-verb-object* would be a better description
>>>>> [than entity-attribute-value].
>>>> You've played around with literals that denote slots in a particular
>>>> type of 3-tuple, the semantics to the triple in question hasn't
>>>> changed.
>>> That's a 4-tuple, not a 3-tuple; not a triple.  In this case we could
>>> reify ... and create a mass of 3-tuples [converted example]
>>> Trying to express
>>>       (Object1 spatiallyBetween Object2 Object3)
>>> using only triples is even trickier.  But if all you have is a hammer,
>>> you can try to make a nail out of the problem.
>> You are moving all over the place with me here. Have I implied that
>> Triple patterns are the only vehicle for Hyperdata?
> You said
>>>>>> "Hyperdata -- what entity-attribute-value model enhanced
>>>>>> with de-referencable URIs delivers"
> and
>>>> You've played around with literals that denote slots in a particular
>>>> type of 3-tuple, the semantics to the triple in question hasn't
>>>> changed.
> in reference to a quad, so i inferred that you were strongly pushing
> the use of Triple patterns for Hyperdata.    (06)

No, I am not pushing anything specifically.    (07)

>
>> And FWIW you can use
>> reification syntax to keep statements about anything down to triples,
> Which i mentioned and gave an example of.  Note that of my second
> quad, i stated it was trickier to express as triples, not that it couldn't
> be done.    (08)

Okay.    (09)

>
>> the ultimate problem is the current reification vocabulary doesn't work
>> on the engineering side of things, so alternatives are needed if we
>> don't want to increase computing costs across the board.
> A simple alternative is to allow quads, or even higher arity predicates.    (010)

Yes, and our system is a Quad Store.    (011)

>
>
>>>>>> I think we call all use the URI as a common foundation for broad
>>>>>> agreement re. data access, integration, and representation :-)\
>>>>> I suggest emphasizing the use of URIs from standard predefined
>>>>> ontologies and term sets as much as possible.
>> ...
>> Okay, we agree    (012)

Awesome!  :-)    (013)

Kingsley    (014)


> -- doug foxvog
>
>> ...
>> Kingsley
>>> -- doug foxvog
>>>
>>>> Kingsley
>
>> 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
>   
>
>    (015)


--     (016)

Regards,    (017)

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    (018)

Attachment: 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)

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