Re: Subjects as Literals

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