Re: Subjects as Literals, [was Re: The Ordered List Ontology]

Pat Hayes wrote:
>
> On Jul 2, 2010, at 6:52 AM, Kingsley Idehen wrote:
>
>> Pat Hayes wrote:
>>>
>>> On Jul 1, 2010, at 9:42 AM, Kingsley Idehen wrote:
>>>
>>>> Pat Hayes wrote:
>>>>>
>>>>> On Jun 30, 2010, at 3:49 PM, Kingsley Idehen wrote:
>>>>>
>>>>>> Pat Hayes wrote:
>>>>>>>
>>>>>>> On Jun 30, 2010, at 1:30 PM, Kingsley Idehen wrote:
>>>>>>>
>>>>>>>> Nathan wrote:
>>>>>>>>> Pat Hayes wrote:
>>>>>>>>>> On Jun 30, 2010, at 6:45 AM, Toby Inkster wrote:
>>>>>>>>>>> On Wed, 30 Jun 2010 10:54:20 +0100
>>>>>>>>>>> Dan Brickley <danbri@danbri.org> wrote:
>>>>>>>>>>>> That said, i'm sure sameAs and differentIndividual (or 
>>>>>>>>>>>> however it is
>>>>>>>>>>>> called) claims could probably make a mess, if added or 
>>>>>>>>>>>> removed...
>>>>>>>>>>>
>>>>>>>>>>> You can create some pretty awesome messes even without OWL:
>>>>>>>>>>>
>>>>>>>>>>> # An rdf:List that loops around...
>>>>>>>>>>>
>>>>>>>>>>> <#mylist> a rdf:List ;
>>>>>>>>>>>     rdf:first <#Alice> ;
>>>>>>>>>>>     rdf:next <#mylist> .
>>>>>>>>>>>
>>>>>>>>>>> # A looping, branching mess...
>>>>>>>>>>>
>>>>>>>>>>> <#anotherlist> a rdf:List ;
>>>>>>>>>>>     rdf:first <#anotherlist> ;
>>>>>>>>>>>     rdf:next <#anotherlist> .
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> They might be messy, but they are *possible* structures using 
>>>>>>>>>> pointers, which is what the RDF vocabulary describes.  Its 
>>>>>>>>>> just about impossible to guarantee that messes can't happen 
>>>>>>>>>> when all you are doing is describing structures in an 
>>>>>>>>>> open-world setting. But I think the cure is to stop thinking 
>>>>>>>>>> that possible-messes are a problem to be solved. So, there is 
>>>>>>>>>> dung in the road. Walk round it.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Could we also apply that to the 'subjects as literals' general 
>>>>>>>>> discussion that's going on then?
>>>>>>>>>
>>>>>>>>> For example I've heard people saying that it encourages bad 
>>>>>>>>> 'linked data' practise by using examples like { 'London' a 
>>>>>>>>> x:Place } - whereas I'd immediately counter with { x:London a 
>>>>>>>>> 'Place' }.
>>>>>>>>>
>>>>>>>>> Surely all of the subjects as literals arguments can be 
>>>>>>>>> countered with 'walk round it', and further good practise 
>>>>>>>>> could be aided by a few simple notes on best practise for 
>>>>>>>>> linked data etc.
>>>>>>>>
>>>>>>>> IMHO an emphatic NO.
>>>>>>>>
>>>>>>>> RDF is about constructing structured descriptions where 
>>>>>>>> "Subjects" have Identifiers in the form of Name References 
>>>>>>>> (which may or many resolve to Structured Representations of 
>>>>>>>> Referents carried or borne by Descriptor Docs/Resources). An 
>>>>>>>> "Identifier" != Literal.
>>>>>>>
>>>>>>> What ARE you talking about? You sound like someone reciting 
>>>>>>> doctrine.
>>>>>>>
>>>>>>> Literals in RDF are just as much 'identifiers' or 'names' as 
>>>>>>> URIs are. They identify their value, most clearly and 
>>>>>>> emphatically. They denote in exactly the same way that URIs 
>>>>>>> denote. "23"^^xsd:number   is about as good an identification of 
>>>>>>> the number twenty-three as you are ever likely to get in any 
>>>>>>> notational system since ancient Babylonia.
>>>>>>
>>>>>> Yes, but ancient Bablyonia != World Wide Web of Structured Linked 
>>>>>> Data, slightly different mediums with some shared characteristics 
>>>>>> :-)
>>>>>>
>>>>>> The World Wide Web is becoming a Distributed DBMS (in my eyes). 
>>>>>> Thus, unambiguous naming matters.
>>>>>
>>>>> A topic for a longer discussion; but irrelevant here, since typed 
>>>>> literals are as unambiguous as a name can possibly get.
>>>>>
>>>>>>
>>>>>> Literal Subjects aren't a "show stopper" per se. (esp. for local 
>>>>>> RDF data). My gripe simply boils down to the nuisance factor 
>>>>>> introduced by data object name ambiguity in a distributed data 
>>>>>> object oriented realm such as the emerging Web of Linked Data.
>>>>>>
>>>>>> What does ""23"^^xsd:number " mean to anyone in a global data space?
>>>>>
>>>>> It means the number twenty-three, everywhere and for all time, 
>>>>> because this meaning can be computed from the very syntactic form 
>>>>> of the name. How unambiguous can something get?
>>>>
>>>> Pat,
>>>>
>>>> Re. RDF's triples, What is a Subject? What is an Object?.
>>>
>>> "subject' refers to the first element in a triple, "object" to the 
>>> last. One might as well call them 'first' and 'third'. The names
>>> 'subject' and 'object' are used purely for convenience, and have no 
>>> formal or semantic significance.
>>>
>>>>
>>>> If they are the same thing, why on earth do we use Names (with 
>>>> implications) to describe the slots in an RDF triple?
>>>
>>> I do not understand the question here well enough to provide an 
>>> answer. Have you actually read the RDF spec documents? The RDF 
>>> syntax model and the semantics?
>>
>> You don't understand the question enough to provide an answer, but 
>> you are able to compute an assessment of spec assimilation. WOW !!
>
> The logic here is: if you had understood the specs, you wouldn't be 
> asking such a damn silly question as you appear to be asking. So, I 
> conclude to myself, I must be misunderstanding your question. Unless, 
> of course, you havn't actually read the specs...

