W3C home > Mailing lists > Public > semantic-web@w3.org > July 2010

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

From: Pat Hayes <phayes@ihmc.us>
Date: Thu, 1 Jul 2010 22:27:06 -0500
Cc: Linked Data community <public-lod@w3.org>, Semantic Web <semantic-web@w3.org>
Message-Id: <3C047CAC-89CE-4DE8-8A20-B4C8B3C191CD@ihmc.us>
To: Kingsley Idehen <kidehen@openlinksw.com>

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?

>
> 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....).

>
> 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 guess my own subtle mistake (re. this thread) is deeming  
> Identifiers and Names to be equivalent , when they aren't :-) Of  
> course, one can use an Identifier as a Name, but that doesn't make  
> them equivalent.
> **
>
>
> One clear point of divergence here is that I am focused on the Web  
> as Dist. DBMS that leverages 3-tuples + HTTP URIs in the S, P, and  
> optionally O slot (aka. HTTP based Linked Data).
>
> To conclude:
>
> Name != Identifier.

>
> I believe Subject == Name (an Identifier based Name) re. RDF triples  
> otherwise the triple should be described as: O-R-O or O-P-O.
>
> I believe an S-P-O triple is a piece of information (Data Object has  
> a Name and at least one Attribute=Value pair).
>
> What I desscribe actually has zilch to do with RDF as I am inclined  
> to believe you see RDF :-)

I see it the way the RDF specifications describe it. I am genuinely  
not quite clear how you see it, but it seems to have very little to do  
with the way it is specified. Perhaps you would be better off using  
something other than RDF.

Pat


> Thus, in a way, the literal-subject debate may simply help everyone  
> understand and accept that RDF != Linked Data. Thus, providing  
> additional proof that RDF isn't mandatory or even required re.  
> delivery of  HTTP based Linked Data.
>
> RDF based Linked Data != RDF. They are different things, clearly.   
> We can't have it both ways (** Pat: not for you, that's for those  
> that deem RDF and Linked Data inextricably linked **).
>
>
> BTW - I still have no idea if RDF and RDF/XML are really distinct.  
> HTML and N3 built the Web of Linked Data, but N3  remains a 2nd or  
> 3rd class citizen whenever we talk about the pragmatic aspects of  
> what continues to be inappropriately labeled as an RDF virtue i.e.  
> Linked Data.
>
> Danbri:
>
> I agree with the essence of your earlier post!
>
>
> Kingsley
>
>
>>
>> Pat
>>
>>
>>> I know the meaning of: <http://km.aifb.kit.edu/projects/numbers/web/n23#this 
>>> >, based on the resource I deref at: <http://km.aifb.kit.edu/projects/numbers/web/n23 
>>> >
>>>
>>>
>>>
>>> Kingsley
>>>
>>>
>>>>
>>>> Pat Hayes
>>>>
>>>>>
>>>>> If you are in a situation where you can't or don't want to mint  
>>>>> an HTTP based Name, simply use a URN, it does the job.
>>>>>
>>>>>
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Nathan
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>>
>>>>> Regards,
>>>>>
>>>>> Kingsley Idehen          President & CEO OpenLink Software      
>>>>> Web: http://www.openlinksw.com
>>>>> Weblog: http://www.openlinksw.com/blog/~kidehen
>>>>> Twitter/Identi.ca: kidehen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ------------------------------------------------------------
>> 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
>
>
>
>
>

------------------------------------------------------------
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
Received on Friday, 2 July 2010 03:28:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:20 UTC