- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Thu, 1 Jul 2010 09:12:09 -0600
- 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>
- Message-ID: <AANLkTilSq7haxnJFlK8ZKIu7kBHRX1Rbe--L__mJjcE8@mail.gmail.com>
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:40 UTC