Re: comments / review of Concepts

Gentlemen, 

What do you think about putting some of the material currently in Semantics section  4.1 into Concepts section 6? I have no axe to grind on this, but maybe we should at least consider the idea. It is not directly concerned with semantics so much as the machinery of combining graphs into larger ones, which seems like fairly basic stuff that all RDF users should know about. 

I can volunteer to do the actual typing required to produce a draft, as I have a fairly smooth workflow going at this point. 

Pat

On Jun 20, 2013, at 9:26 AM, Peter F. Patel-Schneider wrote:

> 
> On 06/19/2013 09:25 AM, David Wood wrote:
>> Hi Peter,
>> 
>> On May 22, 2013, at 01:38, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>> 
>>> I read Concept and Semantics on a plane this evening.
>>> 
>>> Here are my comments on Concepts.   Consider this a pre-review.
>> Thanks for this review.  Is another review forthcoming?  Please advise.
> 
> Consider that as a full review.
> 
>> 
>> 
>>> peter
>>> 
>>> 
>>> Comments on  RDF 1.1 Concepts version of 21 May 2013
>>> 
>>> Looks very good, with only one significant issue (#1, just below)
>>> 
>>> 1/ Social meaning is rearing its ugly head here
>>> 
>>> Instead use in 1.3
>>> - IRIs have global scope:  Two different appearances of an IRI denote the
>>>  same resource
>>> - By social convention, ... gets to say what the intended (or usual)
>>>  referent of an IRI is.  Applications and users need not abide by this
>>>  intended denotation, but there may be a loss of interoperability with
>>>  other applications and users if they do so.
>> I believe you meant "if they do not do so", meaning if they do not abide by the intended denotation.
>> 
> Yes.
>>> - ... For example, ... intended referents ...
>>> Instead use in 1.5
>>> - ... should never change its intended referent.
>> 
>> Changes made in the current editors' draft.  I looked at adding a definition for "intended referent" but decided it was unnecessary.
>> 
>> 
>>> Consider if I say that the meaning of pfps:foo is the integer 2 and
>>> the meaning of pfps:bar is the decimal number 2.0.  These are my IRIs so I
>>> get to do this. Does this mean that any RDF processor that performs (even)
>>> simple entailment must produce
>>> 	ex:foo ex:bar pfps:foo .
>>> entails
>>> 	ex:foo ex:bar pfps:bar .
>> 
>> Not to me, no.  Does it to you??
> 
> Of course not, but I think that we have to be careful to not imply this in any way shape or form.
> 
> The current wording here is acceptable.
>> 
>> 
>>> 2/ Union is not always conjunction
>>> 
>>> 1.7 ... the union of two RDF graphs that do not share blank nodes is their
>>> conjunction.  If two RDF graphs share blank nodes, then conjoining them may
>>> require merging [defined in Semantics].
>>> 
>>> Alternatively, define merge here.
>>> 
>>> Alternatively, remove the last sentence of the fragment above.
>> 
>> Please confirm that the changes I made to 1.7 are acceptable to you.
> 
> I think that some minor changes should be made to go along with the new Semantics stance on union and merge:
> 
>  If two or more RDF graphs share blank nodes, then unioning [point to Semantics] them preserves the shared identity of the blank nodes.  If this is not desired, the two graphs can be merged [...], which effectively destroys this shared identity.
> 
> This is purposefully vague.
> 
>> 
>>> 3/ Explicitly say which sections are normative ??
>>> 
>>> I believe this is 2, 3, 4 (except 4.2), and 5
>> 
>> I do not believe this to be necessary.  Informative sections are so marked and everything else is considered normative.  I do see that (e.g.) the 2004 OWL semantics explicitly marked normative sections as such, but personally think it is overkill.  However, I won't fight anyone over it if you think it is useful.
> 
> I just thought that in the current regime things were supposed to be explicitly spelled out this way.  If not, then no problem.
> 
> 
> [...]
> 
>> Thanks again. Regards, Dave -- http://about.me/david_wood 
> 
> I'm happy with the current state of the document, modulo blank nodes as graph names.
> 
> peter
> 
> 
> 

------------------------------------------------------------
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, 20 June 2013 16:12:19 UTC