Re: Promoting rdf-mt

On Jun 21, 2013, at 10:46 AM, Eric Prud'hommeaux wrote:

> * Pat Hayes <phayes@ihmc.us> [2013-06-21 10:20-0500]
>> 
>> On Jun 21, 2013, at 7:26 AM, Eric Prud'hommeaux wrote:
>> 
>>> * Sandro Hawke <sandro@w3.org> [2013-06-21 06:25-0400]
>>>> 
>>>> 
>>>> Gavin Carothers <gavin@carothers.name> wrote:
>>>> 
>>>>> On Thu, Jun 20, 2013 at 8:39 PM, Pat Hayes <phayes@ihmc.us> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jun 20, 2013, at 9:22 PM, Peter Patel-Schneider wrote:
>>>>>> 
>>>>>>> I say no, also because Concepts should be as small as possible.
>>>>>> 
>>>>>> Fair enough. But I still repeat that this is stuff that *all* readers
>>>>> of
>>>>>> the RDF specs should see, and apparently a large fraction of them
>>>>> never
>>>>>> read Semantics.
>>>>>> 
>>>>> 
>>>>> Well can't speak for everyone but the new version is VASTLY
>>>>> more approachable then the 2004 edition. Thanks Pat and Peter!
>>>>> 
>>>> 
>>>> I wonder what we could say about it -- how we could describe it in our other documents and postings -- that would get the people who would benefit from reading it to read it.   What does someone get out of it?    In my vision of the Semantic Web, every data consumer is doing at least RIF Core and OWL 2 RL entailment processing, with dereferencing, so they can transparently handle variations and migrations in the vocabulary.   But my vision isn't getting a lot of traction.    So for people with a less grand vision, what propose is served for RDF users by the RDF semantics?
>>> 
>>> 
>>> I'd like to echo the spirit of this question in my simplistic
>>> understanding of RDF:
>>> 
>>> The vast majority of RDF data is used with graph semantics, with
>>> SPARQL queries exhaustively matching patterns in the graph, and
>>> where BNodes are treated the same as any other term.
>> 
>> ?Really? Bnodes treated just like any other term?
> 
> To be clear, in the text of a SPARQL query, bnodes are like non-portable variables, but SPARQL's interpretation of bnodes in the data is that they are all distinct:
> 
> Data: _:b1 a <Barn> . _:b2 a <Barn> .
> Query: SELECT ?s { ?s a <Barn> }
> Results:
>  ?s
>  _:b1
>  _:b2
> The results can rename _:b1 and _:b2 to other distinct bnodes but the answer will be wrong if the cardinality isn't 2.
> 
> This is backed up by aggregate functions like count:
> Query: SELECT ?type (COUNT(?s) AS ?c) { ?s a ?t }
> Results:
>  ?type  ?c
>  <Barn> 2
> 
> I'm sorry we're abusing your child in the fashion, but we find it very practical.

No, that all makes sense. SPARQL (indeed any xxxQL) can't tell if one blank thing is the same as another, so keeping them separate is the conservative way to proceed. OK, I now understand what you mean. My squawk was because I thought you meant it treated bnodes in the query just like IRIs. 

>>> We have various levels of OWL entailment, the most common of which is
>>> DL (modulo the occasional completeness bug). DL models include
>>> BNode-BNode, BNode-IRI and IRI-IRI equivalences.
>> 
>> Do you mean owl:sameAs ? 
> 
> I mean that every IRI could be the same unless explicitly stated to be different. Given a value set violation like:
> 
>  <p1> rdfs:range :ValueSet1 .
>  :ValueSet1 owl:oneOf ( <V1> <V2> ) .
>  <x> <p1> <V3> .
> 
> OWL nods blondly and concludes that <V3> must equal either <V1> or <V2>. We must convince it otherwise to make this violation detectably inconsistent:
> 
>  [] owl:allDistinct ( <V1> <V2> <V3> ) .

Right. But this is OWL reasoning about the denotations of the IRIs. not the *identity* of the IRIs. It does not think that ex:V1 is the **same IRI** as ex:V2.  RDF semantics does the same exact thing, but RDF doesn't proivide any way to say it. 

Pat


>>> In the middle, we have RDF Semantics which keeps all IRIs distinct but
>>> includes BNode equivalence (and hence a notion of graph leaning).
>>> 
>>> Does anyone actually *use* RDF Semantics, or is it only used as a
>>> foundation for OWL?
>> 
>> Seems to me that all anyone really needs to grok is what is said in section 5.2:
>> 
>> An RDF graph is true exactly when:
>> 
>> 1. the IRIs and literals in subject or object position in the graph all refer to things,
>> 
>> 2. there is some way to interpret all the blank nodes in the graph as referring to things,
>> 
>> 3. the IRIs in property position refer to binary relationships,
>> 
>> 4. and under these interpretations, each triple S P O in the graph asserts that the thing referred to as S, and the thing referred to as O, do in fact stand in the relationship referred to by P.
>> 
>> And maybe the RDFS inference patterns in 9.2.1, which are sometimes handy.
>> 
>> Pat
>> 
>> PS. I love the idea that RDF semantics is a "foundation" for OWL. 
>> 
>>> 
>>> 
>>>>   - Sandro
>>>> 
>>>>> --Gavin
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Pat
>>>>>> 
>>>>>>> 
>>>>>>> peter
>>>>>>> 
>>>>>>> On Thu, Jun 20, 2013 at 9:11 AM, Pat Hayes <phayes@ihmc.us> wrote:
>>>>>>>> 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
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> -- 
>>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>>> 
>>> 
>>> -- 
>>> -ericP
>>> 
>>> 
>> 
>> ------------------------------------------------------------
>> 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
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> -ericP
> 

------------------------------------------------------------
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 Saturday, 22 June 2013 01:15:06 UTC