- From: Ivan Herman <ivan@w3.org>
- Date: Mon, 21 May 2012 17:53:27 +0200
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Richard Cyganiak <richard@cyganiak.de>, Steve Harris <steve.harris@garlik.com>, Guus Schreiber <guus.schreiber@vu.nl>, RDF WG <public-rdf-wg@w3.org>
On May 21, 2012, at 17:08 , Pat Hayes wrote: > OK. > > Just to get the ball rolling, try this for size. > > Two literals "string1"^^Thedatatype "string2"^^Thedatatype are D-equivalent when: > Thedatatype is in D > and > L2V(Thedatatype)(string1) = L2V(Thedatatype)(string2) > > Then two graphs G1 and G2 are LV-equivalent with respect to D, or D-LV-equivalent, when there is a mapping M between D-equivalent literals such that G1=M(G2). > > Put into English, when the graphs are the same except that some literals may be replaced by others having the same datatype and the same value under their datatype. > > Note, M does not have to be 1:1. so for example it is OK to normalize several forms to one normalized form, eg "02"^^xsd:number and "00002"^^xsd:number both to "2"^^xsd:number. > > This does not use the 'entailment' route I suggested earlier, which I now see could introduce odd corner cases for some datatypes. This is more like a weakened form of graph isomorphism, restricted simply to substituting one literal form for another when they have the same semantic value. > Reads well... :-) > Question. Suppose two different datatypes have the same value for some strings. For example, suppose "2"^^xsdd:evenNumber = 2 = "2"^^xsd:number. Do we want to allow a substitution that changes the literal datatype in such cases? The above does not allow this, but it could be easily changed to allow it. > I presume, technically, what can we done is: "string1"^^Thedatatype1 "string2"^^Thedatatype2 are D-equivalent when: - Thedatatype1 and Thedatatype2 are in D - Thedatatype1 = Thedatatype2 or, say, Thedatatype is a derived datatype by restriction of Thedatatype2 = L2V(Thedatatype2)(string1) = L2V(Thedatatype2)(string2) where XSD says: [Definition:] A datatype is said to be ·derived· by restriction from another datatype when values for zero or more ·constraining facet·s are specified that serve to constrain its ·value space·and/or its ·lexical space· to a subset of those of its ·base type·. we can of course refer to the 'derived by restriction' definition of XSD, we do not have to define it by ourselves. That being said, I am not 100% sure we want that. I have the impression that by doing so we loose some information in making these graphs equivalent. Ie, I am a bit undecided at the moment... Ivan > Pat > > > On May 20, 2012, at 4:40 AM, Ivan Herman wrote: > >> I does look sensible to me to define this 'LV' entailment… >> >> >> -- >> Ivan Herman, W3C Semantic Web Activity Lead >> http://www.w3.org/People/Ivan/ >> mobile: +31-641044153 >> FOAF: http://www.ivan-herman.net/foaf. (http://www.ivan-herman.net/foaf.rdf)ttl >> >> Sent with Sparrow (http://www.sparrowmailapp.com/?sig) >> >> >> On Sunday, May 20, 2012 at 03:46 , Pat Hayes wrote: >> >>> >>> On May 18, 2012, at 6:44 AM, Richard Cyganiak wrote: >>> >>>> On 18 May 2012, at 12:16, Steve Harris wrote: >>>>>>>> I have hit a problem today, when implementing the HTML literal in my RDFa distiller software. The problem is that the underlying library does not give me a method whereby I can take the original file's element content from its corresponding DOM node and dump it into a string (that can be used for the RDF Literal). (Technically, the library does not implement the innerHTML attribute on the DOM Element Node.) I can only take the content and dump it into a string in full XML syntax. >>>>>>>> >>>>>>>> So, for example, if I have, in HTML5+RDFa: >>>>>>>> >>>>>>>> <div property="ex:something" datatype="rdf:HTML"><p>Inner</div> >>>>>>>> >>>>>>>> then the only way I can generate an HTML Literal is >>>>>>>> >>>>>>>> <> ex:something "<p>Inner</p>"^^rdf:HTML . >>>>>>>> >>>>>>>> Another library used by another tool may have the necessary method. For the same RDFa fragment it can generate: >>>>>>>> >>>>>>>> <> ex:something "<p>Inner"^^rdf:HTML . >>>>>>>> >>>>>>>> With the current definition of the HTML Literal both RDFa tools are correct and compliant: the HTML Literals, though lexically different, are identical in terms of the generated DOM, based on the HTML5 specification. Ie, if a triple store implements the identity in the value space, there would be no duplication of triples if both tools dump their content into the same space. If only lexical identity is available then... it becomes messy. >>>>>>> >>>>>>> Sure, but what usecase do you have for being able to want to compare these - even though though lexically different - semantically? >>>>>> >>>>>> Test suites for HTML5+RDFa parsers. >>>>> >>>>> Surely there you'd "just" need a graph isomorphism test? >>>> >>>> No, implementing an HTML5+RDFa parser that produces an isomorphic graph is often impossible, as Ivan explained in the text quoted above. >>>> >>>>> You don't care if the input documents are semantically equivalent? >>>> >>>> A test suite for HTML5+RDFa parsers would likely say that a conforming parser MUST generate an RDF graph that is isomorphic to the test case graph, except that literals MAY be replaced by other literals of equal value. >>>> >>>> (In a perfect world, RDF Semantics would define something like LV-Entailment (literal value entailment) that captures this notion. So one could say that an HTML5+RDFa parser MUST generate a graph that is LV-equivalent to the test case graph.) >>> >>> We could easily define this. It would be based on a version of D-entailment but added to simple entailment rather than RDFS-entailment, and then equivalence is simply entails-and-entailed-by, in the usual way. Of course what you get would depend upon which D you were assuming. >>> >>> If you really think this is worth doing, by all means make it an action item on the Semantics editors. >>> >>> Pat >>> >>>> >>>> Best, >>>> Richard >>>> >>>> >>>> >>>>> >>>>> - Steve >>>>> >>>>> -- >>>>> Steve Harris, CTO >>>>> Garlik, a part of Experian >>>>> 1-3 Halford Road, Richmond, TW10 6AW, UK >>>>> +44 20 8439 8203 http://www.garlik.com/ >>>>> Registered in England and Wales 653331 VAT # 887 1335 93 >>>>> Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ >>>> >>> >>> >>> >>> ------------------------------------------------------------ >>> 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 > > > > > ---- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Monday, 21 May 2012 15:50:32 UTC