W3C home > Mailing lists > Public > semantic-web@w3.org > July 2010

Re: Subjects as Literals

From: Bob Ferris <zazi@elbklang.net>
Date: Thu, 01 Jul 2010 10:39:26 +0200
Message-ID: <4C2C543E.4050403@elbklang.net>
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 
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 
(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? ;)




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:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:11 UTC