Re: Subjects as Literals

Great - more crystallization of the problem.

On 01/07/2010 02:14, "Ross Singer" <rossfsinger@gmail.com> 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)?
I would have thought the same as a use case for a literal as object.
I want to say:
"Semantic Web Revisited" foo:isTitleOf bar:somePaper
Why should I be forced to say
bar:somePaper dcterms:hasTitle "Semantic Web Revisited"
? Seems pretty arbitrary to me.
> 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?
> 
> Question #2 isn't coming from some Linked Data Uber Alles mindset,
> merely if this is in public-lod's scope at all...
Ah, this is the "identifier" issue.
I see no reason why the identifier of something has any relation to whether
that URI is the subject of a triple, which is, I think, some of the
confusion that is going on.
In a common Linked Data world, if someone tries to resolve a URI, then they
get back something like a SCBD (Symmetric Concise Bounded Description),
which is the known triples that have that URI as Subject or Object (but may
be extended by blank nodes).
So I think that Linked Data people find it hard to see why the subject has
type restriction to Resource. I certainly do.
In such a world, literal as subject makes perfect sense.
On the other hand, if the 3rd principle of Linked Data ("return something
useful on resolution") is implemented in some RDF system as CBD, where the
triples that have that URI as subject are the only ones returned, then the
problems people are worrying about occur.
But I think it is a long time ago that Linked Data people moved to the
Symmetric world as the information that agents want to see returned on URI
resolution.

Best
Hugh
> 
> -Ross.
> 
> On Wed, Jun 30, 2010 at 5:24 PM, Hugh Glaser <hg@ecs.soton.ac.uk> wrote:
>> Good post - gets to my (mis?)understanding of what is the problem.
>> 
>> On 30/06/2010 21:54, "Robert Sanderson" <azaroth42@gmail.com> wrote:
>> 
>>> 
>>> I have to add my 2 cents here.
>>> 
>>>>> However, if you see some specific harm in permitting statements about
>>>>> literals, please tell us what that harm would be.
>>> 
>>> The specific harm that I would see is that statements would be made about
>>> literals given some particular context of that literal, rather than in a
>>> global scope.
>>> 
>>> For example:
>>> 
>>> "London" rdf:type geo:City
>> This seems strange to me.
>> I would expect "London" to have a type of string.
>>> "London" dcterms:isPartOf "England"
>> Again, this seems strange, especially as dcterms says:
>> "This term is intended to be used with non-literal values"
>> I note with interest the plural of values.
>>> 
>>> That is true only for the particular London which is the capital of England,
>>> not London, Texas, London, Ontario or London in Kiribati.
>> But the string is not the NIR.
>>> 
>>> Now the global graph gets very confused when the subjects are merged, and
>>> this
>>> 'London' is in four different countries at once.
>> But why does the graph have to merge the subjects because they have the same
>> string value, any more than the objects would be merged if they have the
>> same string value?
>> 
>> I agree it is a bit strange to have strings as both subject and object, as
>> the graph is not joined up very much, but it is still a bit of graph that
>> says something that someone might find interesting.
>>> 
>>> The only globally true statements about literals are rather dull:
>>> 
>>> "London" numberOfCharacters 6
>> But is this objection not that same as saying that the only interesting
>> thing one can say is
>> 6 charactersIn "London" . ?
>> Or even
>> numbers:six charactersIn "London" .
>> Which is similar to
>> "London" numberOfCharacters numbers:six
>>> "London" firstCharacter "L"
>>> 
>>> For the few use cases where it would be interesting to say something that is
>>> globally true about a literal, a URI can easily be assigned. Be that a UUID
>>> or
>>> an HTTP URI which returns the literal when dereferenced.
>> But using literals as objects is also saying things that are true of
>> literals.
>> 
>> Cheers
>>> 
>>> 
>>> Rob Sanderson
>>> Los Alamos National Laboratory
>>> 
>>> 
>> 
>> 
>>

Received on Thursday, 1 July 2010 01:37:55 UTC