Re: [RDF-CONCEPTS] Skolemization

* Ivan Herman <ivan@w3.org> [2013-06-16 12:22+0200]
> I have not looked at the text right now (I am on a mobile), and that may be good
> at this moment, because it shows what I remember the intention was...
> 
> I guess the question of David could/should be boiled down to: is the
> Skolemization part normative or not? I think we never meant that to be normative
> in the group; if it says so in the document, that is a mistake (Pat already
> alluded to that). If it is non normative, then the usage of an RFC MUST would
> become fairly meaningless... Is there any reason we would make it normative?
> This request never came up in the group before; the whole skolemization was
> presented as a good practice to follow if one wants to get rid of bnodes when
> exchanging graphs.
> 
> (Systems may skolemize for any other reason, eg, for internal purposes or
> exchanging data with other instantiation of the same software only, and they may
> decide to use some sort of a UUID based URI which would be just as fine. If we
> set a 'must' for the genid way, then a UUID based skolemization might be
> considered as illegal:-(

I think one of Pat's points, with which I agree, is that definitions
don't have RFC2112 keywords. Definitional specs e.g. SPARQL Query,
don't even reference RFC2119.


> Ivan
> 
> 
> 
> 
> 
> Niklas Lindström wrote:
> > 
> > 
> > On Sun, Jun 16, 2013 at 5:25 AM, Pat Hayes <phayes@ihmc.us
> > <mailto:phayes@ihmc.us>> wrote:
> > 
> > 
> >     On Jun 15, 2013, at 9:38 PM, David Booth wrote:
> > 
> >     >
> >     > similarly the definition of RDF skolemization needs to be normative, with
> >     conformance terms, for the exact same reason.
> >     >
> >     > if someone transformed
> >     >
> >     >  _:b :foo :bar .
> >     >
> >     > into
> >     >
> >     >  :bar :foo :bar .
> >     >
> >     > then they should be prohibited from calling it RDF skolemization, just as
> >     people are currently prohibited from calling the following RDF:
> >     >
> >     >  "literal" _:bnode  "oops" .
> > 
> >     Its not about calling things names.
> > 
> > 
> > 
> >> Its not about calling things names.
> > 
> > To me, that's exactly what it is. The sentence David has a problem with is:
> > 
> >     "Systems wishing to do this SHOULD mint a new, globally unique IRI (a Skolem
> > IRI) for each blank node so replaced."
> > 
> > Because, in his reading (IIUC), the first "this" is bound to "skolemization".
> > The question is only if this is the case. If it is, David is right, because
> > skolemization is, by definition, "mint a new, globally unique IRI (a Skolem IRI)
> > for each blank node so replaced". So to do skolemization, you MUST do
> > skolemization. However, the sentence preceding the one above in the spec is:
> > 
> >     "In situations where stronger identification is needed, systems may
> > systematically replace some or all of the blank nodes in an RDF graph with IRIs."
> > 
> > It can be argued that this binds the "this" in question to "replace some or all
> > of the blank nodes in an RDF graph with IRIs". And, as Pat has elaborated on,
> > this act in itself has no requirements which are relevant to specify in this
> > context.
> > 
> > In either case, as this discussion is evidence of, something should probably be
> > done to the spec text to clarify what is actually required, and under which
> > conditions.
> > 
> > Cheers,
> > Niklas
> > 
> >  
> > 
> >     They can *call* that RDF all they like, but a conforming RDF engine will
> >     spit it out, is the point. But there isn't anything about skolemization that
> >     engines are required to do or prohibited from doing. They can do it, or not;
> >     and they can do other things, or not. If someone says their engine is doing
> >     skolemization when it isn't, then they are wrong, which can be checked by
> >     looking at the definitions. But just because their own tray tables are not
> >     in the fully upright and locked position does not make their RDF engine
> >     nonconformant.
> > 
> >     Pat
> > 
> > 
> >     >
> >     > David
> >     >
> >     >
> >     >
> > 
> >     ------------------------------------------------------------
> >     IHMC                                     (850)434 8903
> >     <tel:%28850%29434%208903> or (650)494 3973 <tel:%28650%29494%203973>
> >     40 South Alcaniz St.           (850)202 4416 <tel:%28850%29202%204416>   office
> >     Pensacola                            (850)202 4440 <tel:%28850%29202%204440>
> >       fax
> >     FL 32502                              (850)291 0667
> >     <tel:%28850%29291%200667>   mobile
> >     phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 



-- 
-ericP

Received on Sunday, 16 June 2013 17:02:15 UTC