Pat,

Assume I've read the spec and don't understand them. Rather that 
gravitating to insults, just answer the question I asked.

If too silly or dumb for you, you do have the option to ignore.

Where I come from there are no silly or dumb questions. Instead, it  
rather silly or dumb to not ask questions when pursuing clarity.

So far so good, you have spewed subjective commentary and unnecessary 
insults.

You can have a conversation without being insulting, you know.


>
>>>> I've only once seen the RDF triple referred to as O-R-O (by 
>>>> @danbri) i.e., Object-Relation-Object.
>>>
>>> IF you read the specs, however, it is abundantly clear that this is 
>>> what an RDF triple means, viz. that a relation holds between two 
>>> objects (I prefer "things", but....).
>>
>> Exactly!
>
> ? I thought you were arguing *against* this view ?

I am not arguing against the view.

I am seeking clarity.

Can people not play "devils advocate" en route to seeking broader 
clarity in the  "RDF" realm?

>
>>
>> So why: Subject-Predicate-Object  (SPO) everywhere re. RDF?
>
> As I said, the terminology is used so as to make it easier to refer to 
> the various parts of a triple. Yes, triples are ordered. The 
> 'linguistic' flavor of the SPO terminology is an unfortunate accident 
> of history. 

Thanks for answering the question.

As you can see, just another chunk of conflation that makes RDF very 
very difficult to describe, conceptually.

> In other forums, people talk of 'first' and 'second' 'argument 
> positions', which  for many people has the unpleasant metallic taste 
> of mathematics. But its the same thing they are talking about.
>
> But in any case, even if I agree that (in spite of the RDF spec), 
> there is something intuitively significant about the idea of a 
> 'subject', I still don't see (to return to the thread topic) why a 
> literal should not count as a perfectly good name for the subject of a 
> description. 
Returning to the topic head.

I am looking at things from the DBMS view, bearing in mind I strongly 
believe the World Wide Web is evolving into a Distributed Databases on a 
global scale.


> Literals denote a rather limited range of things, to be sure: strings, 
> numbers, dates, etc.. ; but these things are real things, and some of 
> them play their small but nontrivial roles in our lives, so why should 
> they be arbitrarily excluded from the universe of topics that can be 
> the legitimate subjects of a description?
They shouldn't be, just give unambiguous names to subjects. "23" doesn't 
mean the same thing to every human being on this planet.

A majority of human beings on this planet are getting connected to the 
World Wide Web. It increasingly at part of their lives. Thus, don't make 
assumptions about "23", give it a proper name (unambiguous variety), and 
describe it based on your particular world view etc..

