Re: Why do we name nodes and not edges?

On Aug 1, 2012, at 6:22 AM, Steve Harris wrote:

> On 2012-07-31, at 15:57, Pat Hayes wrote:
> 
>> 
>> On Jul 31, 2012, at 7:32 AM, Steve Harris wrote:
>> 
>>> On 2012-07-31, at 00:38, トーレ　エリクソン wrote:
>>> 
>>>> Hugh Glaser wrote:
>>>>> With respect to naming triples, at first sight it seems to me there is
>>>>> a perfectly sensible way of doing it, as I described in an earlier
>>>>> message. There is no need to describe a language for encoding the whole
>>>>> triple a unique URI for the edge uniquely identifies the triple, and
>>>>> seems quite natural.
>>>>> This URI can then be subPropertyOf whatever it would have been in the
>>>>> general form.
>>>>> So we have gained identifiers for triples for the possible maximum cost
>>>>> of one extra subPropertyOf triple for each triple to be identified.
>>>>> And now RDF can be used to make statements about each triple (edge), and
>>>>> I can do it all in Linked Data.
>>>>> 
>>>>> This doesn't immediately solve the same thing as Named Graphs, where
>>>>> groups of triples/edges needed to be identified.
>>>>> But can't the edges be gathered into Classes?
>>>>> And with multiple inheritance, you can have arbitrary membership of
>>>>> Classes by any edge, giving much more power than simple Named Graphs,
>>>>> where triples/edges can only be members of one graph?
>>>> 
>>>> [snip]
>>>> 
>>>>> Is there anything technically wrong with what I am describing?
>>>> 
>>>> I find this solution quite intriguing as well. It would be easier to
>>>> implement if RDF were to allow blank nodes in the predicate position.
>>> 
>>> You can't use bNodes (for fairly obvious semantic reasons)
>> 
>> Well, no. Actually there are no *semantic* problems with having bnodes in predicate position. The RDF semantics would adapt to this case quite smoothly. The same semantic constructions were used in ISO Common Logic which allows quantification over relations of arbitrary arity. Of course there might be other issues, but the semantics is OK.
> 
> I simply meant that a blank *node* can't be an edge.

Ah yes, indeed. Wording. 

> You could add bArcs,

Quite.

> but given what we've learnt about using bNodes in practice, making them existential variables seems like a mistake.

Well, that was exactly my point, above. The RDF semantics would work AS WRITTEN, without change, if bArcs were allowed in RDF. And it would give them the existential interpretation, just as it does bNodes. The result would be a subset of ISO Common Logic, and it would work just fine. CL works beautifully (IMO, of course.)

> Semantic was probably a poor choice of words in this company, sorry :)
> 
>>> but you can put a genid URI (http://www.w3.org/TR/rdf11-concepts/#section-skolemization), or a UUID URN there, which has lots of the same benefits from a usability point of view, but without the bizarre mathematical implications.
>> 
>> What bizarre mathematics are you worried about? 
> 
> I meant bizarre implications (of bNodes/bArcs being existential variables), not bizarre mathematics.
> 
> I can't quite figure out the consequences, but given the strange results that bNodes in OWL cause

Well, yes, the OWL/RDF would probably rule out bArcs in its syntax constraints (the OWL-DL almost certainly would), but that isn't an argument against having them in RDF itself.  Again, IMO.  This is purely academic, of course; AFAIK, nobody is suggesting having bArcs in RDF. But I tend to bristle when people just assert that things like this are impossible, catastrophic, obviously insane, etc.., when they have been yawn run-of-the-mill for about a decade in more expressive logics, have a clear semantics, and have elegant use cases.  

OK, end of rant.

Pat


> , I would think that existential variables as edges would be equally strange. Perhaps not.
> 
> - Steve
> 
> -- 
> Steve Harris, CTO
> Garlik, a part of Experian
> +44 7854 417 874  http://www.garlik.com/
> Registered in England and Wales 653331 VAT # 887 1335 93
> Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ
> 
> 
> 

------------------------------------------------------------
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 Thursday, 2 August 2012 04:16:10 UTC