- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 21 May 2012 10:08:38 -0500
- To: Ivan Herman <ivan@w3.org>, Richard Cyganiak <richard@cyganiak.de>
- Cc: Steve Harris <steve.harris@garlik.com>, Guus Schreiber <guus.schreiber@vu.nl>, RDF WG <public-rdf-wg@w3.org>
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. 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. 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
Received on Monday, 21 May 2012 15:09:35 UTC