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

Re: Subjects as Literals

From: Robert Sanderson <azaroth42@gmail.com>
Date: Thu, 1 Jul 2010 09:12:09 -0600
Message-ID: <AANLkTilSq7haxnJFlK8ZKIu7kBHRX1Rbe--L__mJjcE8@mail.gmail.com>
To: Pat Hayes <phayes@ihmc.us>
Cc: Ross Singer <rossfsinger@gmail.com>, Hugh Glaser <hg@ecs.soton.ac.uk>, Linked Data community <public-lod@w3.org>, Semantic Web <semantic-web@w3.org>
On Wed, Jun 30, 2010 at 9:14 PM, Pat Hayes <phayes@ihmc.us> wrote:

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 .
>


This is a great example of what is wrong with the proposal! :)

Either, the literals stand by themselves and each occurrence of "01-02-1481"
is a completely separate instance (and in the current syntax would get a
unique identifier), or *all* occurrences of the literal can be conflated
together.  The distinction between a token and a type, respectively.

Option 1: Literal as Token
If each is its own token (unique identifiers) then one string is the same as
the date given, and a completely different string is in the Muslim
calendar.

eg:

urn:uuid1 hasValue "01-02-1481"
urn:uuid1 sameDateAs "01022010"^^xsd:date

urn:uuid2 hasValue "01-02-1481"
urn:uuid2 isDateIn :MuslimCalendar

This makes the proposal pointless, as you can't express two statements about
the same literal subject.  The only thing you can do is express the inverse
of existing properties... at the expense of complexity and the burden of
unnecessary choice. (title is easy as the only way to do it, adding
isTitleOf gains us nothing we couldn't already express)


Option 2: Literal as Type
However, if all occurrences of that string are the same entity and can be
merged together, then we also have:

"01-02-1481" sameDateAs "1481-02-01"^^xsd:date .    // ddmmyyyy
"01-02-1481" sameDateAs "1481-01-02"^^xsd:date .    // mmddyyyy
"01-02-1481" isDateIn :RomanCalendar

This also makes the proposal pointless as you cannot say anything meaningful
which is globally true about a literal.  That same string is at least three
different dates in two different calendars. Drat that pesky global truth
requirement!

The only way that Pat's example makes sense is if the context of the literal
is constrained to the current named graph.  If there was interest in
"fixing" RDF, then making Named Graphs a core feature would be my first
agenda item!

Rob Sanderson
Received on Thursday, 1 July 2010 15:12:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:20 UTC