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. (01)
>>>> 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. (02)
>>> No, that's an actual feature. You can deal with coreferences via
>>> owl:sameAs or owl:inverseFunctionalProperty based reasoning and/or
>>> custom rules. (03)
>> 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. (04)
> ...
> 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. (05)
> This game is still all about good old lookups (06)
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. (07)
That still does not handle the missing owl:sameAs assertions,
which i mentioned above. (08)
> and views enhanced by
> discovery patterns and relationship semantics that constitute Web
> accessible structured data. (09)
>>> 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. (010)
>> Many government view it to be a bad thing if there are many social
>> security number data elements to the same data object (person). (011)
> Come on now, how have you arrived at that exemple bearing in mind the
> existence of semantics for inverse functional relationships in OWL etc? (012)
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". (013)
Never say "never"! 8)# (014)
>>>>> 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? (015)
>>>> [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]. (016)
>>> 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. (017)
>> 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] (018)
>> 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. (019)
> You are moving all over the place with me here. Have I implied that
> Triple patterns are the only vehicle for Hyperdata? (020)
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. (021)
> And FWIW you can use
> reification syntax to keep statements about anything down to triples, (022)
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. (023)
> 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. (024)
A simple alternative is to allow quads, or even higher arity predicates. (025)
>>>>> 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 (026)
-- doug foxvog (027)
> ...
> Kingsley
>> -- doug foxvog
>>
>>> Kingsley (028)
> 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 (029)
_________________________________________________________________
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 (030)
|