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

Re: Subjects as Literals

From: Henry Story <henry.story@gmail.com>
Date: Thu, 1 Jul 2010 11:37:12 +0200
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>
Message-Id: <769BA1ED-A3C2-479D-AA56-255B2A341A06@bblfish.net>
To: Pat Hayes <phayes@ihmc.us>
+1 to the points below.

I think one should point out that rdf semantics allows them, and that in an open world they
just can't be excluded.

In N3 literals as subjects are often used. And the cwm repository is a good place to look
for examples

@prefix log: <http://www.w3.org/2000/10/swap/log#>.

    rdfs:comment "The subject string, parsed as N3, gives this formula."

see many of the relations described in http://www.w3.org/2000/10/swap/doc/CwmBuiltins,
especially the maths ones.

relations between text and its md5 hash, which is used in some of the code in 

I think it would also simplify the prgrammatic apis, such as Java. 

It is perhaps not the most urgent thing to do, but putting it on the seriously todo list
would perhaps help people start shifting the tools to supporting them. 


On 1 Jul 2010, at 05:14, Pat Hayes wrote:

> 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 09:37:49 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:18 UTC