- From: Steve Harris <steve.harris@garlik.com>
- Date: Mon, 13 Aug 2012 19:13:37 +0100
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, Pat Hayes <phayes@ihmc.us>, "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>
On 13 Aug 2012, at 18:15, Gregg Kellogg <gregg@greggkellogg.net> wrote: > On Aug 13, 2012, at 2:20 AM, Steve Harris <steve.harris@garlik.com> wrote: > >> On 2012-08-12, at 02:26, Gregg Kellogg wrote: >> >>> On Aug 11, 2012, at 1:11 PM, Andy Seaborne <andy.seaborne@epimorphics.com> wrote: >>> >>>> >>>> >>>> On 11/08/12 19:40, Steve Harris wrote: >>>>> On 11 Aug 2012, at 18:02, Pat Hayes wrote: >>>>> >>>>>> >>>>>> On Aug 11, 2012, at 5:22 AM, Andy Seaborne wrote: >>>>>> >>>>>>> Hi Dan, >>>>>>> >>>>>>> On 11/08/12 07:46, Dan Brickley wrote: >>>>>>>> Hi Dave, >>>>>>>> >>>>>>>> On 10 August 2012 19:25, Dave Beckett <dave@dajobe.org> wrote: >>>>>>>>> Dear RDF Working Group >>>>>>>> >>>>>>>> (Just a personal response here) >>>>>>> >>>>>>> Ditto. >>>>>>> >>>>>>>> Agreed. This is a niche topic, but I still now thing it is of >>>>>>>> occasional use. >>>>>>>> >>>>>>>> In particular, as a maintainer/editor/contributor for popular >>>>>>>> RDF vocabularies (FOAF, schema.org and others) I believe there >>>>>>>> is implicit demand for this which is often expressed instead in >>>>>>>> terms of requests for new inversely named properties. Whenever >>>>>>>> someone asks a vocabulary maintainer to add 'isDirectorOf' >>>>>>>> alongside 'director', or asks what the inverse of 'actor', or >>>>>>>> 'associatedAnatomy' or 'depicts' is, they are talking about >>>>>>>> just this issue. >>>>>>> >>>>>>> For those people, do you think "^" will read acceptable to those >>>>>>> people? (Your point about "isXof" not always being the best >>>>>>> choice of name is also interesting.) >>>>>>> >>>>>>>>> 3. It is not in SPARQL's data syntax. 4. There is a high bar >>>>>>>>> to add a new feature to an existing, well understood and >>>>>>>>> implemented language like Turtle. This feature does not fit >>>>>>>>> that in my judgement. >>>>>>>> >>>>>>>> Taking those two together, ... >>>>>>>> >>>>>>>> I only support adding such a construct if it has a comparable >>>>>>>> notation in SPARQL. They might not be 100% identical, but the >>>>>>>> basic concept ought to either be in both, or in neither. Turtle >>>>>>>> and SPARQL share a common heritage in N3; if we can make >>>>>>>> teaching them (Turtle and SPARQL; I consider N3 something like >>>>>>>> a "Labs project") easier by sharing structure and ideas, we >>>>>>>> ought to. >>>>>>> >>>>>>> A difference between "^:directory" (or the "is...of" syntax) and >>>>>>> a property :isDirectorOf is that the "^" solution immediately >>>>>>> does the reversing of the written subject and written object. >>>>>>> >>>>>>> :Ridley_Scott ^:director :Blade_Runner >>>>>>> >>>>>>> leading to a possible unexpected situation later: >>>>>> >>>>>> POSSIBLY unexpected. If someone were under the illusion that the >>>>>> caret syntax created a new property, they would be surprised or >>>>>> disappointed at this point. The answer, surely, is to take pains, >>>>>> in writing the documentatio, to explain carefully that it does not >>>>>> do this. Your example would be a good one to use is such a >>>>>> tutorial, for example. But the fact that a feature MIGHT be >>>>>> surprising to someone who DIDNT read the tutiorials and does not >>>>>> understand it, it surely not a good argument for not including it. >>>> >>>> I'm undecided about this feature; I haven't seen a complete proposal >>>> yet. There is not absolute argument one way or the other that I've seen >>>> and it seems to come down to a value judgement. >>>> >>>> What does not work for me in this case is the argument like >>>> >>>> Use Case -> feature solves Use Case -> include feature. >>> >>> Case #1 >>> >>> For one thing, it would mean that a Turtle serialization of a SPARQL DESCRIBE (at least one using a Concise Bounded Description) could be generated with a single "subject". For a describe of :gregg in the graph >>> >>> :gregg foaf:knows :andy . >>> : andy foaf:knows :gregg . >>> >>> could be serialized as >>> >>> :gregg foaf:knows : andy; ^foaf:knows :danbri . >> >> Not really relevant to your point but a CBD doesn't include statements where the described URI is the object. http://www.w3.org/Submission/CBD/#definition > > No, not for IRIs, but step 2 does this for BNodes, including the subjects which reference them as objects. So, yes, my example doesn't strictly adhere to this, but a BNode variant would > > :gregg foaf:knows _:someone; ^foaf:knows _:someone . Not by my reading of step 2, it says where the bNodes is the subject of the triple. Anyway, it's somewhat irrelevant! - Steve > That said, even though I've brought forth some potential use cases, I don't feel strongly about including inverse properties myself. I'm probably a +0.5. > > Gregg > >> It's a good example of how this type of thing can be used to reduce the number of bytes needed to write a chunk of RDF though. >> >>> Case #2 >>> >>> The second scenario I've seen is where several resources need to be declared as having the same type. >>> >>> foaf:Person ^a :gregg, : andy . >>> >>> Personally, I prefer is..of, and suggest that we include that as syntactic suggar: >>> >>> foaf:Person is rdf:type of :gregg, :andy >>> >>> Reads much better. (Not so much in the first use case). >> >> Ditto. >> >> - Steve >> >> -- >> Steve Harris, CTO >> Garlik, a part of Experian >> +44 7854 417 874 http://www.garlik.com/ >> Registered in England and Wales 653331 VAT # 887 1335 93 >> Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ >> >
Received on Monday, 13 August 2012 18:14:10 UTC