- From: Patrick J. Hayes <phayes@ihmc.org>
- Date: Sun, 4 Sep 2022 07:11:14 +0000
- To: Anthony Moretti <anthony.moretti@gmail.com>
- CC: David Booth <david@dbooth.org>, "semantic-web@w3.org" <semantic-web@w3.org>
- Message-ID: <8B6F7911-7F98-4D81-AF81-B28391E7F2B7@ihmc.org>
Hi Anthony OK, composite value types. ALong the lines of my previous emial, if we introduce these into RDF syntax then we have to give them a semantics (or openly declare that they have no semantics, which IMO would be a serious mistake). So what DO they mean? Can you explain? The truth conditions for the triple :JoeBiden :hasAddress {@type: :Address, streetNumber: 1600, street: "Pennsylvania Avenue NW"} are that it is true in I just when IEXT(I(:hasAddress)) contains the pair <I(:JoeBiden), I({@type:….})>, so we need to be able to say what the value of the interpretation mapping is when applied to a composite value type. Is this related in any way at all to the denotations of IRIs inside that expression? Is it a new kind of object, distinct from other things that the RDF describes? If we want to have semantic constraints like 2/4=1/2 for fractions, we will need to have some kind of semantics at least for the 'recognized' composite types. In fact these look to me very like a generalization of datatyped literals, where the datatype might take several strings instead of just one. That would be a useful generalization in any case, and an easy extension to RDF without materially changing anything in the basic syntax. What slightly bothers me is that things like the :hasAddress case look to me like a shorthand for a bunch of triples with the same subject, itself being the encoding of a n-ary relation (in this case n=3: Joe, a number and a street name) whereas things like fractions and coordinates (and complex numbers, dates+times etc) seem more like one triple with a complex datatyped literal as the object. Which makes me suspect that there are two different semantics being applied to one syntax, which is almost always a bad idea. But perhaps I am worrying too much :-) Pat PS, In practice, addresses are way more complicated. See https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/ On Sep 2, 2022, at 1:51 AM, Anthony Moretti <anthony.moretti@gmail.com<mailto:anthony.moretti@gmail.com>> wrote: I think it might help to first break the problem into parts, and then the semantics question can be asked about each part separately. A holistic approach to adding a collection syntax might consist of: 1. Adding syntax for composite value types in the subject or object positions, which I've previously argued is missing from RDF. 2. Adding syntax for extensionally defined collections—which can be thought of as simply special cases of composite value types—in the subject or object positions. 3. Adding syntax for associating an IRI with a composite value type. Composite value types are useful for things like: * Addresses * Coordinates * Polygons * Fractions The components of the value are enough to uniquely identify the value, so an IRI is optional, and whether two values are equal or not depends upon a comparison operation that can be defined canonically for each type (for example, if we're talking about Fractions then 1/2 == 2/4 should be true). An example of (1) might be something like: :JoeBiden :hasAddress {@type: :Address, streetNumber: 1600, street: "Pennsylvania Avenue NW"} Once you have that, collections are a special case, so an example of (2) might be something like: :MichaelJordan :jerseyNumbers @set[23, 45] With a full composite value type, if there wasn't a special collection syntax, it might look something like: :MichaelJordan :jerseyNumbers {@type: :Set, 1: 23, 2: 45} In my opinion, composite value types are closed atomic concepts, they only make sense as a whole, therefore for collections described in the manner of (2), no entailment should occur across the boundary of the collection and there shouldn't be any semantics, and therefore the collection is also fully defined and closed. Examples of (3) might be something like: :s: @set[:b, :c, :d] :l: @list[:b, :c, :d] :cs: @closedSet[:b, :c, :d] :cl: @closedList[:b, :c, :d] In my opinion, for collections described in this way no such boundary exists, entailments can be made across the boundary of the collection to the members, but they can depend upon other things like the class that the collection itself belongs to etc. It's still definitely not the case that all things said about a collection should automatically be said about each member though. Anthony On Thu, Sep 1, 2022 at 11:52 PM Patrick J. Hayes <phayes@ihmc.org<mailto:phayes@ihmc.org>> wrote: > On Aug 16, 2022, at 11:20 AM, David Booth <david@dbooth.org<mailto:david@dbooth.org>> wrote: > > On 8/16/22 12:56, Holger Knublauch wrote: >> A next generation of RDF(-star) can hopefully get rid of rdf:Lists through reification with an index property. > > That sounds surprising, given the widespread dislike of reification. Do you have a pointer to an explanation? > > Incidentally, I personally think RDF should natively support lists, which David Wood and James Leigh proposed at the 2009 W3C RDF Next Steps workshop: > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2009%2F12%2Frdf-ws%2Fpapers%2Fws14&data=05%7C01%7Cphayes%40ihmc.us%7C0a77747beb0a409a1dd808da7fb4dc50%7C2b38115bebad4aba9ea3b3779d8f4f43%7C1%7C0%7C637962712068140669%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=t61SxH5CMAP%2Bt7jSbWCayCVpP3tAZfnRrPid8bTaZUw%3D&reserved=0<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2009%2F12%2Frdf-ws%2Fpapers%2Fws14&data=05%7C01%7Cphayes%40ihmc.org%7Ca636a943d73a44d3551d08da8cc0672b%7C2b38115bebad4aba9ea3b3779d8f4f43%7C1%7C0%7C637977055240479538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=z%2FodUcvc09wxAhkqDfaFiulCKbkTARVs%2BbuIr5w%2B6Kw%3D&reserved=0> OK, that proposes to make lists part of the RDF /syntax/. So a triple with a list as subject is now a syntactically legal RDF expression: [:a :b :c] :p :o . and this is now syntactically legal RDF. That was easy, but now this ball lands in my court as semantics editor. If this is legal RDF syntax, it has to mean something, has to have a semantics. What does it mean? How is it to be interpreted? Or, if you don't like the S-word, what does this new RDF 'listriple' entail? What can be inferred from it, and what is it inferrable from? For example, is this valid: from :a :p :o . :b :p :o . :c :p :o . infer [:a :b :c] :p :o . ? Or the reverse? How about from [:a :b :c] :p :o . infer [:a :c :b] :p :o . No? Because if you have the first one in both directions you can prove that this one is valid as well. And what if you have a list in both subject and object positions? Etc. Note, it is not enough to answer "sometimes" or "it depends". That kind of woolliness destroys the utility of RDF as an information exchange notation. If the answer depends on something else, then that something else has to also be somehow encoded into the RDF syntax, in order to disambiguate the list notation. The RDF WG could never agree on what the semantics of list syntax might be. And - a private observation of my own - the people who most wanted to put lists into the syntax were usually the same ones who insisted that they could not, or should not, be given a semantics. I suspect that this is because those folk are slipping into thinking of RDF as a kind of programming language rather than a descriptive logical language. Now, one can take a completely different view of lists (and other things like lists), which is that rather than having them as part of the syntax of RDF they should be some of the things that RDF describes, just as it is used to describe wine, consumer goods, animal species and everything else in the wonderful world of wikipedia. Then they don't have to be given an RDF semantcs because they are in the RDF semantics universe along with everything else. And that is what the WG decided to do. But given the relatively poverty of RDF as a descriptive language, it's impossible to put very tight constraints on what lists look like, so one gets the oddities described in https://www.w3.org/TR/rdf11-mt/#rdf-collections<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Frdf11-mt%2F%23rdf-collections&data=05%7C01%7Cphayes%40ihmc.org%7Ca636a943d73a44d3551d08da8cc0672b%7C2b38115bebad4aba9ea3b3779d8f4f43%7C1%7C0%7C637977055240479538%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2bgOi8au%2BMdAbQBbhdZlSPO%2B82btUdye54qYfIFaEvw%3D&reserved=0>. OK, just a small growl from the dugout. Anyone who advocates having lists in RDF syntax, please don't speak until you have at least a sketch of what they are supposed to mean, that you are willing to commit to. Pat Hayes
Received on Sunday, 4 September 2022 07:11:33 UTC