As per the URI in the earlier thread, numbers already have URIs. Ditto 
letters of the Alphabet [1] .
>
>> O-R-O reflects what you've just described.
>
> And what I just described is what the RDF spec says, in mind-numbing 
> detail.

Yes, could be subjectively mind-numbing, but at best that's simply your 
opinion. Of course, an opinion you are entitled too, naturally.

Through my subjective lenses: Detail != Clarity.

>
>> Like many of the RDF oddities (playing out nicely in this thread), 
>> you have an O-R-O but everyone talks about S-P-O.
>>
>> "Subject" has implicit meaning, it lends itself to describing stuff.  
>> If I recall, RDF stands for: Resource Description Framework.
>>
>> I guess "Description" also means nothing?
>
> Not at all. RDF is indeed a language for describing, just like any 
> other assertional logic. Descriptions are made up from assertions of 
> relationships between things. Each RDF triple is a little assertion.

So back to my point, what is the focal point of the assertions? Isn't 
such a thing commonly referred to as "Subject"? 

Assertions that coalesce around a "Subject" give us a descriptive 
representation of said "Subject".

So following this literal-subjects line of thought. Are there any size 
constraints?

>
>>>> In addition, I don't see Information and Data as being the same 
>>>> thing. Information (as I know it) is about Data + Context.  Raw 
>>>> Data (as I know it) is about: a unit of observation and deemed 
>>>> worthy of description by its observer.  You have to give Names to 
>>>> subject of a description. "23"^^xsd:number  isn't a Name.
>>>
>>> Why do you say this? It is certainly as much a name as, say, 
>>> "Patrick J. Hayes". It is a well-formed string which denotes 
>>> something, and its denotation is perfectly clear, in fact 
>>> computable. So, it is a name. I challenge you to specify what you 
>>> mean by "Name" in such a way that it excludes literals as names, 
>>> other than by simply reiterating your bare claim that they are not.
>>
>> I mean an unambiguous Name for a Web of Semantically Linked Data.
>>
>> "Patrick J. Hayes" simply doesn't cut it as an unambiguous name 
>> within the aforementioned Web.
>
> "simply doesn't cut it" simply doesn't cut it as any kind of 
> convincing argument. WHY does it not cut it? 
Because Its inherently ambiguous in a global data space such as the 
World Wide Web (WWW).

Again, let's get the context straight here. This is about the WWW 
medium.  RDF without the WWW is an endeavor to achieve what? Goals 
matter where I come from.

RDF in local zip files are as useless today as they were in the early 
days of RDF (pre. Linked Data meme).

Example across 3 distinct Linked Data Spaces:

1. http://uriburner.com/fct/facet.vsp?cmd=load&fsq_id=47 --- lot of 
things associated with "Patrick J. Hayes" I have a disambiguation task 
on my hands
2. 
http://www.google.com/search?client=safari&rls=en&q=patrick+j.+hayes&ie=UTF-8&oe=UTF-8 
-- which "Patrick J. Hayes"? What "Patrick J. Hayes" ?
3. 
http://lod.openlinksw.com/fct/rdfdesc/usage.vsp?g=http%3A%2F%2Fdbpedia.org%2Fresource%2FPatrick_J._Hayes&tp=3 
-- disambiguated
4. 
http://lod.openlinksw.com/fct/rdfdesc/usage.vsp?g=http%3A%2F%2Fdbpedia.org%2Fresource%2FPatrick_J._Hayes&tp=4 
-- disambiguated .

Doesn't cut it because I want to Find Things with Precision by Name, 
over huge data spaces within and across the WWW. I don't want to build 
airport sized data centers to pull that off.  No decreases in computer 
hardware make that proposition practical. IMHO.

> What is wrong with it as a name? It is certainly not ambiguous, as you 
> seem to imply. 
See links above. Its utterly ambiguous on the WWW medium.

Names have a degree of medium specificity that affects their bottom line 
utility.

> As several people have pointed out, its hard to even imagine anything 
> less ambiguous than an RDF literal.
I suspect you meant: less unambiguous?
> It contains a link (a URI) to the very specification which determines 
> its own meaning. So, what other problems do you see with it as a name?
Assuming, you meant "less unambiguous" the links above should hopefully 
clarify my point re. effective and practical unambiguous Names re. WWW 
medium.

Links:

1. http://dbpedia.org/resource/A - Letter A
2. http://dbpedia.org/resource/Z

Kingsley
>
> Pat
>
>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
>
>
>


-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Friday, 2 July 2010 18:24:13 UTC