W3C home > Mailing lists > Public > public-rdf-comments@w3.org > June 2013

Re: [RDF-CONCEPTS] Skolemization

From: Ivan Herman <ivan@w3.org>
Date: Sun, 16 Jun 2013 12:22:26 +0200
Message-ID: <51BD91E2.7050504@w3.org>
To: Niklas Lindström <lindstream@gmail.com>
CC: Pat Hayes <phayes@ihmc.us>, David Booth <david@dbooth.org>, public-rdf-comments <public-rdf-comments@w3.org>
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:-(

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



Received on Sunday, 16 June 2013 10:22:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:57 UTC