- From: Steve Harris <steve.harris@garlik.com>
- Date: Sat, 26 Mar 2011 23:23:00 +0000
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Sandro Hawke <sandro@w3.org>, semantic-web@w3.org
On 2011-03-26, at 21:24, Pat Hayes wrote: > > On Mar 26, 2011, at 4:40 AM, Steve Harris wrote: > >> The only challenge with Option 5 is what to do when you encounter a pre-skoemised bNode in the wild. > > ??? Nothing. That is, you treat it just like any other URI in RDF. Which I thought was a large part of the point of having them in the first place. (What did you think one should 'do'?) Well that would depend on scope decisions, without having it in user's hands it's hard to know what's the correct behaviour. >> Consumers might wish to remint IDs for them with their own UUID, to help users map from UUIDs to sources. > > Aaaargh. No, that would be an ERROR. It would not be any more valid that swapping out any other URI for one of your own choosing. Fair enough. It would break people attempt to map UUIDs to data sources though. Not necessarily a bad thing. - Steve >> This is what happens with unskolemised bNodes now, in practice. That behaviour would be slightly odd on a random sub-set of tag: URIs, not a huge problem, just odd. I guess we could explicitly forbid reminting skolemised bNodes, but I can think of good reasons for doing it. >> >> - Steve >> >> On 2011-03-25, at 18:23, Pat Hayes wrote: >> >>> Option 5 (which I guess I was kind of assuming in the background) just use your tag scheme without any further additions. >>> >>> The trouble with 4 is, how to ensure that accidental coincidences don't happen (ie are sufficiently rare that they can be tolerated). People will just put the magic in a URI and re-use it over and over. The tag: scheme is a very clever way to avoid this hole, and you have already done all the hard work, so why not use it? >>> >>> BTW, I think that skolem URIs should NOT be dereferencable, as a matter of design. If you want to put a 'real' URI name in there, you always have that option: but then (for example) changing it will make a non-equivalent graph (as it should). >>> >>> However, just occurred to me that according to http-range-14, these URIs ought to return a 303. Which leads me to the idea that they ought to always have a hash in them, to avoid this tarpit. So they are URIrefs, not URIs. >>> >>> Pat >>> >>> On Mar 25, 2011, at 11:57 AM, Sandro Hawke wrote: >>> >>>> On Fri, 2011-03-25 at 16:01 +0000, Steve Harris wrote: >>>>> On 2011-03-25, at 15:41, Pat Hayes wrote: >>>>>> >>>>>> On Mar 25, 2011, at 10:05 AM, Sandro Hawke wrote: >>>>>> >>>>>>> Thanks for the detailed answer, but I'm pretty sure you're answering a >>>>>>> different question than I meant. (Sorry for not being more clear.) >>>>>>> What I meant was: is OWL 2 Full okay with people Skolemizing ontologies >>>>>>> they are asserting? >>>>>>> >>>>>>> I might be misunderstanding, but it seems like all the problems you >>>>>>> point out only arise during the entailment check. And yes, I know you >>>>>>> can't Skolemize a query. I would never even think about doing that. >>>>>>> I'm just talking about Skolemizing assertions. >>>>>>> >>>>>>> I think its general best to do queries in a query language and/or a rule >>>>>>> language, but maybe that's a matter of taste. >>>>>>> >>>>>>> You say, "you never know how someone will use your graph", so I guess >>>>>>> the point is that Alice might publish an ontology that gets Skolemized >>>>>>> by her system, and then Bob publishes an identical ontology, and then >>>>>>> when Charlie comes along and wants to find out whether Bob and Alice's >>>>>>> ontologies entail each other, he's going to get a false negative because >>>>>>> of the Skolemization. >>>>>> >>>>>> We can probably even fix this, in fact. If we can reliably distinguish 'bnode URIs' from other URis, eg if they all use a common namespace, then there is an obvious notion of graph equivalence which allows a 1:1 replacement of the skolem URIs. And then Charlie can discover that, though not logically equivalent, Alice and Bob's graphs are graph-equivalent. People will write code to check things like this if it ever starts to matter to anyone. The cost of testing this is identical to the cost of checking graph equivalence right now (its the same algorithm.) >>>>> >>>>> Exactly. >>>>> >>>>> In triplestores I'm familiar (admittedly not that many) with bNodes are skolemised into a value space that's different from both literals and URIs, so this is a natural consequence. >>>> >>>> So, is there a simple way we can flag them? I know it's out of scope >>>> for the RDF WG to define one, but maybe there's a solution that's so >>>> simple everyone can just start doing it without a W3C process. >>>> >>>> Strawman 1: make new URI scheme for this >>>> >>>> Con: very hard to do. (It took me and Tim Kingberg 4+ years to get the >>>> "tag:" URI scheme RFC published. Hopefully it's gotten much easier, but >>>> still I'm hesitant.) >>>> Con: it wouldn't be a link for linked data >>>> >>>> Strawman 2: use urn:uuid:<uuid> >>>> >>>> Con: there might be some false-positives, because of people using UUIDs >>>> who don't mean them like this >>>> Con: might be longer than necessary >>>> Con: no helpful human-readable element >>>> Con: no link for linked data >>>> >>>> Strawman 3: use tag:w3.org,2000:Skolem:<some optional >>>> text>:<uuid> >>>> >>>> Con: no link for linked data >>>> Con: might be longer than necessary >>>> >>>> Strawman 4: use any IRI with some magic string in it, like >>>> "SkBNode" or "$+SKNB+$". >>>> >>>> Con: some false positives, as magic string may appear in a few IRIs >>>> where it was not intended (such as blog posts about the concept, which >>>> use it in the title, or other naive machine generated URLs). >>>> >>>> For me, the clear winner is Strawman 4, because I really like being able >>>> to dereference stuff, even if it's a Skolem constant. This allows the >>>> Skolemizer to provide web service if it wants to. You can also use 4 >>>> with a tag: URI if you don't want to support dereference. >>>> >>>> -- Sandro >>>> >>>> >>>> >>>> >>> >>> ------------------------------------------------------------ >>> 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 >>> >>> >>> >>> >>> >> >> -- >> Steve Harris, CTO, Garlik Limited >> 1-3 Halford Road, Richmond, TW10 6AW, UK >> +44 20 8439 8203 http://www.garlik.com/ >> Registered in England and Wales 535 7233 VAT # 849 0517 11 >> Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD >> >> > > ------------------------------------------------------------ > 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 > > > > > -- Steve Harris, CTO, Garlik Limited 1-3 Halford Road, Richmond, TW10 6AW, UK +44 20 8439 8203 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Saturday, 26 March 2011 23:23:46 UTC