- From: Stephane Fellah <fellahst@gmail.com>
- Date: Thu, 1 Jul 2010 11:58:17 -0400
- To: Robert Sanderson <azaroth42@gmail.com>
- Cc: Pat Hayes <phayes@ihmc.us>, 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>
- Message-ID: <AANLkTilPoEE4ncV7t3tyewN82mbSF6TVfsypvJWcSHVf@mail.gmail.com>
Hi, I just want to throw my 2 cents in this discussion. I posted a comment in October 2004 related to "Smart Literal"proposal in Jena Discussion Group. http://tech.groups.yahoo.com/group/jena-dev/message/11581 Best regards Stephane Fellah smartRealm LLC <http://tech.groups.yahoo.com/group/jena-dev/message/11581> On Thu, Jul 1, 2010 at 11:12 AM, Robert Sanderson <azaroth42@gmail.com>wrote: > > > 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:58:57 UTC