- From: Bob Ferris <zazi@elbklang.net>
- Date: Thu, 01 Jul 2010 10:39:26 +0200
- To: Pat Hayes <phayes@ihmc.us>
- CC: Ross Singer <rossfsinger@gmail.com>, Hugh Glaser <hg@ecs.soton.ac.uk>, Robert Sanderson <azaroth42@gmail.com>, Linked Data community <public-lod@w3.org>, Semantic Web <semantic-web@w3.org>
Hello everybody, I think the main issues are already discussed. Hence, here are some summarized notes of my thoughts: 1. We shouldn't propagate that a user (always a machine or human beeing) has to go this way and not the other one. Leaving this decision by the user, leads to more user satisfaction (that's a natural point of view in my mind). That means a inverse relation should exist at every time. If a inverse relation includes a new meaning, e.g. 'child' inverse relation of 'father', than we should define this property explicitly. If not than we should define at least an anonymous inverse property (as also discussed here[1]). The outcome is, that an engine, which processes the statement to the knowledge base, should always be able to resolve incomming statement. If the statement isn't in the form as it can be store in the knowledge base (I think it is better to not store statements of an anonymous inverse property), than the engine has to transform it into the valid form (maybe its even enough to store one way and calculate the inverse relation(s)). (If the machines haven't the calculation power yet, then they will have it at least in the near future) 2. We wouldn't write back some literals, if we wouldn't know their context, e.g. changing a name of a person, wouldn't happen, if we don't know the person (the identifier of that person). That means we have always a context. 3. I really don't understand the decision between datatypes and individuals (and their disjointness as Michael Schneider point it out; maybe it's a bit naive point of view, or that I haven't such deep knowledge about really understanding DL). What about handling (datatyped) literals as in-built individuals, e.g. a string typed literal would be then internally resolved to an ex:String individual. We could reuse the well-defined xsd datatypes etc. 4. Don't believe the JSON hype ;) However, feel free to design a good Semantic Graph serialisation format based on JSON. JSON looks better than XML. N3 looks also better than XML. Currently, we have already a a very good Semantic Graph serialisation format based on N3. Why not hyping this one? ;) Cheers, Bob [1] http://www.semanticoverflow.com/questions/1126/when-should-i-use-explicit-anonymous-defined-inverse-properties Am 01.07.2010 05:14, schrieb Pat Hayes: > > On Jun 30, 2010, at 8:14 PM, Ross Singer wrote: > >> I suppose my questions here would be: >> >> 1) What's the use case of a literal as subject statement (besides >> being an academic exercise)? > > A few off the top of my head. > > 1. Titles of books, music and other works might have properties such as > the date they were registered, who owns them, etc.. > 2. Dates may have significant properties such as being the day that > someone was shot or when war broke out. > 3. Dates represented as character strings in some known date format > other than XSD can be asserted to be the same as a 'real' date by > writing things like > > "01-02-1481" sameDateAs "01022010"^^xsd:date . > "01-02-1481" isDateIn :MuslimCalendar . > > I am sure that you can think of many more. In general, allowing strings > as subjects opens the door to a wide range of uses of RDF to 'attach' > information to pieces of text. Another example which occurs to me: this > piece of text is the French translation of that piece of text, expressed > as a single RDF triple with two literals. > > 4. It has been noted that one can map datatyping into RDF itself by > treating the datatypes as properties, and there are several use cases > for this. The natural way to do it involves having literals as subject, > since the dataype map goes from the string to the value: > > "23" xsd:number "23"^^xsd:number . > > 5. Also, allowing this "purely academically" has the notable advantage > of simplifying RDF(S) inferencing, including making the forward-chaining > rules simpler. Right now, there is a strange oddity involving blank node > instantiations. One can say things like 'the number of my children is > prime" by using an blank node: > > :PatHayes hasNumberOfKids _:x . > _:x :a :PrimeNumber . > > But this legal RDF can't be instantiated in the obvious way: > > :PatHayes hasNumberOfKids "3"^^xsd:number . > "3"^^xsd:number :a "PrimeNumber . XXXX > > This trips up RDFS reasoners, which can often produce inferences by a > kind of sneaky use-a-bnode-instead maneuver even when the obvious > conclusion cannot be stated because of the restriction. (There are a few > examples in the RDF semantics document.) Removing the restriction would > enable reasoners to work more efficiently with a smaller set of rules. > (I gather that at least some of the RDFS rule engines out there already > do this, internally.) > >> 2) Does literal as subject make sense in "linked data" (I ask mainly >> from a "follow your nose" perspective) if blank nodes are considered >> controversial? > > Seems to me that from the linked data POV, anything that can be an > object should also be useable as a subject. Of course, that does allow > for the view that both of them should only ever be IRIs, I guess. > > Pat Hayes
Received on Thursday, 1 July 2010 08:40:10 UTC