Re: subjects as literals

[Nathan]

joel sachs wrote:
Wasn't this part of the summer's argument regarding literals as 
rdf:subjects , i.e.


.. and that ones easy,

If { a rel b } infers { b is rel of a }, and b can be a literal in the 
first statement, then b must also be a literal in the second statement.


Whether or not a specific dl or serialization supports the full set of 
statements that can be made, or a subset of those, is a different issue 
all together, a serialization of a dl, cannot determine the real world, 
it cannot assert that { "Joel" is the name of :joel } cannot be said, it 
can only confess that it doesn't provide a way to say that.


Best,

Nathan

URI declaration [was Re: Subjects as Literals]

[David Booth]

On Fri, 2010-07-09 at 08:45 +0200, Henry Story wrote: 
> On 8 Jul 2010, at 20:30, David Booth wrote:
> 
> > On Thu, 2010-07-08 at 11:03 -0500, Pat Hayes wrote:
> >> On Jul 6, 2010, at 9:23 PM, David Booth wrote:
> >> 
> >>> On Tue, 2010-07-06 at 20:45 +0200, Henry Story wrote:
> >>> [ . . . ]
>  foaf:knows a rdf:Property .
>  
>  Well we can dereference foaf:knows to find out what it means. This is
>  the canonical way to find it's meaning, and is the initial  
>  procedure we
>  should use to arbitrate between competing understandings of its  
>  meaning.
> >>> 
> >>> Right.  The document you get upon dereferencing -- the "follow your
> >>> nose" document -- acts as a URI declaration.[1]
> >>> 
> >>> 1. http://dbooth.org/2007/uri-decl/
> >> 
> >> Just to clarify, that is David's idea and his suggestion. It seems  
> >> like a sensible idea, in many ways. It seems to reflect some current  
> >> practice. But it is not part of the current RDF spec., and it is  
> >> controversial.
> > 
> > No, it was not my idea.  I cannot claim any credit for it.  The idea was
> > already around and in fairly common practice (though not universal) when
> > I first wrote it up in 2007.  I do not know who came up with it.  All I
> > did was write it up, give it a descriptive name "URI declaration" (so
> > that we could all refer to it more easily), and promote it.
> 
> The general idea is widely accepted, but the interpretation using speech
> acts is certainly original and controversial.

True, that particular explanation of how URI declaration works was my
idea.  But I'm not sure that that particular explanation is even needed
anyway.  In some sense the whole idea of a speech act is a convenient
simplification of reality, or a useful fiction.  What really matters is
that the community *believes* that publishing and using URI declarations
is the "right" way to do things (i.e., the preferred way, or best
practice), and acts accordingly, and this is happening already.

> There is also an issue that one can imagine conventions arising in other
> ways too btw...

Yes, that can happen.  That can lead to what I've been calling the
"competing definitions" approach to establishing URI resource identity,
and this paper on "Why URI Declarations? A comparison of architectural
approaches" explains why it is architecturally inferior to the URI
declarations approach:
http://dbooth.org/2008/irsw/


The section of "The URI Lifecycle in Semantic Web Architecture" on
"community expropriation" of a URI proposes guidelines for how to handle
that situation when it happens:
http://dbooth.org/2009/lifecycle/#expropriation 


-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Re: Show me the money - (was Subjects as Literals)

[Jeremy Carroll]

 On 7/11/2010 4:25 AM, Dave Reynolds wrote:


Jena, which Jeremy's software is based on, *does* allow literals as
subjects internally (the Graph SPI) and the rule reasoners *do* work
with generalized triples just as most such RDF reasoners do. However, we
go to some lengths to stop the generalized triples escaping. So the lack
of subjects as triples in the exchange syntax or the publicly
standardized model has had no detrimental impact on our ability to work
with them internally.


I have noticed similar points - a lot of reasoner based software, and 
graph internals software, and probably triple storage software will 
allow subjects as literals - but when considering systems and 
applications that actually do something useful (rather than just the 
internals) then you interface with people, and the difference between a 
literal and something else is crucial. This is where I see the costs.


Jeremy

Re: Show me the money - (was Subjects as Literals)

[Dave Reynolds]

On Thu, 2010-07-01 at 22:44 -0500, Pat Hayes wrote: 
> Jeremy, your argument is perfectly sound from your company's POV, but  
> not from a broader perspective. Of course, any change will incur costs  
> by those who have based their assumptions upon no change happening.  
> Your company took a risk, apparently. IMO it was a bad risk, as you  
> could have implemented a better inference engine if you had allowed  
> literal subjects internally in the first place, but whatever. 

I've tried to be quiet but I couldn't let this dig slide by ... 

Jena, which Jeremy's software is based on, *does* allow literals as
subjects internally (the Graph SPI) and the rule reasoners *do* work
with generalized triples just as most such RDF reasoners do. However, we
go to some lengths to stop the generalized triples escaping. So the lack
of subjects as triples in the exchange syntax or the publicly
standardized model has had no detrimental impact on our ability to work
with them internally.

Dave

[Apologies if this point has already been made down thread, I'm only 303
messages in and have 242 left to scan :)]

Re: Subjects as Literals

[Henry Story]

On 8 Jul 2010, at 20:30, David Booth wrote:

> On Thu, 2010-07-08 at 11:03 -0500, Pat Hayes wrote:
>> On Jul 6, 2010, at 9:23 PM, David Booth wrote:
>> 
>>> On Tue, 2010-07-06 at 20:45 +0200, Henry Story wrote:
>>> [ . . . ]
 foaf:knows a rdf:Property .
 
 Well we can dereference foaf:knows to find out what it means. This is
 the canonical way to find it's meaning, and is the initial  
 procedure we
 should use to arbitrate between competing understandings of its  
 meaning.
>>> 
>>> Right.  The document you get upon dereferencing -- the "follow your
>>> nose" document -- acts as a URI declaration.[1]
>>> 
>>> 1. http://dbooth.org/2007/uri-decl/
>> 
>> Just to clarify, that is David's idea and his suggestion. It seems  
>> like a sensible idea, in many ways. It seems to reflect some current  
>> practice. But it is not part of the current RDF spec., and it is  
>> controversial.
> 
> No, it was not my idea.  I cannot claim any credit for it.  The idea was
> already around and in fairly common practice (though not universal) when
> I first wrote it up in 2007.  I do not know who came up with it.  All I
> did was write it up, give it a descriptive name "URI declaration" (so
> that we could all refer to it more easily), and promote it.

The general idea is widely accepted, but the interpretation using speech
acts is certainly original and controversial.

There is also an issue that one can imagine conventions arising in other
ways too btw...

Which is to say it is interesting and can be developed further.

Henry

Re: Capturing the discussion (RE: Subjects as Literals)

[Antoine Zimmermann]

Sandro, all,


I created the wikipage as you suggested. It is sketchy and certainly a 
bit biased towards my own opinion but I guess this will be improved as 
the document extends.



Le 07/07/2010 05:01, Sandro Hawke a écrit :

Would anyone be willing to try to capture the results of this thread in
a page or two of consensus (neutral point-of-view) text that would
explain the situation to at least a majority of the folks who've jumped
in here with misunderstandings?

To my reading, you (Michael) and Antoine are expressing that most
clearly, if you'd be willing.


Michael, feel free to modify my first input.


It would be good, I think, to incorporate the ideas and perhaps the
structure used at the workshop:
http://www.w3.org/2001/sw/wiki/RDF_Core_Charter_2010#Literals_as_Subjects

... but probably do it on another wiki page, eg:

http://www.w3.org/2001/sw/wiki/Literals_as_Subjects (which does not yet
exist as I write this).

We could think of this as a FAQ response, where the Questions are
something like:
   Why can't I use Literals in the subject position in RDF?


For me, the only answer I know to this question is:
"You can't use literals as subjects because the spec says so."

It would be good to have the history of this restriction to know why it 
was put in the spec in the first place.



   When are you going to change this?


Hmm, can we really answer that question when the community is still very 
divided on whether it should be changed at all?



   How can I work around this restriction?
and maybe:
   What would anyone want to use literals as subjects?
   What would it mean to use a literal as a predicate?



Hoping someone will feel inspired to tie this up with a nice bow,
 -- Sandro



Regards,
AZ

Re: Subjects as Literals

[Jakub Kotowski]

On 08.07.2010 19:06, Pat Hayes wrote:
>> With literals, typing has come up but it hasn't been fully integrated
>> with the rest of the RDF grammar; you can still say things like
>> 'ten(integer) much-likes "Sampo"@fi' without any usual type system
>> catching the error.
> 
> LIteral types don't check 'errors' in RDF. (Though this one ought to be
> caught by any RDF parser, in fact.) This is a complicated issue in the
> design of RDF, one which absorbed a great deal of the WG's time. Its
> probably not relevant to go into this here; it has to do with keeping
> RDF monotonic. I can wax lyrical on this if you really want me to.

I would like to hear it if you don't mind.

Best regards,
Jakub

Re: Subjects as Literals

[David Booth]

On Thu, 2010-07-08 at 11:03 -0500, Pat Hayes wrote:
> On Jul 6, 2010, at 9:23 PM, David Booth wrote:
> 
> > On Tue, 2010-07-06 at 20:45 +0200, Henry Story wrote:
> > [ . . . ]
> >> foaf:knows a rdf:Property .
> >>
> >> Well we can dereference foaf:knows to find out what it means. This is
> >> the canonical way to find it's meaning, and is the initial  
> >> procedure we
> >> should use to arbitrate between competing understandings of its  
> >> meaning.
> >
> > Right.  The document you get upon dereferencing -- the "follow your
> > nose" document -- acts as a URI declaration.[1]
> >
> > 1. http://dbooth.org/2007/uri-decl/
> 
> Just to clarify, that is David's idea and his suggestion. It seems  
> like a sensible idea, in many ways. It seems to reflect some current  
> practice. But it is not part of the current RDF spec., and it is  
> controversial.

No, it was not my idea.  I cannot claim any credit for it.  The idea was
already around and in fairly common practice (though not universal) when
I first wrote it up in 2007.  I do not know who came up with it.  All I
did was write it up, give it a descriptive name "URI declaration" (so
that we could all refer to it more easily), and promote it.  

My write-up explains:
http://dbooth.org/2007/uri-decl/#uri-decl
[[
The ideas behind URI declarations are not new.  A number of people in
the Semantic Web community have used and advocated practices that amount
to URI declaration.  For example, Dan Connolly's paper on "A Pragmatic
Theory of Reference for the Web" [23 May 2006] recommends:

   "1. To mint a term in the community, choose a URI of the form doc#id
and publish at doc some information that motivates others to use the
term in a manner that is consistent with your intended meaning(s).
   2. Use of a URI of the form. doc#id implies agreement to information
published at doc."


And Sandro Hawke wrote in his RDF 2 Wishlist post:

". . . the use of particular IRIs as predicates implies certain things,
as defined by the IRI’s owner"


And Cool URIs for the Semantic Web recommends:

"1. Be on the Web.
Given only a URI, machines and people should be able to retrieve a
description about the resource identified by the URI from the Web."
]]

The practice is already quite well established, though again not
universal, and there is still some controversy, but it seems to be
diminishing as people understand it more.



-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Re: Subjects as Literals

[Pat Hayes]

On Jul 6, 2010, at 9:51 PM, Sampo Syreeni wrote:


On 2010-07-05, Pat Hayes wrote:

This objection strikes me as completely wrong-headed. Of course  
literals are machine processable.


What precisely does "Sampo" as a plain literal mean to a computer?  
Do give me the fullest semantics you can.


In RDF, it means the five-character string ess-ay-em-pee-oh, in that  
order. It does not mean anything else. This meaning is fixed by the  
RDF specification documents themselves. BTW, these are Unicode  
characters, so consult the Unicode documentation for more detail on  
what exactly is meant by a "character" (it is surprisingly  
complicated, and makes fascinating reading.)


As in, is it the Finnish Sampo as in me, my neighbour, or what would  
be roughly translated as "cornucopia" in some languages?


As you did not specify any language tag, the characters are presumed  
to be in the English ("Latin") alphabet. Technically, the characters  
are all in unicode plane 0.


You could of course just answer that it's just a literal, but then  
you'd be telling precisely the same thing I did: that sort of thing  
has only axiomatic semantics, lacking the real world denotation  
which is needed if we want to actually apply this stuff to something  
tangible.


Not at all. Character strings may not be 'tangible', but they are real  
things in the world. Being tangible isn't a necessary condition for  
being real. The world comprises many things, probably more kinds of  
thing than any of us are capable of imagining at any given moment (the  
'horatio principle': it is a mistake to want to exclude things from  
the universe of everyone else's discourse, or to presume that one's  
own ontological biases are going to be universally shared by others.)


So what is it? As opposed to me as an OID (I don't think the URI  
namespace registration went through yet): 1.3.6.1.4.1.12798.1.2049 ?  
I mean, if your semweb killer app ordered that, the user should  
mostly receive a no-thanks for hairy mail prostitution. If they  
ordered the third kind of Sampo -- they should probably receive hard  
psychedelics instead. (And yes, I know this is rather concrete  
bound. I think it should be, too.)



Well, nobody is suggesting allowing literals as predicates [...]


Why? Is there a lesson to be learnt there?


Only that the world in general probably isn't ready yet for this kind  
of generalized logic. It is being used by specialists and those who  
really need it, like the security agencies (who have been using it for  
several years now).


But it is easy to give 'ridiculous' examples for any syntactic  
possibility. I can write apparent nonsense using nothing but URIs,  
but this is not an argument for disallowing URIs in RDF.


In fact it could be. Whatever format you accept, you should be  
liberal with, but at the same time you should always have an  
unambiguous, safe, productive and well-documented interpretation for  
it all.


This is WRONG. The type specifiers *completely* disambiguate the  
text in the body of the literal.


A language signifier tacked onto a plain literal doesn't, as I just  
showed.


Actually it does. The literal denotes the string, no more and no less.


An integer annotation on a number just says it's a number


And that ends the matter, right there. A number is a real thing in the  
world, it is the denotation of a numeral. It doesn't "carry" anything  
else. If you want to talk about numbers of zlotys, or numbers of  
centimeters, then you need ontologies of zlotys and centimeters (or,  
perhaps, new datatypes for these things.)


, not what unit it perhaps carries; those are two completely  
different kinds of numbers, carrying different operational semantics.


No, they are not different kinds of *numbers*. There is only one kind  
of number, AKA the natural numbers (Im ignoring reals, rationals, and  
complex numbers.)


With literals, typing has come up but it hasn't been fully  
integrated with the rest of the RDF grammar; you can still say  
things like 'ten(integer) much-likes "Sampo"@fi' without any usual  
type system catching the error.


LIteral types don't check 'errors' in RDF. (Though this one ought to  
be caught by any RDF parser, in fact.) This is a complicated issue in  
the design of RDF, one which absorbed a great deal of the WG's time.  
Its probably not relevant to go into this here; it has to do with  
keeping RDF monotonic. I can wax lyrical on this if you really want me  
to.




I'd say that's pretty far from well defined semantics. Even in the  
simplest, axiomatic sense. The literal is then the primary culprit  
-- otherwise you and others have done a swell job in tightening it up.


For plain literals, the meaning of the literal is the string  
itself, a unique string of characters.


That I know too.


Well then, isn't that unambiguous enough for you?



With Schema derived or otherwise strictly derived types, the level  
of disambiguation can be the same as or ev

Re: Subjects as Literals

[Pat Hayes]

On Jul 6, 2010, at 9:23 PM, David Booth wrote:


On Tue, 2010-07-06 at 20:45 +0200, Henry Story wrote:
[ . . . ]

foaf:knows a rdf:Property .

Well we can dereference foaf:knows to find out what it means. This is
the canonical way to find it's meaning, and is the initial  
procedure we
should use to arbitrate between competing understandings of its  
meaning.


Right.  The document you get upon dereferencing -- the "follow your
nose" document -- acts as a URI declaration.[1]

1. http://dbooth.org/2007/uri-decl/


Just to clarify, that is David's idea and his suggestion. It seems  
like a sensible idea, in many ways. It seems to reflect some current  
practice. But it is not part of the current RDF spec., and it is  
controversial.


Pat





--
David Booth, Ph.D.
Cleveland Clinic (contractor)
http://dbooth.org/

Opinions expressed herein are those of the author and do not  
necessarily

reflect those of Cleveland Clinic.







IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

Re: Subjects as Literals

[Pat Hayes]

On Jul 6, 2010, at 4:02 PM, Nathan wrote:


Pat Hayes wrote:
However, before I lose any more of my SW friends, let me say at  
once that I am NOT arguing for this change to RDF.


so after hundreds of emails, I have to ask - what (the hell) defines  
RDF?


Well, the current specs do. And they include a lot more than the  
semantics. In particular, they include syntactic restrictions on what  
can be in what part of a triple, like no literals in the subject  
position. When I say that the RDF semantics works fine for a more  
general version, what I mean is only to reassure folk who know that it  
would be only an editorial matter to change the specs to allow more  
general forms for triples, but who worry (as many folk do) that such a  
change might break something basic in the RDF semantics, which is  
known to be a deep, subtle complicated thingie - to reassure them that  
this will not break the semantics, in fact. Of course, the 'rdf  
semantics' document would need some revision, since it gives for  
inference rules for RDFS which presume that the syntactic restrictions  
are in place, things like that. But these changes would actually  
simplify the way the document is written compared to its present form.




I've read that 'The RDF Semantics as stated works fine with triples  
which have any kind of syntactic node in any position in any  
combination.'


Do the 'RDF Semantics' define RDF? or do the serializations?


The specs do, which include the RDF graph model as well as the RDF/XML  
serialization, both normative.




simply - does RDF support literal subjects or not


Right now, it does not.

- I've read the aforementioned sentence to read 'RDF Semantics  
support literal subjects' or should I be reading 'RDF Semantics  
could support literal subjects' or 'does support literal subjects' or?


Could support (with some work, but not too much) is closest to the  
mark. See above.


Pat




Just seeking a definitive bit of clarity on 1: what defines RDF, 2:  
what is *currently* supported in that definition.


Preferably a serialization unspecific answer :)

Best & TIA,

Nathan





IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

Re: Subjects as Literals

[Reto Bachmann-Gmuer]

On Tue, Jul 6, 2010 at 10:23 AM, Danny Ayers  wrote:

> I've been studiously avoiding this rat king of a thread, but just on
> this suggestion:
>
> On 2 July 2010 11:16, Reto Bachmann-Gmuer 
> wrote:
> ...
> > Serialization formats could support
> >
> > "Jo" :nameOf :Jo
> >
> > as a shortcut for
> >
> > [ owl:sameAs "Jo"; :nameOf :Jo]
> >
> > and a store could (internally) store the latter as
> >
> > "Jo" :nameOf :Jo
> >
> > for compactness and efficiency.
>
> what about keeping the internal storage idea, but instead of owl:sameAs,
> using:
>
> :Jo rdfs:value "Jo"
>
> together with
>
> :Jo rdf:type rdfs:Literal
>
> rdf:value has no clear semantics and it might be used and interpreted
differently. owl:sameAs has a clear semantics and if the processor supports
owl the above is legal and an unambiguous expression of the intended
meaning.

While there might be arguments and advantages on a theoretical level for
empowering the rdf layer itself to allow expressing the synonymity of terms
and literal subjects I don't see any practical benefits. We're moving
towards higher levels of abstraction, to describe the world with triples in
the semantic web owl is an essential foundation. With this semantic web we
can have what we need and want (literal subjects). To me the discussion on
the ideal separation of the layers might be theoretically interesting, but
for practical purposes I don't care where IP ends and TCP begins, how my
files maps to sector and similarly if the semantic stack is designed as
elegant as it could if I have to use owl to have my literal subjects. What I
do care about is the stability of what I'm building upon.

Bring RDF and OWL (Full) closer by combined introductions and tutorial, I
can see lots of benefits in that, but mainly costs in changing RDF.


Cheers,
reto

Re: Subjects as Literals

[David Booth]

On Wed, 2010-07-07 at 10:33 +0200, Henry Story wrote:
> On 7 Jul 2010, at 04:23, David Booth wrote:
> 
> > On Tue, 2010-07-06 at 20:45 +0200, Henry Story wrote:
> > [ . . . ] 
> >> foaf:knows a rdf:Property .
> >> 
> >> Well we can dereference foaf:knows to find out what it means. This is
> >> the canonical way to find it's meaning, and is the initial procedure we
> >> should use to arbitrate between competing understandings of its meaning.
> > 
> > Right.  The document you get upon dereferencing -- the "follow your
> > nose" document -- acts as a URI declaration.[1]
> > 
> > 1. http://dbooth.org/2007/uri-decl/ 
> 
> Yes, very interesting and useful paper. 

Thanks.

> 
> I can't say if I agree with all of it yet, as I would have to read it
> more carefully.  But I think reflection in this space is very much
> needed. 

It's been a few years since I first wrote it, so I should probably
re-read it to see whether *I* still agree with all of it.  :)

> 
> A few notes. 
> 
> You use the word "URI" a lot in your paper, but I am not sure all URIs
> have a dereferencing mechanism. What is interesting about your paper
> is that it points to a reason for why this is really important part of
> a URI.

Yes.
> 
> It would be interesting to make the case in terms of the Fregean
> Sense/Reference distinction. I have used that to explain "How does
> Secure Authentication Work with FOAF+SSL?" in the FAQ
> 
>   http://esw.w3.org/Foaf%2Bssl/FAQ
> 
> On the sense reference distinction, I think people tend to forget that
> in the semantic web, every URI we use is a relation between a string
> and a thing, intermediated by the sense.
> 
>   We could make this clear by creating the reference relation, perhaps
> log:reference
> which would relate a URI string to the thing.
> 
>    owl:sameAs "http://bblfish.net/#me"^^log:reference 
> .
> 
> this makes it clear that the <...> notation is just the shorthand for
> the literal notation to the right, which if thought of this way,
> suggests we have been using literals in subject position all the
> time ;->

Nice.  And I agree that this kind of relation is needed.  But are you
making an intentional distinction between log:reference and the existing
log:uri relation?
http://www.w3.org/2000/10/swap/doc/Reach#More
Before I noticed log:uri I made up a similar relation (though I hadn't
used it as a datatype), but I have since been using log:uri to express
this idea:

    log:uri "http://bblfish.net/#me"; .

> 
> 
>   So what is log:reference do? Well it is the relation that gives the
> reference of an object. But how does anyone come to know the procedure
> for finding the reference? (This is a very Michael Dummett like
> question). If there is no way to find the sense of a word, if there is
> no thing to learn that counts as knowing it, then there is no way of
> being right or wrong about its use. And so the word has no meaning. 
>
>   In everyday human life for millennia there have been certain skilled
> user of a word, masters of the vocabulary, that are final arbiters of
> the words meaning. This has to be true in the semantic web too, but we
> need more mechanical ways of finding the sense.
> 
>   So to repeat: the log:reference has to be a relation that links the
> name to the referent via the sense. Since it is tying a string to a
> thing, it has to get going on information from the URI string. The
> only way of doing that is getting that string's log:semantics: ie
> dereferencing that string using the canonical method for dereferencing
> that URI given its scheme. A http URL is dereferenced using the HTTP
> scheme, a ftp url using the ftp scheme, https using http and TLS,
> etc 

Take a look at "Resource Identity and Semantic Extensions: Making Sense
of Ambiguity":
http://dbooth.org/2010/ambiguity/
which was presented at the Semantic Technology Conference two weeks ago.
It sheds some light on issues of resource ambiguity, and it proposes a
standard way -- basically an attempt to codify common practice -- to
determine a URI's referent.
> 
>The document returned has to be interpreted giving us its
> log:semantics. Perhaps it would be more helpful to have the canonical
> semantics relation (and perhaps this is what named graphs are?)
> 
>"http://bblfish.net/#me"; log:canonicalSemantics #at a time?
>{ :me a foaf:Person;
>  foaf:name "Henry Story";
>  foaf:homepage ;
>  is cert:identity of ... } .
> 
>  
>   Notice now that the object of log:canonicalSemantics is a graph, which
> we can think of as the set of possible worlds in which the statements therein
> are true.
> 
>I think up to here I feel pretty comfortable.
> 
>There are a few interesting issues from there on that I need to
> think about more:
> 
>- if the graph to the right does not individuate one thing, is that
> just bad practice? Does it make the url "http

Re: Subjects as Literals

[Henry Story]

On 7 Jul 2010, at 04:23, David Booth wrote:

> On Tue, 2010-07-06 at 20:45 +0200, Henry Story wrote:
> [ . . . ] 
>> foaf:knows a rdf:Property .
>> 
>> Well we can dereference foaf:knows to find out what it means. This is
>> the canonical way to find it's meaning, and is the initial procedure we
>> should use to arbitrate between competing understandings of its meaning.
> 
> Right.  The document you get upon dereferencing -- the "follow your
> nose" document -- acts as a URI declaration.[1]
> 
> 1. http://dbooth.org/2007/uri-decl/ 

Yes, very interesting and useful paper. 

I can't say if I agree with all of it yet, as I would have to read it more 
carefully.  But I think reflection in this space is very much needed. 

A few notes. 

You use the word "URI" a lot in your paper, but I am not sure all URIs have a 
dereferencing mechanism. What is interesting about your paper is that it points 
to a reason for why this is really important part of a URI.

It would be interesting to make the case in terms of the Fregean 
Sense/Reference distinction. I have used that to explain "How does Secure 
Authentication Work with FOAF+SSL?" in the FAQ

  http://esw.w3.org/Foaf%2Bssl/FAQ

On the sense reference distinction, I think people tend to forget that in the 
semantic web, every URI we use is a relation between a string and a thing, 
intermediated by the sense.

  We could make this clear by creating the reference relation, perhaps 
log:reference
which would relate a URI string to the thing.

   owl:sameAs "http://bblfish.net/#me"^^log:reference .

this makes it clear that the <...> notation is just the shorthand for the 
literal notation to the right, which if thought of this way, suggests we have 
been using literals in subject position all the time ;->

  So what is log:reference do? Well it is the relation that gives the reference 
of an object. But how does anyone come to know the procedure for finding the 
reference? (This is a very Michael Dummett like question). If there is no way 
to find the sense of a word, if there is no thing to learn that counts as 
knowing it, then there is no way of being right or wrong about its use. And so 
the word has no meaning. 

  In everyday human life for millennia there have been certain skilled user of 
a word, masters of the vocabulary, that are final arbiters of the words 
meaning. This has to be true in the semantic web too, but we need more 
mechanical ways of finding the sense.

  So to repeat: the log:reference has to be a relation that links the name to 
the referent via the sense. Since it is tying a string to a thing, it has to 
get going on information from the URI string. The only way of doing that is 
getting that string's log:semantics: ie dereferencing that string using the 
canonical method for dereferencing that URI given its scheme. A http URL is 
dereferenced using the HTTP scheme, a ftp url using the ftp scheme, https using 
http and TLS, etc 

   The document returned has to be interpreted giving us its log:semantics. 
Perhaps it would be more helpful to have the canonical semantics relation (and 
perhaps this is what named graphs are?)

   "http://bblfish.net/#me"; log:canonicalSemantics #at a time?
   { :me a foaf:Person;
 foaf:name "Henry Story";
 foaf:homepage ;
 is cert:identity of ... } .

 
  Notice now that the object of log:canonicalSemantics is a graph, which
we can think of as the set of possible worlds in which the statements therein
are true.

   I think up to here I feel pretty comfortable.

   There are a few interesting issues from there on that I need to think about 
more:

   - if the graph to the right does not individuate one thing, is that just bad 
practice? Does it make the url "http://bblfish.net/#me"; essentially unuseable, 
until that detail is cleared up.

   - how much of the vocabulary inside the graph needs to be understood too? 
Perhaps
 one needs to get the meaning of each relation until one finds an identifying 
description.

   - Is the description in the graph to the right a way that would identify :me 
in every possible world, ie is it a description or a rigid designator? How does 
one distinguish rigid designators from general desciptions.

 I think your suggestion here is that it is a rigid designator -- which it 
can only be if there is a way to tie that meaning to the actual world.  You do 
this tying to the actual world by thinking of the description as a speech act, 
or a document publication act. That sounds good.  
   But perhaps we need a vocabulary then to help us distinguish such acts and 
general descriptions. I think a few examples would probably help here. If all 
the graph contained was
{ :me foaf:name "Henry Story" . }
   Then that certainly would be ambiguous. Would that mean the 
 then referred to any person named "Henry Story" ? In 
any possible wor

Re: Subjects as Literals

[Danny Ayers]

On 6 July 2010 13:34, Nathan  wrote:
> Danny Ayers wrote:

>> :Jo rdfs:value "Jo"
>>
>> together with
>>
>> :Jo rdf:type rdfs:Literal
>>
>> ?
>
> 1: is there and rdfs:value? (rdf:value)

My mistake, it is rdf:value

> 2: I would *love* to see rdf:value with a usable tight definition that
> everybody can rely on

It's certainly usable, but the definition is about as open as it could be:

http://www.w3.org/TR/rdf-primer/#rdfvalue

http://www.w3.org/TR/rdf-schema/#ch_value

http://www.w3.org/TR/rdf-mt/#rdfValue

...in fact it rather resembles a bnode in the property position.

Cheers,
Danny.

-- 
http://danny.ayers.name

Re: Subjects as Literals

[Ivan Mikhailov]

Antoine, all,

On Tue, 2010-07-06 at 20:54 +0100, Antoine Zimmermann wrote:

> Not only there are volunteers to implement tools which allow literals as 
> subjects, but there are already implementations out there.
> As an example, take Ivan Herman's OWL 2 RL reasoner [1]. You can put 
> triples with literals as subject, and it will reason with them.
> Here in DERI, we also have prototypes processing generalised triples.

It is absolutely not a problem to add a support in, e.g., Virtuoso as
well. 1 day for non-clustered version + 1 more day for cluster. But it
will naturally kill the scalability. Literals in subject position means
either outlining literals at all or switch from bitmap indexes to plain,
and it the same time it blocks important query rewriting.

We have seen triple store benchmark reports where a winner is up to 120
times faster than a loser and nevertheless all participants are in
widespread use. With these reports in mind, I can make two forecasts.

1. RDF is so young that even an epic fail like this feature would not
immediately throw an implementation away from the market.

2. It will throw it away later.

> Other reasoners are dealing with literals as subjects. RIF 
> implementations are also able to parse triples with literals as 
> subjects, as it is required by the spec.
...
> Some people mentioned scalability issues when we allow literals as 
> subject. It might be detrimental to the scalability of query engines 
> over big triple stores, but allowing literals as subjects is perfectly 
> scalable when it comes to inference materialisation (see recent work on 
> computing the inference closure of 100 billion triples [2]).
> 

Reasoners should get data from some place and put them to same or other
place. There are three sorts of inputs: triple stores with real data,
dumps of real data and synthetic benchmarks like LUBM. There are two
sorts of outputs: triple stores for real data and papers with nice
numbers. Without adequate triple store infrastructure at both ends (or
inside), any reasoner is simply unusable. [2] compares a reasoner that
can not answer queries after preparing the result with a store that
works longer but is capable of doing something for its multiple clients
immediately after completion of its work. If this is the best achieved
and the most complete result then volunteers are still required.

> Considering this amount of usage and use cases, which is certainly meant 
> to grow in the future, I believe that it is time to standardised 
> generalised RDF.

http://en.wikipedia.org/wiki/Second-system_effect

There were "generalised RDFs" before a simple RDF comes to scene. Minsky
--- frames and slots. Winston --- knowledge graphs that are only a bit
more complicated than RDF. The fate of these approaches is known: great
impact on science, little use in industry.

> A possible compromise would be to define RDF 2 as /generalised RDF + 
> named graphs + deprecate stuff/, and have a sublanguage (or profile) 
> RDF# which forbids literals in subject and predicate positions, as well 
> as bnodes in predicate position.

Breaking a small market in two incompatible parts is as bad as asking my
mom what she would like to use on her netbook, ALSA or OSS. She don't
know (me either) and she don't want to chose which half of sound
applications will crash.

> Honestly, it's just about putting a W3C stamp on things that some people 
> are already using and doing.

If people are living in love and happiness without a stamp on a paper,
it does not mean living in sin ;) Similarly, people may use literals as
subjects without asking others and without any stamp.

Best Regards,
Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com

> [2] Jacopo Urbani, Spyros Kotoulas, Jason Maassen, Frank van Harmelen, 
> and Henri Bal. "OWL reasoning with WebPIE: calculating the closure of 
> 100 billion triples" in the proceedings of ESWC 2010.

Capturing the discussion (RE: Subjects as Literals)

[Sandro Hawke]

Would anyone be willing to try to capture the results of this thread in
a page or two of consensus (neutral point-of-view) text that would
explain the situation to at least a majority of the folks who've jumped
in here with misunderstandings?

To my reading, you (Michael) and Antoine are expressing that most
clearly, if you'd be willing.

It would be good, I think, to incorporate the ideas and perhaps the
structure used at the workshop:
http://www.w3.org/2001/sw/wiki/RDF_Core_Charter_2010#Literals_as_Subjects

... but probably do it on another wiki page, eg:

http://www.w3.org/2001/sw/wiki/Literals_as_Subjects (which does not yet
exist as I write this).

We could think of this as a FAQ response, where the Questions are
something like:
  Why can't I use Literals in the subject position in RDF?
  When are you going to change this?
  How can I work around this restriction?
and maybe:
  What would anyone want to use literals as subjects?
  What would it mean to use a literal as a predicate?

Hoping someone will feel inspired to tie this up with a nice bow,
-- Sandro

On Tue, 2010-07-06 at 23:40 +0200, Michael Schneider wrote:
> Nathan wrote:
> 
> >Sent: Tuesday, July 06, 2010 11:02 PM
> >To: Pat Hayes
> >Cc: Toby Inkster; Linked Data community; Semantic Web
> >Subject: Re: Subjects as Literals
> >
> >Pat Hayes wrote:
> >> However, before I lose any more of my SW friends, let me say at once
> >> that I am NOT arguing for this change to RDF.
> >
> >so after hundreds of emails, I have to ask - what (the hell) defines
> >RDF?
> >
> >I've read that 'The RDF Semantics as stated works fine with triples
> >which have any kind of syntactic node in any position in any
> >combination.'
> >
> >Do the 'RDF Semantics' define RDF? or do the serializations?
> 
> Every formal language is essentially defined by a (abstract) syntax and a
> semantics. The syntax defines which well-formed syntactic constructs exist,
> and the semantics gives meaning to these constructs. 
> 
> RDF is defined by the RDF Abstract Syntax, defined in [1], and the RDF
> Semantics, defined in [2]. 
> 
> Serializations of the (abstract) syntax, as RDF/XML [3] or N3 in the case of
> RDF, are concrete formalisms to encode the abstract syntax of a language
> into a stream of characters so a language construct can be technically
> stored and processed. A serialization does not fundamentally contribute to
> the specification of the language, but is of great importance anyway. An
> abstract syntax cannot really be stored or processed, but is more of a
> conceptual/mathematical model.
> 
> >simply - does RDF support literal subjects or not - I've read the
> >aforementioned sentence to read 'RDF Semantics support literal subjects'
> >or should I be reading 'RDF Semantics could support literal subjects' or
> >'does support literal subjects' or?
> 
> The RDF Semantics could, in principle, cope with generalized RDF, but the
> RDF Abstract Syntax does not support literal subjects. Therefore, RDF as a
> whole does not support literal subjects.
> 
> >Just seeking a definitive bit of clarity on 1: what defines RDF, 2: what
> >is *currently* supported in that definition.
> >
> >Preferably a serialization unspecific answer :)
> 
> Indeed. Even if a serialization of RDF would support literals in subjects,
> RDF as a formal language would still not support it. For instance, N3
> supports certain forms of rules, and TriG supports named graphs. But none of
> these syntactic constructs are supported by the RDF Abstract Syntax. So they
> are not supported by RDF. 
> 
> >Best & TIA,
> >
> >Nathan
> 
> Best,
> Michael
> 
> [1] <http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/>
> [2] <http://www.w3.org/TR/2004/REC-rdf-mt-20040210/>
> [3] <http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/>
> 
> --
> Dipl.-Inform. Michael Schneider
> Research Scientist, Information Process Engineering (IPE)
> Tel  : +49-721-9654-726
> Fax  : +49-721-9654-727
> Email: michael.schnei...@fzi.de
> WWW  : http://www.fzi.de/michael.schneider
> ===
> FZI Forschungszentrum Informatik an der Universität Karlsruhe
> Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
> Tel.: +49-721-9654-0, Fax: +49-721-9654-959
> Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
> Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
> Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
> ===
> 
> 
> 

Linked Data Spec (was Re: Subjects as Literals)

[Sandro Hawke]

On Tue, 2010-07-06 at 22:23 -0400, David Booth wrote:
> On Tue, 2010-07-06 at 20:45 +0200, Henry Story wrote:
> [ . . . ] 
> > foaf:knows a rdf:Property .
> > 
> > Well we can dereference foaf:knows to find out what it means. This is
> > the canonical way to find it's meaning, and is the initial procedure we
> > should use to arbitrate between competing understandings of its meaning.
> 
> Right.  The document you get upon dereferencing -- the "follow your
> nose" document -- acts as a URI declaration.[1]
> 
> 1. http://dbooth.org/2007/uri-decl/ 

To be clear, this is your proposal, not a part of the current RDF
specifications.Your phrasing might confuse people about that.  

Your proposal is somewhat more specific than the general Linked Data
proposal, eg http://www.w3.org/DesignIssues/LinkedData

Two questions for the W3C community going forward are:

 * exactly what do we mean by Linked Data (ie do we follow
   David's proposal?)

 * in the general case, "should" data be published as RDF
   Linked Data?

The workshop output on these subjects is here:

http://www.w3.org/2001/sw/wiki/RDF_Core_Charter_2010#Linked_Data_Work_Items

and see the strawpoll results:

http://www.w3.org/2010/06/rdf-work-items/table

If someone wants to re-factor and revise those proposals, I'd encourage
them to do it on that wiki, but on a new page.

Some of this work may end up being tackled as part of the eGovernment
Activity instead of the Semantic Web activity, perhaps.

-- Sandro

Re: Subjects as Literals

[Sampo Syreeni]

On 2010-07-05, Pat Hayes wrote:

This objection strikes me as completely wrong-headed. Of course 
literals are machine processable.


What precisely does "Sampo" as a plain literal mean to a computer? Do 
give me the fullest semantics you can. As in, is it the Finnish Sampo as 
in me, my neighbour, or what would be roughly translated as "cornucopia" 
in some languages? You could of course just answer that it's just a 
literal, but then you'd be telling precisely the same thing I did: that 
sort of thing has only axiomatic semantics, lacking the real world 
denotation which is needed if we want to actually apply this stuff to 
something tangible.


So what is it? As opposed to me as an OID (I don't think the URI 
namespace registration went through yet): 1.3.6.1.4.1.12798.1.2049 ? I 
mean, if your semweb killer app ordered that, the user should mostly 
receive a no-thanks for hairy mail prostitution. If they ordered the 
third kind of Sampo -- they should probably receive hard psychedelics 
instead. (And yes, I know this is rather concrete bound. I think it 
should be, too.)



Well, nobody is suggesting allowing literals as predicates [...]


Why? Is there a lesson to be learnt there?

But it is easy to give 'ridiculous' examples for any syntactic 
possibility. I can write apparent nonsense using nothing but URIs, but 
this is not an argument for disallowing URIs in RDF.


In fact it could be. Whatever format you accept, you should be liberal 
with, but at the same time you should always have an unambiguous, safe, 
productive and well-documented interpretation for it all.


This is WRONG. The type specifiers *completely* disambiguate the text 
in the body of the literal.


A language signifier tacked onto a plain literal doesn't, as I just 
showed. An integer annotation on a number just says it's a number, not 
what unit it perhaps carries; those are two completely different kinds 
of numbers, carrying different operational semantics. With literals, 
typing has come up but it hasn't been fully integrated with the rest of 
the RDF grammar; you can still say things like 'ten(integer) much-likes 
"Sampo"@fi' without any usual type system catching the error.


I'd say that's pretty far from well defined semantics. Even in the 
simplest, axiomatic sense. The literal is then the primary culprit -- 
otherwise you and others have done a swell job in tightening it up.


For plain literals, the meaning of the literal is the string itself, a 
unique string of characters.


That I know too.

With Schema derived or otherwise strictly derived types, the level of 
disambiguation can be the same as or even better than with URI's, 
true. But then that goes the other way around, too: URI's could take 
the place of any such precise type.


No, they cannot. For numbers, for example, one would need infinitely many 
URIs; but in any case, why bother creating all these URIs?


There are just as many URI's in abstract as there are integers. Just 
take oid:integer:1 and go right past oid:integer: if necessary. 
Certainly even today the practical maximum GET strings over even HTTP go 
right upto thousands of digits of potential numerical capacity, quite 
without the need to compress further.


In theory, it can be argued that we can think about only such many 
discrete concepts. As long as they are discrete, they can be enumerated, 
and as long as the number stays finite, we could just give all of them 
separate numbers. Then just tack them onto a very big namespace prefix, 
like my number above. Theoretically it's easy; in pracitce you'd like 
the kind of hierarhical namespace that URI's and OID's buy you. But 
still, naming something like 10^100 discrete objects would still be 
easy. And then !!!:


We have (universally understood) names for the numbers already, called 
numerals. For dates, times and so forth, there are many formats in use 
throughout human societies, of course. That is WHY the work of 
establishing datatype standards work was done. To ignore all this, to 
reject a widely accepted standard, and advocate reversion to a 
home-made URI scheme seems to me to be blatantly irresponsible.


What I want is for more stuff to be standardized and their format 
shared. That is *squarely* my problem, here: RDF literals invite misuse. 
Perhaps if we banned plain literals, it would be better. But right now, 
few people type their literals well, and the typing mechanism even 
invites people to treat typed values as separate from the rest of the 
triple oriented data model. Which is extra work; which means your 
typical lazy nerd won't like it enough to implement it proper.


Personally, I'd like to see data standardized as broadly as possible. 
I'd like to have broad datasets out there, will well defined semantics. 
That is pretty much why I then oppose literals within the semantic web: 
they encourage sloppy typing which can kill the whole deal. Especially 
if we start to allow them all-round.

--
Sampo Syreeni, aka decoy - de

Re: Subjects as Literals

[Jeremy Carroll]

 On 7/5/2010 3:40 PM, Hugh Glaser wrote:

A particular problem in this realm has been characterised as
S-P-O v. O-R-O and I suspect that this reflects a Semantic Web/Linked Data
cultural difference,



You see this as a problem of having a literal in the "subject" position.
I might equally decide it is a problem with having literal in the "object"
position.
Literals are literals wherever they appear - they have no deeper semantics,
and they certainly do not identify anything other than the literal that they
are, if that makes sense.






Ah, perhaps the nub.
The "subject" is no more the thing "being talked about" than the "object".
I am not asking for symmetry of the grammar, if I understand what you mean.
I am asking for the freedom to express the statements I want in the way I
want, so that I can query the way I want.
At the risk of repeating myself:
If someone wants to say "666" foo:isTheNumberOf bar:theBeast
and I have to tell them (as I do) ah, you can't say that, you need to
introduce a resource numbers:666 rdfs:label "666". ...
or  bar:theBeast foo:hasNumber "666"
I actually feel pretty stupid, having told them that RDF represents
relations in a natural and basic way.
In fact, I always feel a bit embarrassed when I get to the bit in my slides
that shows there are two sorts of triples, as I have just said that the
triples are just a directed graph.


Just to mischievously throw a further linguistic spanner in the works 
(maybe that's a troll alert)

http://en.wikipedia.org/wiki/Ergative%E2%80%93absolutive_language

If we consider RDF as an ergative language, then the first position is 
necessarily an agent, and moreover, literals MUST NOT be agents


http://www.w3.org/2001/01/mp23

(My first research paper was on the Basque auxiliary verb, see Carroll 
and Abaitua 1990)


This would have interesting consequences for n-ary predicates

Jeremy

Re: Subjects as Literals

[David Booth]

On Tue, 2010-07-06 at 20:45 +0200, Henry Story wrote:
[ . . . ] 
> foaf:knows a rdf:Property .
> 
> Well we can dereference foaf:knows to find out what it means. This is
> the canonical way to find it's meaning, and is the initial procedure we
> should use to arbitrate between competing understandings of its meaning.

Right.  The document you get upon dereferencing -- the "follow your
nose" document -- acts as a URI declaration.[1]

1. http://dbooth.org/2007/uri-decl/ 



-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Re: Subjects as Literals

[Hugh Glaser]

On 06/07/2010 09:44, "Henry Story"  wrote:

> 
> On 6 Jul 2010, at 09:19, Dan Brickley wrote:
> 
>> On Tue, Jul 6, 2010 at 12:40 AM, Hugh Glaser  wrote:
>>> Hi Sampo.
>>> I venture in again...
>>> I have much enjoyed the interchanges, and they have illuminated a number of
>>> cultural differences for me, which have helped me understand why some people
>>> have disagree with things that seem clear to me.
>>> A particular problem in this realm has been characterised as
>>> S-P-O v. O-R-O and I suspect that this reflects a Semantic Web/Linked Data
>>> cultural difference, although the alignment will not be perfect.
>>> I see I am clearly in the latter camp.
>>> Some responses below.
>> 
>> 
>> imho RDF processing requires both perspectives, and neither is more
>> semwebby or linky than the other.
> 
> I agree with what you say here Dan, though I don't think it has anything
> to do with S-P-O or O-R-O.
Just my reading of Dan' message - thanks Henry for putting it clearly.
I now understand even better that some people see the "S" as a special
thing, that somehow is tied into the statements that are being made about
the "S".
The Quad bit of the graph is sort of an acceptance that things are more
O-R-O than S-P-O.
In fact, maybe the heretics (such as me) who just view things as O-R-O are
the reason that Quads are wanted at all.
We have decoupled the "S" from any special role, and so some sense of what
triples are "about" is being added.
> 
> That we have different graphs and that they can be merged are furthermore
> complimentary and essential to the semantic web. The RDF Semantics in my
> view clearly contains the notions of separate graphs, since it shows how
> they should be merged when *both are considered to be True*! Therefore
> if two graphs are not considered to be true there is no requirement to
> merge them. This is quite clear in the talk of possible worlds from the RDF
> Semantics document
> 
> [[
> The basic intuition of model-theoretic semantics is that asserting a sentence
> makes a claim about the world: it is another way of saying that the world is,
> in fact, so arranged as to be an interpretation which makes the sentence true.
> In other words, an assertion amounts to stating aconstraint on the possible
> ways the world might be.
> ]]
> 
> ( In this way of thinking about things relations are thought of as sentences.
> So this is just one more way of thinking of the relations in addition to S-P-O
> or O-R-O)
So it looks to me like your [[...]] seems to be very O-R-O to me.
> 
> Now it is quite clear from the above that when one has two incompatible
> graphs, then both of them still have meaning. They both can describe possible
> ways the world can be. It is just that merging them will lead to the set of
> all possible worlds: ie, nothing will be said.
> 
> RDF is a relational semantics. The model is arrows between things. That
> the serialisations don't allow literals in predicate position is a syntactic
> restriction, not a semantic one: because semantically one just cannot
> impose such a restriction. It is very clear that there are relations between
> numbers for example.
Cool ... Onwards to the discussion of exactly what defines RDF semantics, as
I bow out (again).
> 
> 
>> 
>> On a good day, we can believe what an RDF doc tells us. It does so in
>> terms of objects/things and their properties and relationships (o-r-o
>> i guess). On another day, we have larger collections of RDF to curate,
>> and need to keep track more carefully of who is claiming what about
>> these object properties; that's the provenance and quads perspective,
>> s-p-o.
> 
> As mentioned above o-r-o or s-p-o way of thinking of relations are in my
> view ways of thinking of exactly the same thing: arrows between things, or
> relations. This has no bearing on the quads or triple perspective.
> 
> 
>> Note that the subject/predicate/object terminology comes from
>> the old M&S spec which introduced reification in a ham-fisted attempt
>> to handle some of this trust-ish stuff, and that most simple data'
>> -oriented stuff uses SPARQL, the only W3C formal spec that covers
>> quads rather than triples. So I don't think the community splits
>> neatly into two on this, and that's probably for the best!
>> 
>> RDF processing, specs and tooling are about being able to jump in a
>> fluid and natural way between these two views of data; dipping down
>> into the 'view from one graph', or zooming out to see the bigger
>> picture of who says what.
> 
> These are one and the same view. It is just a question of which
> world you think is the actual one: ie a question of indexicality. Which
> world am I in.
> 
>> Neither is correct, and it is natural for
>> the terminology to change to capture the shifting emphasis. But until
>> we make this landscape clearer, people will be confused -- when is it
>> an attribute or property, and when is it a predicate?
> 
> Attribute, property, sentence, these are just the slightly different
> ways o

Re: Subjects as Literals

[Henry Story]

On 6 Jul 2010, at 21:57, Antoine Zimmermann wrote:

> I'd like to apologize in advance for being sarcastic, especially since I have 
> really nothing against Henry... ;)
> 
> 
> Le 06/07/2010 19:45, Henry Story a écrit :
>> 
>> This would be possible to say. The problem is that there would be no
>> way on earth that anyone could come to an agreement as to what kind
>> of property "lit" was. Everyone could make up defend their choice. And
>> where there is no right or wrong, there is no meaning. Hence the above
>> is undecidable.
>> 
>> What is the difference between the above and
>> 
>>foaf:knows a rdf:Property .
> 
> What is the difference between the above and
> 
>   foaf:lit a rdf:Property .
> 
> Well, we can dereference it and /not/ find out what it means.

In that case indeed you don't know much about what type of property it is. In 
fact 
if you can never derference it, then there are bound to be issues of who is 
correct about its meaning. 

I could add if you never dereferenced it, how do you know that foaf:lit is a 
property? You could say that it was, and I could say that it was not: how would 
an impartial observer come to judge on the issue?

With foaf:lit it is clear that the canonical determination of its meaning 
should be set by the owner of the xmlns.com domain. This does not mean that 
there cannot be exceptions that would make us decide otherwise. Say if 
xmlns.com was hacked, taken over by some pirates, or if the content was changed 
in a way that broke either an explicit or implicit licence that was widely 
accepted. The point is that there is a procedure that can be followed to 
understand what is right and wrong about the meaning of what foaf:lit means.

> This is possible to say. The problem is that there is no way on earth that 
> anyone can come to an agreement as to what kind of property foaf:lit is.

I disagree. As shown above: the xmlns.com domain does help identify some agency 
that is responsible for names coined in that domain.

This is not and cannot be the case of pure string literals such as "lit". Those 
are defined by the RDF semantics as strings, and there is no way anyone else's 
interpretation of them as a literal can trump anyone else's. 

> Everyone can make up defend their choice. And where there is no right or 
> wrong, there is no meaning. Hence, the above is undecidable.

This does not follow. But thanks for allowing me to clarify the difference
between URLs and pure string literals.

> And therefore, URIs as subjects should be disallowed... ;)

You can keep using URIs as subjects :-)

Henry


> 
>> Well we can dereference foaf:knows to find out what it means. This is
>> the canonical way to find it's meaning, and is the initial procedure we
>> should use to arbitrate between competing understandings of its meaning.
>> 
>>  Henry
>> 
> 
> Cheers,
> -- 
> Antoine Zimmermann
> Post-doctoral researcher at:
> Digital Enterprise Research Institute
> National University of Ireland, Galway
> IDA Business Park
> Lower Dangan
> Galway, Ireland
> antoine.zimmerm...@deri.org
> http://vmgal34.deri.ie/~antzim/

RE: Subjects as Literals

[Michael Schneider]

Nathan wrote:

>Sent: Tuesday, July 06, 2010 11:02 PM
>To: Pat Hayes
>Cc: Toby Inkster; Linked Data community; Semantic Web
>Subject: Re: Subjects as Literals
>
>Pat Hayes wrote:
>> However, before I lose any more of my SW friends, let me say at once
>> that I am NOT arguing for this change to RDF.
>
>so after hundreds of emails, I have to ask - what (the hell) defines
>RDF?
>
>I've read that 'The RDF Semantics as stated works fine with triples
>which have any kind of syntactic node in any position in any
>combination.'
>
>Do the 'RDF Semantics' define RDF? or do the serializations?

Every formal language is essentially defined by a (abstract) syntax and a
semantics. The syntax defines which well-formed syntactic constructs exist,
and the semantics gives meaning to these constructs. 

RDF is defined by the RDF Abstract Syntax, defined in [1], and the RDF
Semantics, defined in [2]. 

Serializations of the (abstract) syntax, as RDF/XML [3] or N3 in the case of
RDF, are concrete formalisms to encode the abstract syntax of a language
into a stream of characters so a language construct can be technically
stored and processed. A serialization does not fundamentally contribute to
the specification of the language, but is of great importance anyway. An
abstract syntax cannot really be stored or processed, but is more of a
conceptual/mathematical model.

>simply - does RDF support literal subjects or not - I've read the
>aforementioned sentence to read 'RDF Semantics support literal subjects'
>or should I be reading 'RDF Semantics could support literal subjects' or
>'does support literal subjects' or?

The RDF Semantics could, in principle, cope with generalized RDF, but the
RDF Abstract Syntax does not support literal subjects. Therefore, RDF as a
whole does not support literal subjects.

>Just seeking a definitive bit of clarity on 1: what defines RDF, 2: what
>is *currently* supported in that definition.
>
>Preferably a serialization unspecific answer :)

Indeed. Even if a serialization of RDF would support literals in subjects,
RDF as a formal language would still not support it. For instance, N3
supports certain forms of rules, and TriG supports named graphs. But none of
these syntactic constructs are supported by the RDF Abstract Syntax. So they
are not supported by RDF. 

>Best & TIA,
>
>Nathan

Best,
Michael

[1] <http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/>
[2] <http://www.w3.org/TR/2004/REC-rdf-mt-20040210/>
[3] <http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/>

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schnei...@fzi.de
WWW  : http://www.fzi.de/michael.schneider
===
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
===

Re: Subjects as Literals

[Nathan]

Thanks for the clarification Antione,

I'll take one of those generalised rdf's to go when available, can I pre 
order?


Best,

Nathan

Antoine Zimmermann wrote:

So to clarify a bit:

A serialisation is just a way to write down an RDF document in a 
computer. A serialisation of RDF must respect the abstract RDF syntax, 
which forbids literals in subject position. If the serialisation allows 
literals as subject, it is not a serialisation of RDF but it serialises 
a more general language (e.g., N3).
Then comes the semantics. The semantics does not allow or disallow 
anything, it just provides a notion of interpretation of an RDF 
vocabulary, and a notion of satisfaction of an RDF document (which must 
*not* have a literal in subject position). However, what we mean by 
saying, informally, that "the semantics allows literals in subject" is 
that the very same semantics could be applied to generalised RDF.


So, strictly speaking, no, the semantics does not allow you to put 
literals in subject, but it allows you to straightforwardly define the 
possible meaning of a generalised triple.



AZ

Le 06/07/2010 22:02, Nathan a écrit :

Pat Hayes wrote:

However, before I lose any more of my SW friends, let me say at once
that I am NOT arguing for this change to RDF.


so after hundreds of emails, I have to ask - what (the hell) defines RDF?

I've read that 'The RDF Semantics as stated works fine with triples
which have any kind of syntactic node in any position in any 
combination.'


Do the 'RDF Semantics' define RDF? or do the serializations?

simply - does RDF support literal subjects or not - I've read the
aforementioned sentence to read 'RDF Semantics support literal subjects'
or should I be reading 'RDF Semantics could support literal subjects' or
'does support literal subjects' or?

Just seeking a definitive bit of clarity on 1: what defines RDF, 2: what
is *currently* supported in that definition.

Preferably a serialization unspecific answer :)

Best & TIA,

Nathan

Re: Subjects as Literals

[Dan Brickley]

On Tue, Jul 6, 2010 at 11:17 PM, Pat Hayes  wrote:
[...]
>> This is
>> the canonical way to find it's meaning, and is the initial procedure we
>> should use to arbitrate between competing understandings of its meaning.
>
> Whoo, I doubt if that idea is going to fly. I sincerely hope not. Using
> that, how would you determine the meaning of the DC vocabulary?

It's also worth bearing in mind that Web sites get hacked from time to
time. W3C gets attacked regularly (but is pretty robust). The FOAF
servers were compromised a year or two back (but the xmlns.com site
was untouched). For a while, foaf-project.org was serving evil PHP and
ugly links, as was my own home page. This kind of mischief should be
kept in mind by anyone building a system that assumes you'll get
canonical meaning from an HTTP GET...

cheers,

Dan

Re: Subjects as Literals

[Antoine Zimmermann]

So to clarify a bit:

A serialisation is just a way to write down an RDF document in a 
computer. A serialisation of RDF must respect the abstract RDF syntax, 
which forbids literals in subject position. If the serialisation allows 
literals as subject, it is not a serialisation of RDF but it serialises 
a more general language (e.g., N3).
Then comes the semantics. The semantics does not allow or disallow 
anything, it just provides a notion of interpretation of an RDF 
vocabulary, and a notion of satisfaction of an RDF document (which must 
*not* have a literal in subject position). However, what we mean by 
saying, informally, that "the semantics allows literals in subject" is 
that the very same semantics could be applied to generalised RDF.


So, strictly speaking, no, the semantics does not allow you to put 
literals in subject, but it allows you to straightforwardly define the 
possible meaning of a generalised triple.



AZ

Le 06/07/2010 22:02, Nathan a écrit :

Pat Hayes wrote:

However, before I lose any more of my SW friends, let me say at once
that I am NOT arguing for this change to RDF.


so after hundreds of emails, I have to ask - what (the hell) defines RDF?

I've read that 'The RDF Semantics as stated works fine with triples
which have any kind of syntactic node in any position in any combination.'

Do the 'RDF Semantics' define RDF? or do the serializations?

simply - does RDF support literal subjects or not - I've read the
aforementioned sentence to read 'RDF Semantics support literal subjects'
or should I be reading 'RDF Semantics could support literal subjects' or
'does support literal subjects' or?

Just seeking a definitive bit of clarity on 1: what defines RDF, 2: what
is *currently* supported in that definition.

Preferably a serialization unspecific answer :)

Best & TIA,

Nathan

Re: Subjects as Literals

[Pat Hayes]

On Jul 6, 2010, at 1:45 PM, Henry Story wrote:



On 6 Jul 2010, at 14:03, Michael Schneider wrote:


Toby Inkster:


On Mon, 5 Jul 2010 17:43:17 -0500
Pat Hayes  wrote:

Well, nobody is suggesting allowing literals as predicates  
(although

in fact the RDF semantics would easily extend to this usage, if
required, and the analogous structures are allowed, and do have
genuine use cases, in ISO Common Logic.)


Actually, I have suggested allowing them just to make things  
simpler -

URIs, blank nodes and literals would all be allowed in any position.
However, a statement with a literal in the predicate position  
would be

officially defined to have no meaning.


So, if

  :s "lit" :o .

must not have a semantic meaning, what about

  "lit" rdf:type rdf:Property .


This would be possible to say. The problem is that there would be no
way on earth that anyone could come to an agreement as to what kind
of property "lit" was. Everyone could make up defend their choice. And
where there is no right or wrong, there is no meaning. Hence the above
is undecidable.


True (though you use "undecideable" here not in its technical sense, I  
presume) but the same is true for any RDF at all.




What is the difference between the above and

  foaf:knows a rdf:Property .

Well we can dereference foaf:knows to find out what it means.


Not according to the RDF specs, you can't. That is, you can (maybe)  
dereference it, but what you get has no bearing upon its (official)  
meaning. Maybe it should, but that idea needs a LOT of work to get  
straight. It is one proposal in the RDF2 wish-list, in fact.



This is
the canonical way to find it's meaning, and is the initial procedure  
we
should use to arbitrate between competing understandings of its  
meaning.


Whoo, I doubt if that idea is going to fly. I sincerely hope not.  
Using that, how would you determine the meaning of the DC vocabulary?


Pat




Henry





IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

Re: Subjects as Literals

[Yves Raimond]

Hello!

On Tue, Jul 6, 2010 at 10:02 PM, Nathan  wrote:
> Pat Hayes wrote:
>>
>> However, before I lose any more of my SW friends, let me say at once that
>> I am NOT arguing for this change to RDF.
>
> so after hundreds of emails, I have to ask - what (the hell) defines RDF?
>
> I've read that 'The RDF Semantics as stated works fine with triples which
> have any kind of syntactic node in any position in any combination.'
>
> Do the 'RDF Semantics' define RDF? or do the serializations?
>
> simply - does RDF support literal subjects or not - I've read the
> aforementioned sentence to read 'RDF Semantics support literal subjects' or
> should I be reading 'RDF Semantics could support literal subjects' or 'does
> support literal subjects' or?
>
> Just seeking a definitive bit of clarity on 1: what defines RDF, 2: what is
> *currently* supported in that definition.

According to this recommendation, it doesn't support any kind of node
in any position:

http://www.w3.org/TR/rdf-concepts/#section-Literals

So no, it's not something serialisation-specific.

Best,
y

>
> Preferably a serialization unspecific answer :)
>
> Best & TIA,
>
> Nathan
>
>

Re: Subjects as Literals

[Nathan]

Pat Hayes wrote:
However, before I lose any more of my SW friends, let me say at once 
that I am NOT arguing for this change to RDF.


so after hundreds of emails, I have to ask - what (the hell) defines RDF?

I've read that 'The RDF Semantics as stated works fine with triples 
which have any kind of syntactic node in any position in any combination.'


Do the 'RDF Semantics' define RDF? or do the serializations?

simply - does RDF support literal subjects or not - I've read the 
aforementioned sentence to read 'RDF Semantics support literal subjects' 
or should I be reading 'RDF Semantics could support literal subjects' or 
'does support literal subjects' or?


Just seeking a definitive bit of clarity on 1: what defines RDF, 2: what 
is *currently* supported in that definition.


Preferably a serialization unspecific answer :)

Best & TIA,

Nathan

RE: Subjects as Literals

[Michael Schneider]

+1

The fact that

"basically, all the upper levels of the Semantic Web layer 
cake are not based on RDF but on generalised RDF"

(see also my list of concrete citations at [1]) makes it, in my humble
opinion, essentially mandatory for an RDF working group to standardize
generalized RDF, i.e. subjects and bnodes in all positions of a triple.

In addition, I like your idea of having a "classic" syntactic fragment with
traditional RDF syntax, so older systems (or those for which their
implementers decide to not go to generalized RDF) will still have a standard
to conform to.

Best,
Michael

[1] <http://lists.w3.org/Archives/Public/semantic-web/2010Jul/0146.html>

>-Original Message-
>From: semantic-web-requ...@w3.org [mailto:semantic-web-requ...@w3.org]
>On Behalf Of Antoine Zimmermann
>Sent: Tuesday, July 06, 2010 9:54 PM
>To: Ivan Mikhailov
>Cc: public-lod@w3.org; Semantic Web
>Subject: Re: Subjects as Literals
>
>Ivan, all,
>
>
>Le 06/07/2010 18:00, Ivan Mikhailov a écrit :
> > After 7 days of discussion, are there any volunteers to implement
>this
> > proposal? Or you specify the wish and I should implement it (and
> > Kingsley should pay) for an unclear purpose? Sorry, no.
>
>
>Not only there are volunteers to implement tools which allow literals as
>subjects, but there are already implementations out there.
>As an example, take Ivan Herman's OWL 2 RL reasoner [1]. You can put
>triples with literals as subject, and it will reason with them.
>Here in DERI, we also have prototypes processing generalised triples.
>
>Other reasoners are dealing with literals as subjects. RIF
>implementations are also able to parse triples with literals as
>subjects, as it is required by the spec.
>
>In addition to the existing implementations, it should be noticed that
>the main standards built on top of RDF(S) (SPARQL, OWL 2, RIF) are all
>using generalised triples instead of the restrictive RDF triples. So,
>basically, all the upper levels of the Semantic Web layer cake are not
>based on RDF but on generalised RDF...
>
>Some people mentioned scalability issues when we allow literals as
>subject. It might be detrimental to the scalability of query engines
>over big triple stores, but allowing literals as subjects is perfectly
>scalable when it comes to inference materialisation (see recent work on
>computing the inference closure of 100 billion triples [2]).
>
>Considering this amount of usage and use cases, which is certainly meant
>to grow in the future, I believe that it is time to standardised
>generalised RDF. In addition, there are readily available serialisations
>for it (N3, or a straightforward extension of N-triple or Turtle) and a
>backward compatible extension of RDF/XML has been proposed in this
>thread (by Sandro Hawke).
>
>
>A possible compromise would be to define RDF 2 as /generalised RDF +
>named graphs + deprecate stuff/, and have a sublanguage (or profile)
>RDF# which forbids literals in subject and predicate positions, as well
>as bnodes in predicate position.
>Then SPARQL, OWL 2 and RIF would really refer to RDF 2 instead of each
>redifining generalised RDF. People implementing optimisations of triple
>stores would be implementing a W3C-approved part of RDF (namely, RDF#),
>just like people implementing OWL 2 QL implement part of OWL 2 for
>efficient data indexing and query answering.
>
>
>Honestly, it's just about putting a W3C stamp on things that some people
>are already using and doing. Just like named graphs and other stuff.
>Plus, it's an easy one since the semantics is already there.
>
>
>
>[1] http://www.ivan-herman.net/Misc/2008/owlrl/
>[2] Jacopo Urbani, Spyros Kotoulas, Jason Maassen, Frank van Harmelen,
>and Henri Bal. "OWL reasoning with WebPIE: calculating the closure of
>100 billion triples" in the proceedings of ESWC 2010.
>
>
>
>Regards,
>AZ.
>--
>Antoine Zimmermann
>Post-doctoral researcher at:
>Digital Enterprise Research Institute
>National University of Ireland, Galway
>IDA Business Park
>Lower Dangan
>Galway, Ireland
>antoine.zimmerm...@deri.org
>http://vmgal34.deri.ie/~antzim/

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schnei...@fzi.de
WWW  : http://www.fzi.de/michael.schneider
===
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
===

Re: Subjects as Literals

[Pat Hayes]

On Jul 6, 2010, at 2:05 AM, Toby Inkster wrote:


On Mon, 5 Jul 2010 17:43:17 -0500
Pat Hayes  wrote:


Well, nobody is suggesting allowing literals as predicates (although
in fact the RDF semantics would easily extend to this usage, if
required, and the analogous structures are allowed, and do have
genuine use cases, in ISO Common Logic.)


Actually, I have suggested allowing them just to make things simpler -
URIs, blank nodes and literals would all be allowed in any position.
However, a statement with a literal in the predicate position would be
officially defined to have no meaning.


Well (and now we really are in the ivory tower, by the way), the  
"right" thing to do here is to follow the semantics. The RDF semantics  
(http://www.w3.org/TR/rdf-mt/#interp) assumes that there is a mapping,  
called IEXT, from the universe to the set of property extensions. That  
universe, called IR in the mathematical jargon part of the spec, has a  
subset LV of literal values, which (well-formed) literals are required  
to denote. OK, so a literal denotes a literal value, to which - like  
anything else in the universe - the 'extension' mapping IEXT can be  
applied, making it meaningful to be used as a predicate in a triple.  
So in fact, the RDF semantics CAN handle triples with a literal in the  
property position, and they can be perfectly meaningful.


If you write something like {  "ab" "cd" "ef" . } and ask me what (the  
hell) it means, of course I have no idea; but then I also, and for the  
same reason, have no idea what { ex:ab ex:cd ex:ef . } means, either,  
until you show me some larger graph which uses these symbols in some  
organized way, ie an RDF "ontology" of some kind. But there is no need  
to declare that such literals-as-property triples MUST be meaningless.  
The semantics (and the entailment rules, etc.., suitably modified)  
work perfectly well on them, they can be allowed to have any meaning  
that anyone wants them to have, as long as they can somehow express  
that meaning in RDF and any surrounding semantic tools with enough  
clarity. And as I've said in other postings, when we allowed such  
constructions into CL, more as a matter of doctrine than with any  
actual applications in mind, to our great surprise they turned out to  
have several useful applications almost immediately. My experience is,  
in fact, that almost any syntactic structure that can be made to  
support a meaning will quickly find a use. Just to get your  
imagination working, one might for example say that a number used as a  
property means the property which raises its subject to that power, so  
it would be true to write


"2"^^xsd:number "3"^^xsd:number "8"^^xsd:number .

However, before I lose any more of my SW friends, let me say at once  
that I am NOT arguing for this change to RDF.


Pat Hayes




--
Toby A Inkster








IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

Re: Subjects as Literals

[Antoine Zimmermann]

I'd like to apologize in advance for being sarcastic, especially since I 
have really nothing against Henry... ;)



Le 06/07/2010 19:45, Henry Story a écrit :


This would be possible to say. The problem is that there would be no
way on earth that anyone could come to an agreement as to what kind
of property "lit" was. Everyone could make up defend their choice. And
where there is no right or wrong, there is no meaning. Hence the above
is undecidable.

What is the difference between the above and

foaf:knows a rdf:Property .


What is the difference between the above and

foaf:lit a rdf:Property .

Well, we can dereference it and /not/ find out what it means. This is 
possible to say. The problem is that there is no way on earth that 
anyone can come to an agreement as to what kind of property foaf:lit is. 
Everyone can make up defend their choice. And where there is no right or 
wrong, there is no meaning. Hence, the above is undecidable.


And therefore, URIs as subjects should be disallowed... ;)


Well we can dereference foaf:knows to find out what it means. This is
the canonical way to find it's meaning, and is the initial procedure we
should use to arbitrate between competing understandings of its meaning.

Henry



Cheers,
--
Antoine Zimmermann
Post-doctoral researcher at:
Digital Enterprise Research Institute
National University of Ireland, Galway
IDA Business Park
Lower Dangan
Galway, Ireland
antoine.zimmerm...@deri.org
http://vmgal34.deri.ie/~antzim/

Re: Subjects as Literals

[Antoine Zimmermann]

Ivan, all,


Le 06/07/2010 18:00, Ivan Mikhailov a écrit :
> After 7 days of discussion, are there any volunteers to implement this
> proposal? Or you specify the wish and I should implement it (and
> Kingsley should pay) for an unclear purpose? Sorry, no.


Not only there are volunteers to implement tools which allow literals as 
subjects, but there are already implementations out there.
As an example, take Ivan Herman's OWL 2 RL reasoner [1]. You can put 
triples with literals as subject, and it will reason with them.

Here in DERI, we also have prototypes processing generalised triples.

Other reasoners are dealing with literals as subjects. RIF 
implementations are also able to parse triples with literals as 
subjects, as it is required by the spec.


In addition to the existing implementations, it should be noticed that 
the main standards built on top of RDF(S) (SPARQL, OWL 2, RIF) are all 
using generalised triples instead of the restrictive RDF triples. So, 
basically, all the upper levels of the Semantic Web layer cake are not 
based on RDF but on generalised RDF...


Some people mentioned scalability issues when we allow literals as 
subject. It might be detrimental to the scalability of query engines 
over big triple stores, but allowing literals as subjects is perfectly 
scalable when it comes to inference materialisation (see recent work on 
computing the inference closure of 100 billion triples [2]).


Considering this amount of usage and use cases, which is certainly meant 
to grow in the future, I believe that it is time to standardised 
generalised RDF. In addition, there are readily available serialisations 
for it (N3, or a straightforward extension of N-triple or Turtle) and a 
backward compatible extension of RDF/XML has been proposed in this 
thread (by Sandro Hawke).



A possible compromise would be to define RDF 2 as /generalised RDF + 
named graphs + deprecate stuff/, and have a sublanguage (or profile) 
RDF# which forbids literals in subject and predicate positions, as well 
as bnodes in predicate position.
Then SPARQL, OWL 2 and RIF would really refer to RDF 2 instead of each 
redifining generalised RDF. People implementing optimisations of triple 
stores would be implementing a W3C-approved part of RDF (namely, RDF#), 
just like people implementing OWL 2 QL implement part of OWL 2 for 
efficient data indexing and query answering.



Honestly, it's just about putting a W3C stamp on things that some people 
are already using and doing. Just like named graphs and other stuff. 
Plus, it's an easy one since the semantics is already there.




[1] http://www.ivan-herman.net/Misc/2008/owlrl/
[2] Jacopo Urbani, Spyros Kotoulas, Jason Maassen, Frank van Harmelen, 
and Henri Bal. "OWL reasoning with WebPIE: calculating the closure of 
100 billion triples" in the proceedings of ESWC 2010.




Regards,
AZ.
--
Antoine Zimmermann
Post-doctoral researcher at:
Digital Enterprise Research Institute
National University of Ireland, Galway
IDA Business Park
Lower Dangan
Galway, Ireland
antoine.zimmerm...@deri.org
http://vmgal34.deri.ie/~antzim/

Re: Subjects as Literals

[Henry Story]

On 6 Jul 2010, at 14:03, Michael Schneider wrote:

> Toby Inkster:
> 
>> On Mon, 5 Jul 2010 17:43:17 -0500
>> Pat Hayes  wrote:
>> 
>>> Well, nobody is suggesting allowing literals as predicates (although
>>> in fact the RDF semantics would easily extend to this usage, if
>>> required, and the analogous structures are allowed, and do have
>>> genuine use cases, in ISO Common Logic.)
>> 
>> Actually, I have suggested allowing them just to make things simpler -
>> URIs, blank nodes and literals would all be allowed in any position.
>> However, a statement with a literal in the predicate position would be
>> officially defined to have no meaning.
> 
> So, if 
> 
>:s "lit" :o .
> 
> must not have a semantic meaning, what about
> 
>"lit" rdf:type rdf:Property .

This would be possible to say. The problem is that there would be no
way on earth that anyone could come to an agreement as to what kind
of property "lit" was. Everyone could make up defend their choice. And
where there is no right or wrong, there is no meaning. Hence the above 
is undecidable.

What is the difference between the above and

   foaf:knows a rdf:Property .

Well we can dereference foaf:knows to find out what it means. This is
the canonical way to find it's meaning, and is the initial procedure we
should use to arbitrate between competing understandings of its meaning.

Henry

Re: Subjects as Literals

[Toby Inkster]

On Tue, 6 Jul 2010 16:30:06 +0200
"Michael Schneider"  wrote:

> What do you mean by "false statement"?

False in the same sense that this is false:


foaf:name "Barry Chuckle" .

Whether it is provably false by an automated agent is debatable. It
doesn't violate any axioms; there are conceivable universes where it
is true. But in this one, it's false.

-- 
Toby A Inkster

Re: Subjects as Literals

[Nathan]

Ivan Mikhailov wrote:

After 7 days of discussion, are there any volunteers to implement this
proposal? Or you specify the wish and I should implement it (and
Kingsley should pay) for an unclear purpose? Sorry, no.

I should remind one more time: without two scheduled implementations
right now and two complete implementations at the CR time, the
discussion is just for fun.


AFAIK - 'The RDF Semantics as stated works fine with triples which have 
any kind of syntactic node in any position in any combination.' - it's 
only the common serializations which define + cater for a subset of 
'RDF' and prevent literal subjects.


For a long time people have been telling me that RDF/XML is not RDF, if 
people have built their triple/quad stores on the understanding that 
specific serializations of RDF define RDF itself then..?


I'd hope that RDF/XML and other common serializations don't change - but 
 I'd also hope that in the near future we will have an RDF 
serialization which does handle literal subjects (& predicates) - at 
that time it will be a business decision for each company to decide 
whether to use and support it or not.


Best,

Nathan

Re: Subjects as Literals

[Ivan Mikhailov]

After 7 days of discussion, are there any volunteers to implement this
proposal? Or you specify the wish and I should implement it (and
Kingsley should pay) for an unclear purpose? Sorry, no.

I should remind one more time: without two scheduled implementations
right now and two complete implementations at the CR time, the
discussion is just for fun.

Best Regards,

Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com

RE: Subjects as Literals

[Michael Schneider]

Toby Inkster wrote:

>On Tue, 6 Jul 2010 14:03:19 +0200
>"Michael Schneider"  wrote:
>
>> So, if
>>
>> :s "lit" :o .
>>
>> must not have a semantic meaning, what about
>>
>> "lit" rdf:type rdf:Property .
>>
>> ? As, according to what you say above, you are willing to allow for
>> literals in subject position, this triple is fine for you
>> syntactically. But what about its meaning? Would this also be
>> officially defined to have no meaning?
>
>It would have a meaning. It would just be a false statement. 

What do you mean by "false statement"? That it is contradictory, as in OWL
for

  ex:x owl:differentFrom ex:x .

? If so, then this would be a very strong meaning. Quite different from
having no meaning at all.

>The same as the following is a false statement:
>
>   foaf:Person a rdf:Property .

Under which semantics is this a false statement?

Michael

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schnei...@fzi.de
WWW  : http://www.fzi.de/michael.schneider
===
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
===

Re: Subjects as Literals

[Toby Inkster]

On Tue, 6 Jul 2010 14:03:19 +0200
"Michael Schneider"  wrote:

> So, if 
> 
> :s "lit" :o .
> 
> must not have a semantic meaning, what about
> 
> "lit" rdf:type rdf:Property .
> 
> ? As, according to what you say above, you are willing to allow for
> literals in subject position, this triple is fine for you
> syntactically. But what about its meaning? Would this also be
> officially defined to have no meaning?

It would have a meaning. It would just be a false statement. The
same as the following is a false statement:

foaf:Person a rdf:Property .

-- 
Toby A Inkster

RE: Subjects as Literals

[Michael Schneider]

Toby Inkster:

>On Mon, 5 Jul 2010 17:43:17 -0500
>Pat Hayes  wrote:
>
>> Well, nobody is suggesting allowing literals as predicates (although
>> in fact the RDF semantics would easily extend to this usage, if
>> required, and the analogous structures are allowed, and do have
>> genuine use cases, in ISO Common Logic.)
>
>Actually, I have suggested allowing them just to make things simpler -
>URIs, blank nodes and literals would all be allowed in any position.
>However, a statement with a literal in the predicate position would be
>officially defined to have no meaning.

So, if 

:s "lit" :o .

must not have a semantic meaning, what about

"lit" rdf:type rdf:Property .

? As, according to what you say above, you are willing to allow for literals
in subject position, this triple is fine for you syntactically. But what
about its meaning? Would this also be officially defined to have no meaning?
And if so, only this special kind of typing triple with rdf:Property as its
object? Or all typing triples with literal subjects (this would exclude one
of Pat's usecases)? Or even all triples with literal subjects?

But, assume that this triple does not have a semantics, what about

:p rdfs:range rdf:Property .
:s :p "lit" .

This triple actually /has/ a semantic meaning in the /current/ specification
of RDFS. And this meaning indeed includes the meaning of the previous
example, namely that the resource denoted by the literal "lit" is an
instance of the class rdf:Property, that is, the literal denotes a property.

Or what about

:p owl:sameAs "lit" .
:s :p :o .

This is also allowed in current RDFS, and in OWL *) this triple even has the
same meaning as

:s "lit" :o . 

So we are back at the start.

Any idea, how to cope with this all? Semantically? Syntactically?

Michael

(* To be precise, the two examples are equivalent under the OWL 2 RDF-Based
Semantics [1], which is the semantics of OWL 2 Full, and which explicitly
allows literals in all positions of a triple.

[1] 

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schnei...@fzi.de
WWW  : http://www.fzi.de/michael.schneider
===
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
===

Re: Subjects as Literals

[Nathan]

Danny Ayers wrote:

I've been studiously avoiding this rat king of a thread, but just on
this suggestion:

On 2 July 2010 11:16, Reto Bachmann-Gmuer  wrote:
...

Serialization formats could support

"Jo" :nameOf :Jo

as a shortcut for

[ owl:sameAs "Jo"; :nameOf :Jo]

and a store could (internally) store the latter as

"Jo" :nameOf :Jo

for compactness and efficiency.


what about keeping the internal storage idea, but instead of owl:sameAs, using:

:Jo rdfs:value "Jo"

together with

:Jo rdf:type rdfs:Literal

?


1: is there and rdfs:value? (rdf:value)

2: I would *love* to see rdf:value with a usable tight definition that 
everybody can rely on


Best,

Nathan

Re: Subjects as Literals

[Henry Story]

On 6 Jul 2010, at 09:19, Dan Brickley wrote:

> On Tue, Jul 6, 2010 at 12:40 AM, Hugh Glaser  wrote:
>> Hi Sampo.
>> I venture in again...
>> I have much enjoyed the interchanges, and they have illuminated a number of
>> cultural differences for me, which have helped me understand why some people
>> have disagree with things that seem clear to me.
>> A particular problem in this realm has been characterised as
>> S-P-O v. O-R-O and I suspect that this reflects a Semantic Web/Linked Data
>> cultural difference, although the alignment will not be perfect.
>> I see I am clearly in the latter camp.
>> Some responses below.
> 
> 
> imho RDF processing requires both perspectives, and neither is more
> semwebby or linky than the other.

I agree with what you say here Dan, though I don't think it has anything
to do with S-P-O or O-R-O.

That we have different graphs and that they can be merged are furthermore
complimentary and essential to the semantic web. The RDF Semantics in my
view clearly contains the notions of separate graphs, since it shows how
they should be merged when *both are considered to be True*! Therefore 
if two graphs are not considered to be true there is no requirement to
merge them. This is quite clear in the talk of possible worlds from the RDF 
Semantics document

[[
The basic intuition of model-theoretic semantics is that asserting a sentence 
makes a claim about the world: it is another way of saying that the world is, 
in fact, so arranged as to be an interpretation which makes the sentence true. 
In other words, an assertion amounts to stating aconstraint on the possible 
ways the world might be. 
]]

( In this way of thinking about things relations are thought of as sentences. 
So this is just one more way of thinking of the relations in addition to S-P-O 
or O-R-O)

Now it is quite clear from the above that when one has two incompatible graphs, 
then both of them still have meaning. They both can describe possible ways the 
world can be. It is just that merging them will lead to the set of all possible 
worlds: ie, nothing will be said. 

RDF is a relational semantics. The model is arrows between things. That
the serialisations don't allow literals in predicate position is a syntactic
restriction, not a semantic one: because semantically one just cannot
impose such a restriction. It is very clear that there are relations between 
numbers for example.


> 
> On a good day, we can believe what an RDF doc tells us. It does so in
> terms of objects/things and their properties and relationships (o-r-o
> i guess). On another day, we have larger collections of RDF to curate,
> and need to keep track more carefully of who is claiming what about
> these object properties; that's the provenance and quads perspective,
> s-p-o.

As mentioned above o-r-o or s-p-o way of thinking of relations are in my
view ways of thinking of exactly the same thing: arrows between things, or 
relations. This has no bearing on the quads or triple perspective.


> Note that the subject/predicate/object terminology comes from
> the old M&S spec which introduced reification in a ham-fisted attempt
> to handle some of this trust-ish stuff, and that most simple data'
> -oriented stuff uses SPARQL, the only W3C formal spec that covers
> quads rather than triples. So I don't think the community splits
> neatly into two on this, and that's probably for the best!
> 
> RDF processing, specs and tooling are about being able to jump in a
> fluid and natural way between these two views of data; dipping down
> into the 'view from one graph', or zooming out to see the bigger
> picture of who says what.

These are one and the same view. It is just a question of which
world you think is the actual one: ie a question of indexicality. Which 
world am I in.

> Neither is correct, and it is natural for
> the terminology to change to capture the shifting emphasis. But until
> we make this landscape clearer, people will be confused -- when is it
> an attribute or property, and when is it a predicate?

Attribute, property, sentence, these are just the slightly different
ways of saying the same thing. If you try to look here for a solution
to the bigger problem you will not find it. The place to look is at the
possible world semantic level. 

Henry

> 
> cheers,
> 
> Dan
> 
> --
> "There are two kinds of people in the world, those who believe there
> are two kinds of people in the world and those who don't." --Benchley
> 

Re: Subjects as Literals

[Robert Fuller]

+1

On 06/07/10 09:23, Danny Ayers wrote:

I've been studiously avoiding this rat king of a thread, but just on
this suggestion:

On 2 July 2010 11:16, Reto Bachmann-Gmuer  wrote:
...

Serialization formats could support

"Jo" :nameOf :Jo

as a shortcut for

[ owl:sameAs "Jo"; :nameOf :Jo]

and a store could (internally) store the latter as

"Jo" :nameOf :Jo

for compactness and efficiency.


what about keeping the internal storage idea, but instead of owl:sameAs, using:

:Jo rdfs:value "Jo"

together with

:Jo rdf:type rdfs:Literal

?

Cheers,
Danny.



--
Robert Fuller
Research Associate
Sindice Team
DERI, Galway
http://sindice.com/

Re: Subjects as Literals

[Danny Ayers]

I've been studiously avoiding this rat king of a thread, but just on
this suggestion:

On 2 July 2010 11:16, Reto Bachmann-Gmuer  wrote:
...
> Serialization formats could support
>
> "Jo" :nameOf :Jo
>
> as a shortcut for
>
> [ owl:sameAs "Jo"; :nameOf :Jo]
>
> and a store could (internally) store the latter as
>
> "Jo" :nameOf :Jo
>
> for compactness and efficiency.

what about keeping the internal storage idea, but instead of owl:sameAs, using:

:Jo rdfs:value "Jo"

together with

:Jo rdf:type rdfs:Literal

?

Cheers,
Danny.

-- 
http://danny.ayers.name

Re: Subjects as Literals

[Dan Brickley]

On Tue, Jul 6, 2010 at 12:40 AM, Hugh Glaser  wrote:
> Hi Sampo.
> I venture in again...
> I have much enjoyed the interchanges, and they have illuminated a number of
> cultural differences for me, which have helped me understand why some people
> have disagree with things that seem clear to me.
> A particular problem in this realm has been characterised as
> S-P-O v. O-R-O and I suspect that this reflects a Semantic Web/Linked Data
> cultural difference, although the alignment will not be perfect.
> I see I am clearly in the latter camp.
> Some responses below.


imho RDF processing requires both perspectives, and neither is more
semwebby or linky than the other.

On a good day, we can believe what an RDF doc tells us. It does so in
terms of objects/things and their properties and relationships (o-r-o
i guess). On another day, we have larger collections of RDF to curate,
and need to keep track more carefully of who is claiming what about
these object properties; that's the provenance and quads perspective,
s-p-o. Note that the subject/predicate/object terminology comes from
the old M&S spec which introduced reification in a ham-fisted attempt
to handle some of this trust-ish stuff, and that most simple data'
-oriented stuff uses SPARQL, the only W3C formal spec that covers
quads rather than triples. So I don't think the community splits
neatly into two on this, and that's probably for the best!

RDF processing, specs and tooling are about being able to jump in a
fluid and natural way between these two views of data; dipping down
into the 'view from one graph', or zooming out to see the bigger
picture of who says what. Neither is correct, and it is natural for
the terminology to change to capture the shifting emphasis. But until
we make this landscape clearer, people will be confused -- when is it
an attribute or property, and when is it a predicate?

cheers,

Dan

--
"There are two kinds of people in the world, those who believe there
are two kinds of people in the world and those who don't." --Benchley

Re: Subjects as Literals

[Toby Inkster]

On Mon, 5 Jul 2010 17:43:17 -0500
Pat Hayes  wrote:

> Well, nobody is suggesting allowing literals as predicates (although  
> in fact the RDF semantics would easily extend to this usage, if  
> required, and the analogous structures are allowed, and do have  
> genuine use cases, in ISO Common Logic.)

Actually, I have suggested allowing them just to make things simpler -
URIs, blank nodes and literals would all be allowed in any position.
However, a statement with a literal in the predicate position would be
officially defined to have no meaning.

-- 
Toby A Inkster

Re: Subjects as Literals

[Pat Hayes]

Not wanting to keep beating this particular drum, but some things just  
have to be responded to.


On Jul 5, 2010, at 1:36 PM, Sampo Syreeni wrote:


On 2010-06-30, Hugh Glaser wrote:

RDF permits anyone to say anything about anything . . . except a  
literal if it is the subject of the property you want to use for  
the description.


The way I see it, the main reason for this restriction is that the  
data is supposed to be machine processable. Literals rarely are,  
especially in their original, plain form.


This objection strikes me as completely wrong-headed. Of course  
literals are machine processable.


I mean, suppose we allowed literals as subject, predicate and  
object. What does it really mean if I say "Sally"@en "likes"@en  
"Mike"@en?


Well, nobody is suggesting allowing literals as predicates (although  
in fact the RDF semantics would easily extend to this usage, if  
required, and the analogous structures are allowed, and do have  
genuine use cases, in ISO Common Logic.) But it is easy to give  
'ridiculous' examples for any syntactic possibility. I can write  
apparent nonsense using nothing but URIs, but this is not an argument  
for disallowing URIs in RDF.


I'd argue pretty much nothing processable. That's because literals  
tack on an arbitrary, limited number of type specifiers (type and  
perhaps language) to textual data, and neglect everything beyond  
that. That is not how full disambiguation is done; it's how a human  
processor *minimally* disambiguates a piece of text, without making  
it unambiguous.


This is WRONG. The type specifiers *completely* disambiguate the text  
in the body of the literal. Really, this is not a topic for debate in  
a public email list. Just check the actual RDF specifications, in  
particular http://www.w3.org/TR/rdf-mt/#dtype_interp . For plain  
literals, the meaning of the literal is the string itself, a unique  
string of characters. Again, this is stated in the RDF specification  
documents as a normative part of the RDF spec.


With Schema derived or otherwise strictly derived types, the level  
of disambiguation can be the same as or even better than with URI's,  
true. But then that goes the other way around, too: URI's could take  
the place of any such precise type.


No, they cannot. For numbers, for example, one would need infinitely  
many URIs; but in any case, why bother creating all these URIs? We  
have (universally understood) names for the numbers already, called  
numerals. For dates, times and so forth, there are many formats in use  
throughout human societies, of course. That is WHY the work of  
establishing datatype standards work was done. To ignore all this, to  
reject a widely accepted standard, and advocate reversion to a home- 
made URI scheme seems to me to be blatantly irresponsible.


Pat Hayes


IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

Re: Subjects as Literals

[Hugh Glaser]

Hi Sampo.
I venture in again...
I have much enjoyed the interchanges, and they have illuminated a number of
cultural differences for me, which have helped me understand why some people
have disagree with things that seem clear to me.
A particular problem in this realm has been characterised as
S-P-O v. O-R-O and I suspect that this reflects a Semantic Web/Linked Data
cultural difference, although the alignment will not be perfect.
I see I am clearly in the latter camp.
Some responses below.


On 05/07/2010 19:36, "Sampo Syreeni"  wrote:

> On 2010-06-30, Hugh Glaser wrote:
> 
>> RDF permits anyone to say anything about anything . . . except a
>> literal if it is the subject of the property you want to use for the
>> description.
> 
> The way I see it, the main reason for this restriction is that the data
> is supposed to be machine processable. Literals rarely are, especially
> in their original, plain form. I mean, suppose we allowed literals as
> subject, predicate and object. What does it really mean if I say
> "Sally"@en "likes"@en "Mike"@en?
> 
> I'd argue pretty much nothing processable. That's because literals tack
> on an arbitrary, limited number of type specifiers (type and perhaps
> language) to textual data, and neglect everything beyond that. That is
> not how full disambiguation is done; it's how a human processor
> *minimally* disambiguates a piece of text, without making it
> unambiguous.
> 
> With Schema derived or otherwise strictly derived types, the level of
> disambiguation can be the same as or even better than with URI's, true.
> But then that goes the other way around, too: URI's could take the place
> of any such precise type. Beyond that, all that literals do is invite
> people to import more ambiguity into the RDF/SemWeb framework.
> 
> So, better to limit that to the object, in case we just *have* to have
> it somewhere. (I'd rather do without entirely.)
You see this as a problem of having a literal in the "subject" position.
I might equally decide it is a problem with having literal in the "object"
position.
Literals are literals wherever they appear - they have no deeper semantics,
and they certainly do not identify anything other than the literal that they
are, if that makes sense.
> 
>> So I can say: foo:booth isNamed "David Booth" But of course I can't
>> say: "David Booth" isNameOf foo:booth
> 
> You can say the same thing, as you pointed out. So you're aiming at
> grammatical symmetry in excess of expressive capability. Why? There is
> definite value in making the relation asymmetric: that way you can be
> surer that what is being talked about stays...the subject. It's not by
> any means sure that that is really going to be useful, no.
Ah, perhaps the nub.
The "subject" is no more the thing "being talked about" than the "object".
I am not asking for symmetry of the grammar, if I understand what you mean.
I am asking for the freedom to express the statements I want in the way I
want, so that I can query the way I want.
At the risk of repeating myself:
If someone wants to say "666" foo:isTheNumberOf bar:theBeast
and I have to tell them (as I do) ah, you can't say that, you need to
introduce a resource numbers:666 rdfs:label "666". ...
or  bar:theBeast foo:hasNumber "666"
I actually feel pretty stupid, having told them that RDF represents
relations in a natural and basic way.
In fact, I always feel a bit embarrassed when I get to the bit in my slides
that shows there are two sorts of triples, as I have just said that the
triples are just a directed graph.
> 
> But at the same time it's perfectly sure that you would have to start
> employing triples with both the subject and the object a literal, before
> the current model can constrain you semantically. That'd then be pretty
> extreme: the precise semantics of literals are tricky enough as they
> stand. Pretty much the only genuine use cases I can come up with
> off-hand are explicit unit conversions and label translations -- and
> then anything that goes that far should probably get URI's and/or
> epi-RDF conversion code in the first place. After all, both scenarios
> also call for context, which might have to be disambiguated beyond
> mere lexical form and type. (E.g. homologues or units with identical
> dimensions but different usage.)
I think you might be sort of agreeing here, but I don't understand all this
discussion of context that has been going on.
People seem to be somehow assuming that a literal in position one implies
more "context" than one in position three, which seems strange to me.
I guess that is because I am O-R-O, not S-P-O.

All that being said, I am still worried about the costs of any change,
compared to value returned.
Although some recent posts have suggested that it is not such a bad thing.

Best
Hugh

Re: Subjects as Literals

[Sampo Syreeni]

On 2010-06-30, Hugh Glaser wrote:

RDF permits anyone to say anything about anything . . . except a 
literal if it is the subject of the property you want to use for the 
description.


The way I see it, the main reason for this restriction is that the data 
is supposed to be machine processable. Literals rarely are, especially 
in their original, plain form. I mean, suppose we allowed literals as 
subject, predicate and object. What does it really mean if I say 
"Sally"@en "likes"@en "Mike"@en?


I'd argue pretty much nothing processable. That's because literals tack 
on an arbitrary, limited number of type specifiers (type and perhaps 
language) to textual data, and neglect everything beyond that. That is 
not how full disambiguation is done; it's how a human processor 
*minimally* disambiguates a piece of text, without making it 
unambiguous.


With Schema derived or otherwise strictly derived types, the level of 
disambiguation can be the same as or even better than with URI's, true. 
But then that goes the other way around, too: URI's could take the place 
of any such precise type. Beyond that, all that literals do is invite 
people to import more ambiguity into the RDF/SemWeb framework.


So, better to limit that to the object, in case we just *have* to have 
it somewhere. (I'd rather do without entirely.)


So I can say: foo:booth isNamed "David Booth" But of course I can't 
say: "David Booth" isNameOf foo:booth


You can say the same thing, as you pointed out. So you're aiming at 
grammatical symmetry in excess of expressive capability. Why? There is 
definite value in making the relation asymmetric: that way you can be 
surer that what is being talked about stays...the subject. It's not by 
any means sure that that is really going to be useful, no.


But at the same time it's perfectly sure that you would have to start 
employing triples with both the subject and the object a literal, before 
the current model can constrain you semantically. That'd then be pretty 
extreme: the precise semantics of literals are tricky enough as they 
stand. Pretty much the only genuine use cases I can come up with 
off-hand are explicit unit conversions and label translations -- and 
then anything that goes that far should probably get URI's and/or 
epi-RDF conversion code in the first place. After all, both scenarios 
also call for context, which might have to be disambiguated beyond 
mere lexical form and type. (E.g. homologues or units with identical 
dimensions but different usage.)

--
Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Axel Rauschmayer]

>> I use RDF like a next-generation relational database and think that RDF 
>> could be sold to many people this way (there is possibly are larger audience 
>> for this than for ontologies, reasoning, etc.). Especially considering how 
>> No-SQL is currently taking off. This part needs some love and seems to 
>> suffer from the almost exclusive focus on semantics.
> 
> Fair enough. I guess Im not sure how this next-generation-RDB usage fits with 
> the RDF semantics, but I'd be interested in pursuing this further. Does this 
> RDF/RDB++ vision provide any guidance towards what RDF is supposed to, like, 
> mean? Pointers?

Does it have to mean anything? I’ve always found tuple calculus and relational 
algebra quite intuitive, but as far as I remember, it is very light on 
semantics, everything is "just data". URIs as symbols are useful, but I would 
not know how to express the concepts they represent formally. What else is 
needed? A simple schema language, which should probably assume a closed world 
and unique names (unless specified otherwise). I’m surprised how something that 
is trivial (and common!) for relational databases is very hard for SPARQL (for 
example, letting SPARQL return a table where each row is a resource [1]).

Additionally, it would be useful if SPARQL allowed one to do backward-chaining 
via rules (some RIF implementations seem to do this). I can only come up with a 
few use-cases (sub-properties, transitive properties), but those would 
definitely help.

[1] http://www.w3.org/2009/12/rdf-ws/papers/ws17

There might not be anything in it, scientifically, but it would help to sell 
RDF to a community that is largely orthogonal to the one that is after RDF + 
semantics.

-- 
Dr. Axel Rauschmayer
axel.rauschma...@ifi.lmu.de
http://hypergraphs.de/
### Hyena: connected information manager, free at hypergraphs.de/hyena/

Re: Show me the money - (was Subjects as Literals)

[Andy Seaborne]

The other economic-like argument is that there is only so much developer 
bandwidth in the world, whether open source or proprietary.  Do you 
think that bandwidth should be applied to changing current code to track 
changes, to making existing systems more usable, or (open source) on 
supporting users?


Andy

(Disclaimer: I'm sure some email somewhere makes the same point.  But.)

On 01/07/2010 4:38 PM, Jeremy Carroll wrote:


I am still not hearing any argument to justify the costs of literals as
subjects

I have loads and loads of code, both open source and commercial that
assumes throughout that a node in a subject position is not a literal,
and a node in a predicate position is a URI node.

Of course, the "correct" thing to do is to allow all three node types in
all three positions. (Well four if we take the graph name as well!)

But if we make a change, all of my code base will need to be checked for
this issue.
This costs my company maybe $100K (very roughly)
No one has even showed me $1K of advantage for this change.

It is a no brainer not to do the fix even if it is technically correct

Jeremy

Re: Show me the money - (was Subjects as Literals)

[John Erickson]

I greatly respect Jeremy's thoughts, and they may be spot-on in this
case, but I urge the community to be cautious about how much weight to
give this kind of "pragmatic" economics-driven argument generally as
the semantic technology industry grows.

Virtually every organization has -- should have! -- increasing "vested
interests" in their own unique approach. In many cases, their
stakeholders may be better-served by maintaining the status quo; many
others will be served by upsetting the collective apple cart. Progress
is made collectively by hearing out and sometimes acting on
well-reasoned arguments from the other side, even if the implications
are changing one's code base!

Industry consortia move things that look and smell like standards --
W3C recommendations -- ahead by appealing to the "greater good." Thus
I interpret Jeremy's comments as not a call to halt progress; rather,
he's simply asking for a strong case be made that the proposed changes
would benefit the *community* in a compelling way. He's asking for
well-reasoned arguments for change that colleagues around the
ecosystem might present to their grumpy, grey-suited, money-grubbing,
cigar-smoking management ;)

John

On Sun, Jul 4, 2010 at 10:51 PM, Jeremy Carroll  wrote:
>  On 7/1/2010 8:44 PM, Pat Hayes wrote:
>>
>> Jeremy, your argument is perfectly sound from your company's POV, but not
>> from a broader perspective. Of course, any change will incur costs by those
>> who have based their assumptions upon no change happening
>
> I was asking for the economic benefit of the change, as opposed to the
> elegance benefit.
> Personally, I am wholly convinced by the elegance argument - but it will not
> convince my management, nor should it.
>
> I suspect there are several other companies and other open source activities
> that have investments that assume literals do not occur in subject position.
>
> Elegance is not, IMO, a sufficient argument to negate those investments.
> (The sort of thing we are talking about, is what sort of display is
> appropriate for a subject of a triple - we know that it is not a literal, so
> certain code paths, and options are not considered).
>
> Of course, in an industrial consortium costs to one member maybe justified
> by benefits to another - but costs to any member do need to be offset by
> some benefit to some member ... I have yet to see much of an argument (Henry
> got a small bit of the way), that there are any such benefits (i.e. ones
> which have a dollar, euro or yuan value). I have pointed to dollar costs ...
> I expect to see some such benefit. I don't think that expectation is
> unreasonable, more a boundary that keeps people honest ... and not just
> indulging in an intellectual game (he says politely).
>
> Jeremy
>
>
>
>
>



-- 
John S. Erickson, Ph.D.
http://bitwacker.wordpress.com
olyerick...@gmail.com
Twitter: @olyerickson

Re: Show me the money - (was Subjects as Literals)

[Jeremy Carroll]

 On 7/1/2010 8:44 PM, Pat Hayes wrote:
Jeremy, your argument is perfectly sound from your company's POV, but 
not from a broader perspective. Of course, any change will incur costs 
by those who have based their assumptions upon no change happening


I was asking for the economic benefit of the change, as opposed to the 
elegance benefit.
Personally, I am wholly convinced by the elegance argument - but it will 
not convince my management, nor should it.


I suspect there are several other companies and other open source 
activities that have investments that assume literals do not occur in 
subject position.


Elegance is not, IMO, a sufficient argument to negate those investments.
(The sort of thing we are talking about, is what sort of display is 
appropriate for a subject of a triple - we know that it is not a 
literal, so certain code paths, and options are not considered).


Of course, in an industrial consortium costs to one member maybe 
justified by benefits to another - but costs to any member do need to be 
offset by some benefit to some member ... I have yet to see much of an 
argument (Henry got a small bit of the way), that there are any such 
benefits (i.e. ones which have a dollar, euro or yuan value). I have 
pointed to dollar costs ... I expect to see some such benefit. I don't 
think that expectation is unreasonable, more a boundary that keeps 
people honest ... and not just indulging in an intellectual game (he 
says politely).


Jeremy

RE: Subjects as Literals, [was Re: The Ordered List Ontology]

[Michael Schneider]

On Behalf Of Nathan wrote on Friday, July 02:

>Pat Hayes wrote:
>> On Jul 1, 2010, at 11:18 AM, Yves Raimond wrote:
>>> "A literal may be the object of an RDF statement, but not the subject
>>> or the predicate."
>>
>> Just to clarify, this is a purely syntactic restriction. Allowing
>> literals in subject position would require **no change at all** to the
>> RDF semantics. (The non-normative inference rules for RDF and RDFS and
>> D-entailment given in the semantics document would need revision, but
>> they would then be simplified.)
>
>I have to wonder then, what can one all place in the s,p,o slots without
>changing the RDF semantics? literal and bnode predicates for instance?

Short answer: you can put URIs, literals and bNodes in all three positions
of a triple, without needing to touch the current RDF semantics spec. 

Longer answer:
 
The syntactic restrictions of RDF (no literal subjects, no literal or bnode
predicates) are not "checked" by the semantic conditions of the RDF
semantics. Every node in a triple is (in a first "step") simply related to
some resource in the interpreted universe. For URI nodes this is probably
clear, but even literals are meant to represent resources: all datavalues
are treated as resources in RDF! bNodes are a bit different, since they do
not stand directly for a specific resource, but indicate that some resource
/exists/. 

But, in the end, all you receive from the interpretation of all the nodes
occurring in an RDF triple is essentially a binary relationships between two
resources. And the rest of the semantics specification of RDF(S), and even
of OWL Full, works exclusively on these kinds of sets of binary
relationships, below the "syntax surface", so to speak. So the whole stack
of RDF-based semantics is ready to be used with "generalized" RDF out of the
box -- just waiting for the RDF syntax to give up its restrictiveness. :-)

As a special note: Even bNode predicates, and even literal predicates are
allowed in the RDF semantics and make sense (in a technical sense, at
least), because: 

  (a) Properties are also treated as regular resources by the RDF semantics.
They have some binary relation "attached" to them (in order to allow to use
them to relate two resources), but you can still treat them like any other
resource, e.g. relate themselves to another resource by some other
property).

  (b) Literals stand for data value resources, and nothing stops a data
value resource from being used as a predicate resource. (I leave it to the
philosophers here in the list to debate whether this is good use or bad use
in practice.) 

>variables or formulae as in n3?

For formulae: Certainly "no", since formulae are normally not interpreted to
denote resources, but are assertions being interpreted by a truth value. 

For variables: Firstly, /existentially/ quantified variables are already
treated, since they are represented by bNodes. Remains /universally/
quantified variables, as they exist in N3. Supporting them would definitely
need /some/ extension of the RDF semantics, since it has at least to be said
how such variables are interpreted (this is only said for URIs, plain and
typed literals, and for bNodes so far in the spec, see Sections 1.4 and 1.5
of the RDF Semantics [1]). I just cannot tell how much extension would be
required without more deeply thinking about it. So this question keeps open
from my side at the moment. Maybe Pat has an answer?
 
>read as: if a new serialization/syntax was defined for RDF what are the
>limitations for the values of node/object and relationship specified by
>the RDF Semantics?
>
>Best,
>
>Nathan
>
>ps: apologies if this is a dumb question, I fear i'd still be hear next
>year trying to answer it myself though ;)

Not dump at all. Technically pretty demanding, in fact.

Cheers,
Michael
 
[1] 

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schnei...@fzi.de
WWW  : http://www.fzi.de/michael.schneider
===
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
===

RE: Show me the money - (was Subjects as Literals)

[Michael Schneider]

Henry Story wrote:

>So just as a matter of interest, imagine a new syntax came along that
>allowed literals in
>subject position, could you not write a serialiser for it that turned
>
>"123" length 3 .
>
>Into
>
>_:b owl:sameAs "123";
>   length 3.

But this is not an equivalent translation in RDF(S). 

The URI owl:sameAs has no specific meaning in RDF(S); you could likewise
write "ex:yz" instead. Only OWL tools, or at least RDF(S) tools with
additional support for owl:sameAs would be able to understand what you are
intending here. For other RDF tools, you are just asserting that there is
some resource with two properties, but the values of these two properties
are in no way related to each other -- quite in contrast to the original
triple.

So this should certainly not be suggested as "best practice" in an RDF
context.

Michael

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schnei...@fzi.de
WWW  : http://www.fzi.de/michael.schneider
===
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
===

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Haijie.Peng]

On 2010/7/1 22:35, Kingsley Idehen wrote:

Yves Raimond wrote:

Hello Kingsley!


[snip]


IMHO an emphatic NO.

RDF is about constructing structured descriptions where "Subjects" have
Identifiers in the form of Name References (which may or many 
resolve to

Structured Representations of Referents carried or borne by Descriptor
Docs/Resources). An "Identifier" != Literal.

If you are in a situation where you can't or don't want to mint an HTTP
based Name, simply use a URN, it does the job.


It does look like you're already using literal subjects in OpenLink
Virtuoso though:

http://docs.openlinksw.com/virtuoso/rdfsparql.html

SQL>SELECT *
FROM 
WHERE
{
?s foaf:Name ?name . ?name bif:contains "'rich*'".
}

Best,
y



Were is the Literal Subject in the query above?

bif:contains is a function/magic predicate scoped to Literal Objects.

 != "people".

Let's consider the following inequality:
people != people
if we imposed different interpretations on both sides，then we certainly 
could conclude the first 'people' is non-equivalence to the second 
'people' in semantic. Semantic of things is not reflected in the literal 
meaning, but is reflected in interpreter's behavior and its impact on 
the environment/world.


my two cents.

regards

Peng



What am I missing?

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Haijie.Peng]

On 2010/7/1 22:42, Kingsley Idehen wrote:

Pat Hayes wrote:


On Jun 30, 2010, at 3:49 PM, Kingsley Idehen wrote:


Pat Hayes wrote:


On Jun 30, 2010, at 1:30 PM, Kingsley Idehen wrote:


Nathan wrote:

Pat Hayes wrote:

On Jun 30, 2010, at 6:45 AM, Toby Inkster wrote:

On Wed, 30 Jun 2010 10:54:20 +0100
Dan Brickley  wrote:
That said, i'm sure sameAs and differentIndividual (or however 
it is

called) claims could probably make a mess, if added or removed...


You can create some pretty awesome messes even without OWL:

  # An rdf:List that loops around...

<#mylist> a rdf:List ;
  rdf:first <#Alice> ;
  rdf:next <#mylist> .

  # A looping, branching mess...

<#anotherlist> a rdf:List ;
  rdf:first <#anotherlist> ;
  rdf:next <#anotherlist> .



They might be messy, but they are *possible* structures using 
pointers, which is what the RDF vocabulary describes.  Its just 
about impossible to guarantee that messes can't happen when all 
you are doing is describing structures in an open-world setting. 
But I think the cure is to stop thinking that possible-messes 
are a problem to be solved. So, there is dung in the road. Walk 
round it.




Could we also apply that to the 'subjects as literals' general 
discussion that's going on then?


For example I've heard people saying that it encourages bad 
'linked data' practise by using examples like { 'London' a 
x:Place } - whereas I'd immediately counter with { x:London a 
'Place' }.


Surely all of the subjects as literals arguments can be countered 
with 'walk round it', and further good practise could be aided by 
a few simple notes on best practise for linked data etc.


IMHO an emphatic NO.

RDF is about constructing structured descriptions where "Subjects" 
have Identifiers in the form of Name References (which may or many 
resolve to Structured Representations of Referents carried or 
borne by Descriptor Docs/Resources). An "Identifier" != Literal.


What ARE you talking about? You sound like someone reciting doctrine.

Literals in RDF are just as much 'identifiers' or 'names' as URIs 
are. They identify their value, most clearly and emphatically. They 
denote in exactly the same way that URIs denote. "23"^^xsd:number   
is about as good an identification of the number twenty-three as 
you are ever likely to get in any notational system since ancient 
Babylonia.


Yes, but ancient Bablyonia != World Wide Web of Structured Linked 
Data, slightly different mediums with some shared characteristics :-)


The World Wide Web is becoming a Distributed DBMS (in my eyes). 
Thus, unambiguous naming matters.


A topic for a longer discussion; but irrelevant here, since typed 
literals are as unambiguous as a name can possibly get.




Literal Subjects aren't a "show stopper" per se. (esp. for local RDF 
data). My gripe simply boils down to the nuisance factor introduced 
by data object name ambiguity in a distributed data object oriented 
realm such as the emerging Web of Linked Data.


What does ""23"^^xsd:number " mean to anyone in a global data space?


It means the number twenty-three, everywhere and for all time, 
because this meaning can be computed from the very syntactic form of 
the name. How unambiguous can something get?


Pat,

Re. RDF's triples, What is a Subject? What is an Object?.

If they are the same thing, why on earth do we use Names (with 
implications) to describe the slots in an RDF triple?


I've only once seen the RDF triple referred to as O-R-O (by @danbri) 
i.e., Object-Relation-Object.


In addition, I don't see Information and Data as being the same thing. 
Information (as I know it) is about Data + Context.  Raw Data (as I 
know it) is about: a unit of observation and deemed worthy of 
description by its observer.  You have to give Names to subject of a 
description. "23"^^xsd:number  isn't a Name.


**
I guess my own subtle mistake (re. this thread) is deeming Identifiers 
and Names to be equivalent , when they aren't :-) Of course, one can 
use an Identifier as a Name, but that doesn't make them equivalent.

**


One clear point of divergence here is that I am focused on the Web as 
Dist. DBMS that leverages 3-tuples + HTTP URIs in the S, P, and 
optionally O slot (aka. HTTP based Linked Data).


To conclude:

Name != Identifier.
We can also question the role of URI. Because the location of resource 
pointed by URI and the content of URI are orthogonal. A location is 
interpreted by a set of  locating operations, the locating result is 
only GUIDED, not CONTROLLED, by the content of URI. To realize this is 
very important!


regards

 Peng



I believe Subject == Name (an Identifier based Name) re. RDF triples 
otherwise the triple should be described as: O-R-O or O-P-O.


I beli

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Kingsley Idehen]

Dan Brickley wrote:

[snip]

This is the second time in a few hours that a thread has degenerated
into talk of accusations and insults.

I don't care who started it. Sometimes email just isn't the best way
to communicate. If people are feeling this way about an email
discussion, it might be worth the respective parties spending a few
minutes on the phone to try to smooth things over. Or not. I don't
care, really. But each of these mail messages is getting distributed
to several hundred readers. It would be good if we can find ways of
using that bandwidth to solve problems rather than get into fights.

Or maybe we should all just take a weekend break, mull things over for
a couple of days, and start fresh on monday? That's my plan anyhow...

cheers,

Dan

  

Dan,

Being civil isn't rocket science.

People can debate, even do so with passion. All doable without 
unnecessary insults.


Ghana has certainly knocked me out anyhow :-(

--

Regards,

Kingsley Idehen	  
President & CEO 
OpenLink Software 
Web: http://www.openlinksw.com

Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Ian Davis]

On Fri, Jul 2, 2010 at 8:34 PM, Jeremy Carroll  wrote:
>  On 7/2/2010 12:00 PM, Dan Brickley wrote:
>>
>> Or maybe we should all just take a weekend break, mull things over for
>> a couple of days, and start fresh on monday? That's my plan anyhow...
>
> Yeah, maybe some of us could  meet up in some sunny place and sit in an
> office, maybe at Stanford - just like last weekend!

I have to say that meeting was a lot more civilised than the current
raging debate on these lists!

>
> Jeremy
>
>

Ian

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Jeremy Carroll]

 On 7/2/2010 12:00 PM, Dan Brickley wrote:

Or maybe we should all just take a weekend break, mull things over for
a couple of days, and start fresh on monday? That's my plan anyhow...


Yeah, maybe some of us could  meet up in some sunny place and sit in an 
office, maybe at Stanford - just like last weekend!


Jeremy

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Dan Brickley]

[snip]

This is the second time in a few hours that a thread has degenerated
into talk of accusations and insults.

I don't care who started it. Sometimes email just isn't the best way
to communicate. If people are feeling this way about an email
discussion, it might be worth the respective parties spending a few
minutes on the phone to try to smooth things over. Or not. I don't
care, really. But each of these mail messages is getting distributed
to several hundred readers. It would be good if we can find ways of
using that bandwidth to solve problems rather than get into fights.

Or maybe we should all just take a weekend break, mull things over for
a couple of days, and start fresh on monday? That's my plan anyhow...

cheers,

Dan

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Kingsley Idehen]

Pat Hayes wrote:


On Jul 2, 2010, at 6:52 AM, Kingsley Idehen wrote:


Pat Hayes wrote:


On Jul 1, 2010, at 9:42 AM, Kingsley Idehen wrote:


Pat Hayes wrote:


On Jun 30, 2010, at 3:49 PM, Kingsley Idehen wrote:


Pat Hayes wrote:


On Jun 30, 2010, at 1:30 PM, Kingsley Idehen wrote:


Nathan wrote:

Pat Hayes wrote:

On Jun 30, 2010, at 6:45 AM, Toby Inkster wrote:

On Wed, 30 Jun 2010 10:54:20 +0100
Dan Brickley  wrote:
That said, i'm sure sameAs and differentIndividual (or 
however it is
called) claims could probably make a mess, if added or 
removed...


You can create some pretty awesome messes even without OWL:

# An rdf:List that loops around...

<#mylist> a rdf:List ;
rdf:first <#Alice> ;
rdf:next <#mylist> .

# A looping, branching mess...

<#anotherlist> a rdf:List ;
rdf:first <#anotherlist> ;
rdf:next <#anotherlist> .



They might be messy, but they are *possible* structures using 
pointers, which is what the RDF vocabulary describes.  Its 
just about impossible to guarantee that messes can't happen 
when all you are doing is describing structures in an 
open-world setting. But I think the cure is to stop thinking 
that possible-messes are a problem to be solved. So, there is 
dung in the road. Walk round it.




Could we also apply that to the 'subjects as literals' general 
discussion that's going on then?


For example I've heard people saying that it encourages bad 
'linked data' practise by using examples like { 'London' a 
x:Place } - whereas I'd immediately counter with { x:London a 
'Place' }.


Surely all of the subjects as literals arguments can be 
countered with 'walk round it', and further good practise 
could be aided by a few simple notes on best practise for 
linked data etc.


IMHO an emphatic NO.

RDF is about constructing structured descriptions where 
"Subjects" have Identifiers in the form of Name References 
(which may or many resolve to Structured Representations of 
Referents carried or borne by Descriptor Docs/Resources). An 
"Identifier" != Literal.


What ARE you talking about? You sound like someone reciting 
doctrine.


Literals in RDF are just as much 'identifiers' or 'names' as 
URIs are. They identify their value, most clearly and 
emphatically. They denote in exactly the same way that URIs 
denote. "23"^^xsd:number   is about as good an identification of 
the number twenty-three as you are ever likely to get in any 
notational system since ancient Babylonia.


Yes, but ancient Bablyonia != World Wide Web of Structured Linked 
Data, slightly different mediums with some shared characteristics 
:-)


The World Wide Web is becoming a Distributed DBMS (in my eyes). 
Thus, unambiguous naming matters.


A topic for a longer discussion; but irrelevant here, since typed 
literals are as unambiguous as a name can possibly get.




Literal Subjects aren't a "show stopper" per se. (esp. for local 
RDF data). My gripe simply boils down to the nuisance factor 
introduced by data object name ambiguity in a distributed data 
object oriented realm such as the emerging Web of Linked Data.


What does ""23"^^xsd:number " mean to anyone in a global data space?


It means the number twenty-three, everywhere and for all time, 
because this meaning can be computed from the very syntactic form 
of the name. How unambiguous can something get?


Pat,

Re. RDF's triples, What is a Subject? What is an Object?.


"subject' refers to the first element in a triple, "object" to the 
last. One might as well call them 'first' and 'third'. The names
'subject' and 'object' are used purely for convenience, and have no 
formal or semantic significance.




If they are the same thing, why on earth do we use Names (with 
implications) to describe the slots in an RDF triple?


I do not understand the question here well enough to provide an 
answer. Have you actually read the RDF spec documents? The RDF 
syntax model and the semantics?


You don't understand the question enough to provide an answer, but 
you are able to compute an assessment of spec assimilation. WOW !!


The logic here is: if you had understood the specs, you wouldn't be 
asking such a damn silly question as you appear to be asking. So, I 
conclude to myself, I must be misunderstanding your question. Unless, 
of course, you havn't actually read the specs...


Pat,

Assume I've read the spec and don't understand them. Rather that 
gravitating to insults, just answer the question I asked.


If too silly or dumb for you, you do have the option to ignore.

Where I come from there are no silly or dumb questions. Instead, it  
rather silly or dumb to not ask questions when pursuing clarity.


So far so good, you have spewed subjective co

Re: Show me the money - (was Subjects as Literals)

[Sandro Hawke]

On Thu, 2010-07-01 at 17:39 +0100, Nathan wrote:
> Sandro Hawke wrote:
> > On Thu, 2010-07-01 at 17:10 +0100, Nathan wrote:
> >> In all honesty, if this doesn't happen, I personally will have no choice 
> >> but to move to N3 for the bulk of things, and hope for other 
> >> serializations of N3 to come along.
> > 
> > RIF (which became a W3C Recommendation last week) is N3, mutated (in
> > some good ways and some bad ways, I suppose) by the community consensus
> > process.   RIF is simultaneously the heir to N3 and a standard business
> > rules format.
> > 
> > RIF's central syntax is XML-based, but there's room for a presentation
> > syntax that looks like N3.   RIF includes triples which can have
> > literals as subject, of course.  (In RIF, these triples are called
> > "frames".   Well, sets of triples with a shared subject are called
> > frames, technically.But they are defined by the spec to be an
> > extension of RDF triples.)
> 
> does it cover formulae in s and o position?
> 
> i.e. can the following be expressed (without reification):
> 
> { :thermostat :temp :high } log:implies { :heating :power "0" } .

It can express such rules.  That's the main thing it does.  It does not
consider rules to be triples, however.  Making rules just be triples is
an interesting trick timbl did in the design of N3, but it causes a few
problems, and the RIF Working Group decided instead to make rules be
first-class syntactic objects instead.   (The most obvious problem is:
where do you declare the variables?  Another is: how do you attach
metadata to the rule?   Many real-world rule systems have names and
other management information associated with each rule.)

As for putting formulas in the s and o position for non-rule
applications, I would argue that is, by definition, reification.  There
is a RIF Working Draft [1] on doing that, but it's not part of the
current standard.

   -- Sandro


[1] http://www.w3.org/TR/rif-in-rdf

Re: Subjects as Literals

[Pat Hayes]

On Jul 2, 2010, at 11:06 AM, Paul Gearon wrote:


On Fri, Jul 2, 2010 at 8:34 AM, Pat Hayes  wrote:


On Jul 2, 2010, at 7:27 AM, Paul Gearon wrote:

While this may be possible, you've promoted owl:sameAs to have a  
true

semantic relationship at this level. You're treating it as if it
really does mean "equals".


Well, it does mean that, according to the OWL specs.


Of course. My point here was that it's a semantics that it being
applied at the RDF level.


Given your scenario, I'd expect:

[ owl:sameAs "foo", "bar" ]

to lead to the following being stored:

"foo" owl:sameAs "bar"

Since we only got here because owl:sameAs is being treated as having
equality semantics at the RDF level, then I *think* that this is
inconsistent.


Yes, it is.


I'll confess that I don't understand some of the
subtleties surrounding datatypes


You didn't use datatypes in that triple, so...


I misspoke (mis-typed?). I was thinking of the value space. I tend to
lump untyped literals in with the typed ones, even though I know
they're not the same. (sloppy thinking leading to sloppy language)


, so I'll let others confirm this for
me. Presuming that it *is* wrong, then this introduces the  
possibility
of inconsistent RDF, something that is currently impossible (with  
the

exception of XML literals, but that's another story)


Actually its the same story. Literals generally have *fixed*
interpretations, fixed by the semantics of the language. Whenever  
you have

this, you have the possibility of inconsistencies.


, and something we
don't want. I'm more than happy for inconsistencies to be possible  
at

a higher level (e.g. OWL-DL), but not in RDF.


Why not? Inconsistency is just another way to say entailments. If  
there are

no inconsistencies possible in RDF, then there are no significant
entailments from any RDF. So RDF is just a bunch of triples, with  
nothing

that can be done to them except look at them.


Well that's my point. Isn't that was RDF is? If not, then I withdraw
my objection.

I was under the impression that entailments could only appear when we
provide semantics to a vocabulary, such as RDFS. Without that, RDF is
just a bunch of triples that lets us build meaningless structures. We
can apply meaning to these structures through our vocabularies, but
that's our choice, and not something inherent in RDF.

Well, that's how I understand it. Now that I've said it, I'm curious
to know how close to the intended "truth" this interpretation lies.


Close, but I wouldn't say that RDF is meaningless exactly. Its  
semantics is minimal, but it does give it some meaning. Its the just- 
the-basic-facts-Ma'am part of logic: no conditionals, no quantifier  
scopes, and most importantly of all, no negation. Which is why it is  
contradiction-free.


It wouldn't take very much to make into full first-order logic: all it  
needs is a scoping mechanism (think graph literals in N3 or named  
graphs, or my 'surfaces' idea from the Blogic talk) and negation. Mind  
you, that scoping mechanism would drive a truck through triple-store- 
based implementations, I suspect. Back to tree structures and  
Sexpressions, no doubt :-)


Pat



Regards,
Paul Gearon





IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

Re: Subjects as Literals

[Paul Gearon]

On Fri, Jul 2, 2010 at 8:34 AM, Pat Hayes  wrote:
>
> On Jul 2, 2010, at 7:27 AM, Paul Gearon wrote:
>
>> While this may be possible, you've promoted owl:sameAs to have a true
>> semantic relationship at this level. You're treating it as if it
>> really does mean "equals".
>
> Well, it does mean that, according to the OWL specs.

Of course. My point here was that it's a semantics that it being
applied at the RDF level.

>> Given your scenario, I'd expect:
>>
>> [ owl:sameAs "foo", "bar" ]
>>
>> to lead to the following being stored:
>>
>> "foo" owl:sameAs "bar"
>>
>> Since we only got here because owl:sameAs is being treated as having
>> equality semantics at the RDF level, then I *think* that this is
>> inconsistent.
>
> Yes, it is.
>
>> I'll confess that I don't understand some of the
>> subtleties surrounding datatypes
>
> You didn't use datatypes in that triple, so...

I misspoke (mis-typed?). I was thinking of the value space. I tend to
lump untyped literals in with the typed ones, even though I know
they're not the same. (sloppy thinking leading to sloppy language)

>> , so I'll let others confirm this for
>> me. Presuming that it *is* wrong, then this introduces the possibility
>> of inconsistent RDF, something that is currently impossible (with the
>> exception of XML literals, but that's another story)
>
> Actually its the same story. Literals generally have *fixed*
> interpretations, fixed by the semantics of the language. Whenever you have
> this, you have the possibility of inconsistencies.
>
>> , and something we
>> don't want. I'm more than happy for inconsistencies to be possible at
>> a higher level (e.g. OWL-DL), but not in RDF.
>
> Why not? Inconsistency is just another way to say entailments. If there are
> no inconsistencies possible in RDF, then there are no significant
> entailments from any RDF. So RDF is just a bunch of triples, with nothing
> that can be done to them except look at them.

Well that's my point. Isn't that was RDF is? If not, then I withdraw
my objection.

I was under the impression that entailments could only appear when we
provide semantics to a vocabulary, such as RDFS. Without that, RDF is
just a bunch of triples that lets us build meaningless structures. We
can apply meaning to these structures through our vocabularies, but
that's our choice, and not something inherent in RDF.

Well, that's how I understand it. Now that I've said it, I'm curious
to know how close to the intended "truth" this interpretation lies.

Regards,
Paul Gearon

Re: Subjects as Literals

[Pat Hayes]

On Jul 2, 2010, at 7:27 AM, Paul Gearon wrote:


On Fri, Jul 2, 2010 at 2:16 AM, Reto Bachmann-Gmuer
 wrote:

Serialization formats could support

"Jo" :nameOf :Jo

as a shortcut for

[ owl:sameAs "Jo"; :nameOf :Jo]

and a store could (internally) store the latter as

"Jo" :nameOf :Jo

for compactness and efficiency.


While this may be possible, you've promoted owl:sameAs to have a true
semantic relationship at this level. You're treating it as if it
really does mean "equals".


Well, it does mean that, according to the OWL specs.


Given your scenario, I'd expect:

[ owl:sameAs "foo", "bar" ]

to lead to the following being stored:

"foo" owl:sameAs "bar"

Since we only got here because owl:sameAs is being treated as having
equality semantics at the RDF level, then I *think* that this is
inconsistent.


Yes, it is.


I'll confess that I don't understand some of the
subtleties surrounding datatypes


You didn't use datatypes in that triple, so...


, so I'll let others confirm this for
me. Presuming that it *is* wrong, then this introduces the possibility
of inconsistent RDF, something that is currently impossible (with the
exception of XML literals, but that's another story)


Actually its the same story. Literals generally have *fixed*  
interpretations, fixed by the semantics of the language. Whenever you  
have this, you have the possibility of inconsistencies.



, and something we
don't want. I'm more than happy for inconsistencies to be possible at
a higher level (e.g. OWL-DL), but not in RDF.


Why not? Inconsistency is just another way to say entailments. If  
there are no inconsistencies possible in RDF, then there are no  
significant entailments from any RDF. So RDF is just a bunch of  
triples, with nothing that can be done to them except look at them.


Pat




Even if I'm wrong and it's OK, I'd still feel uncomfortable building a
system that can do this.

Regards,
Paul Gearon





IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Pat Hayes]

On Jul 2, 2010, at 6:52 AM, Kingsley Idehen wrote:


Pat Hayes wrote:


On Jul 1, 2010, at 9:42 AM, Kingsley Idehen wrote:


Pat Hayes wrote:


On Jun 30, 2010, at 3:49 PM, Kingsley Idehen wrote:


Pat Hayes wrote:


On Jun 30, 2010, at 1:30 PM, Kingsley Idehen wrote:


Nathan wrote:

Pat Hayes wrote:

On Jun 30, 2010, at 6:45 AM, Toby Inkster wrote:

On Wed, 30 Jun 2010 10:54:20 +0100
Dan Brickley  wrote:
That said, i'm sure sameAs and differentIndividual (or  
however it is
called) claims could probably make a mess, if added or  
removed...


You can create some pretty awesome messes even without OWL:

# An rdf:List that loops around...

<#mylist> a rdf:List ;
rdf:first <#Alice> ;
rdf:next <#mylist> .

# A looping, branching mess...

<#anotherlist> a rdf:List ;
rdf:first <#anotherlist> ;
rdf:next <#anotherlist> .



They might be messy, but they are *possible* structures  
using pointers, which is what the RDF vocabulary describes.   
Its just about impossible to guarantee that messes can't  
happen when all you are doing is describing structures in an  
open-world setting. But I think the cure is to stop thinking  
that possible-messes are a problem to be solved. So, there  
is dung in the road. Walk round it.




Could we also apply that to the 'subjects as literals'  
general discussion that's going on then?


For example I've heard people saying that it encourages bad  
'linked data' practise by using examples like { 'London' a  
x:Place } - whereas I'd immediately counter with { x:London a  
'Place' }.


Surely all of the subjects as literals arguments can be  
countered with 'walk round it', and further good practise  
could be aided by a few simple notes on best practise for  
linked data etc.


IMHO an emphatic NO.

RDF is about constructing structured descriptions where  
"Subjects" have Identifiers in the form of Name References  
(which may or many resolve to Structured Representations of  
Referents carried or borne by Descriptor Docs/Resources). An  
"Identifier" != Literal.


What ARE you talking about? You sound like someone reciting  
doctrine.


Literals in RDF are just as much 'identifiers' or 'names' as  
URIs are. They identify their value, most clearly and  
emphatically. They denote in exactly the same way that URIs  
denote. "23"^^xsd:number   is about as good an identification  
of the number twenty-three as you are ever likely to get in any  
notational system since ancient Babylonia.


Yes, but ancient Bablyonia != World Wide Web of Structured  
Linked Data, slightly different mediums with some shared  
characteristics :-)


The World Wide Web is becoming a Distributed DBMS (in my eyes).  
Thus, unambiguous naming matters.


A topic for a longer discussion; but irrelevant here, since typed  
literals are as unambiguous as a name can possibly get.




Literal Subjects aren't a "show stopper" per se. (esp. for local  
RDF data). My gripe simply boils down to the nuisance factor  
introduced by data object name ambiguity in a distributed data  
object oriented realm such as the emerging Web of Linked Data.


What does ""23"^^xsd:number " mean to anyone in a global data  
space?


It means the number twenty-three, everywhere and for all time,  
because this meaning can be computed from the very syntactic form  
of the name. How unambiguous can something get?


Pat,

Re. RDF's triples, What is a Subject? What is an Object?.


"subject' refers to the first element in a triple, "object" to the  
last. One might as well call them 'first' and 'third'. The names
'subject' and 'object' are used purely for convenience, and have no  
formal or semantic significance.




If they are the same thing, why on earth do we use Names (with  
implications) to describe the slots in an RDF triple?


I do not understand the question here well enough to provide an  
answer. Have you actually read the RDF spec documents? The RDF  
syntax model and the semantics?


You don't understand the question enough to provide an answer, but  
you are able to compute an assessment of spec assimilation. WOW !!


The logic here is: if you had understood the specs, you wouldn't be  
asking such a damn silly question as you appear to be asking. So, I  
conclude to myself, I must be misunderstanding your question. Unless,  
of course, you havn't actually read the specs...


I've only once seen the RDF triple referred to as O-R-O (by  
@danbri) i.e., Object-Relation-Object.


IF you read the specs, however, it is abundantly clear that this is  
what an RDF triple means, viz. that a relation holds between two  
objects (I prefer "things", but).


Exactly!


? I thought you were arguing *against* this view ?

Re: Show me the money - (was Subjects as Literals)

[Nathan]

will look into ISO Common Logic to get familiar then - fwiw so long as 
it supports everything RDF Semantics supports, and allows graph 
literals, I'm easy and can change at any time :)


Pat Hayes wrote:
Well, N3 is just predicate logic done badly. If we want to move in that 
direction, I would vastly prefer extending RDF to ISO Common Logic, or 
something based on it.


Pat

On Jul 2, 2010, at 2:45 AM, Nathan wrote:


Ian Davis wrote:

On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes  wrote:
Jeremy, your argument is perfectly sound from your company's POV, 
but not
from a broader perspective. Of course, any change will incur costs 
by those
who have based their assumptions upon no change happening. Your 
company took
a risk, apparently. IMO it was a bad risk, as you could have 
implemented a
better inference engine if you had allowed literal subjects 
internally in
the first place, but whatever. But that is not an argument for there 
to be
no further change for the rest of the world and for all future time. 
Who
knows what financial opportunities might become possible when this 
change is

made, opportunities which have not even been contemplated until now?


I think Jeremy speaks for most vendors that have made an investment in
the RDF stack. In my opinion the time for this kind of low level
change was back in 2000/2001 not after ten years of investment and
deployment. Right now the focus is rightly on adoption and fiddling
with the fundamentals will scare off the early majority for another 5
years. You are right that we took a risk on a technology and made our
investment accordingly, but it was a qualified risk because many of us
also took membership of the W3C to have influence over the technology
direction.
I would prefer to see this kind of effort put into n3 as a general
logic expression system and superset of RDF that perhaps we can move
towards once we have achieved mainstream with the core data expression
in RDF. I'd like to see 5 or 6 alternative and interoperable n3
implementations in use to iron out the problems, just like we have
with RDF engines (I can name 10+ and know of no interop issues between
them)


Sounds good, doesn't break anything for anybody, and anybody who 
adopts N3 get's all the deployed RDF goodness too! - from what Pat 
says it seems RDF Semantics supports most of N3 apart from a few 
syntax bits and the notable graph literals - perhaps an idea to try 
and get graph literals in to the RDF Semantics before we hit this 
again in 2020 and wonder why the then well supported N3 doesn't have 
them :)


my how this has came full circle,

Best,

Nathan

Re: Show me the money - (was Subjects as Literals)

[Pat Hayes]

Well, N3 is just predicate logic done badly. If we want to move in  
that direction, I would vastly prefer extending RDF to ISO Common  
Logic, or something based on it.


Pat

On Jul 2, 2010, at 2:45 AM, Nathan wrote:


Ian Davis wrote:

On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes  wrote:
Jeremy, your argument is perfectly sound from your company's POV,  
but not
from a broader perspective. Of course, any change will incur costs  
by those
who have based their assumptions upon no change happening. Your  
company took
a risk, apparently. IMO it was a bad risk, as you could have  
implemented a
better inference engine if you had allowed literal subjects  
internally in
the first place, but whatever. But that is not an argument for  
there to be
no further change for the rest of the world and for all future  
time. Who
knows what financial opportunities might become possible when this  
change is

made, opportunities which have not even been contemplated until now?

I think Jeremy speaks for most vendors that have made an investment  
in

the RDF stack. In my opinion the time for this kind of low level
change was back in 2000/2001 not after ten years of investment and
deployment. Right now the focus is rightly on adoption and fiddling
with the fundamentals will scare off the early majority for another 5
years. You are right that we took a risk on a technology and made our
investment accordingly, but it was a qualified risk because many of  
us

also took membership of the W3C to have influence over the technology
direction.
I would prefer to see this kind of effort put into n3 as a general
logic expression system and superset of RDF that perhaps we can move
towards once we have achieved mainstream with the core data  
expression

in RDF. I'd like to see 5 or 6 alternative and interoperable n3
implementations in use to iron out the problems, just like we have
with RDF engines (I can name 10+ and know of no interop issues  
between

them)


Sounds good, doesn't break anything for anybody, and anybody who  
adopts N3 get's all the deployed RDF goodness too! - from what Pat  
says it seems RDF Semantics supports most of N3 apart from a few  
syntax bits and the notable graph literals - perhaps an idea to try  
and get graph literals in to the RDF Semantics before we hit this  
again in 2020 and wonder why the then well supported N3 doesn't have  
them :)


my how this has came full circle,

Best,

Nathan





IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St.   (850)202 4416   office
Pensacola(850)202 4440   fax
FL 32502  (850)291 0667   mobile
phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Nathan]

Richard Cyganiak wrote:

Hi Yves,

[trimmed cc list]

On 2 Jul 2010, at 11:15, Yves Raimond wrote:

I am not arguing for each vendor to implement that. I am arguing for
removing this arbitrary limitation from the RDF spec. Also marked as
an issue since 2000:
http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects


The demand that W3C modify the specs to allow literals as subjects 
should be rejected on a simple principle: Those who demand that change, 
including yourself, have failed to put their money where their mouth is. 
Where is the alternative specification that documents the syntactic and 
semantic extension? Where are the proposed "RDF/XML++" and "RDFa++" that 
support literals as subjects? Where are the patches to Jena, Sesame, 
Redland and ARC2 that support these changes?


The restriction seems to bother some people enough that they write noisy 
emails, but it apparently doesn't bother them enough to actually do 
anything about it.


W3C's job should be to broker compromises between non-interoperable 
approaches by different vendors, and to foster adoption by putting its 
stamp of approval on already widely deployed technologies developed by 
the community. You know, the kind of stuff that actually came out near 
the top of the RDF Next Steps work item poll [1]: named graphs, Turtle, 
RDF/JSON.


Someone mentioned HTML 3.2 in this thread. Let me mention the ill-fated 
XHTML 2.0. A group of markup purists who were more interested in 
polishing the arcane details of the language, rather than meeting the 
interests of the heaviest users and the vendors. They did an enormous 
disservice to W3C and the web. The users and vendors turned their back 
on W3C, started their own effort, and W3C ultimately had to abandon 
XHTML 2.0 or risk to become irrelevant to the future of HTML.


Literals as subjects feels very much like an XHTML 2.0 kind of feature 
to me.


Or, coming at it from a completely different direction: I have yet to 
meet a person (except Nathan perhaps) who says, "Yeah that RDF stuff, I 
had a look at it but then saw that it does not support literals as 
subjects, so I gave up on it."


To clarify - I certainly am not giving up on RDF, and RDF (with the 
exception of Graph Literals) *does* support everything I need (including 
literals as subjects) - however I am having to give up on restricting 
myself to only using the constrained subset of RDF provided by the 
common serializations.


I've found, that in order to be productive and actually make real 
applications running over a read/write web of linked data I'll need the 
most of the full RDF model & those graph literals - in other words N3 
provides everything I need [*] to be able to leave the issues behind and 
just get on being productive (and hopefully a little bit innovative).


I can, and will still publish and consume the common serializations of 
RDF we all use, but to use the data functionally in an application I 
need N3 too.


* tooling is poor of course so far.. but Toby has already stated he's 
wanting to implement in Perl, Yves has already started years ago, TimBL, 
DanC obviously with CWM, others I'm sure, and I'm certainly going to 
address an implementation for ECMAScript-262 (as are some MIT'ers) on 
client and server and quite possibly port to PHP for ARC2 (although 
that's sometime off and isn't a promise), many others have expressed the 
same sentiments over the last day or two alone - so tooling won't be an 
issue for too long, just as it isn't now for the other RDF 
serializations but was years ago.


Hope that clarifies :)

ps: fwiw, I'm with Ian, Toby, Henry and many others on this - leave the 
existing serializations alone, they are only a subset but they do the 
job quite well and let us publish and consume linked data - so it's all 
cool - changing the serializations and stack that's out there is an 
(imho) ridiculously bad idea that will benefit nobody, and it needs 
dropped from all these conversations - the original thread was from me, 
to clarify if subjects as literals were supported by the RDF Semantics, 
and they are, as if virtually anything in any position so it's a non 
issue, and certainly wasn't the issue everybodies hooked up on about 
changing rdf/xml and the likes.


Best,

Nathan

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Kingsley Idehen]

Henry Story wrote:

On 2 Jul 2010, at 15:22, Kingsley Idehen wrote:

  

I think, the main confusion comes from the use of the term "object" for two
entirely different things: In the case of "O-R-O", it refers to (semantic)
individuals. In the case of "S-P-O", it refers to a position in a
(syntactic) RDF triple.
 
  

Conflation Conflation. It makes RDF a real PITA, unfortunately.


EAV model is crystal clear:

Entity-Attribute-Value.

Slap on HTTP names for Entity, Attribute, and Value, optionally,  and you get 
an HTTP based World Wide Web of Structured Linked Data.


This is why conflating RDF and Linked Data has nothing but downside IMHO.



It all depends to whom one is speaking Kingsley. To me EAV does not say much. 
To OO programmers
attribute values often gets them thinking somewhere along the right lines. 
  


"Value" is clearer than "Object".

A Value can be a Reference or a Literal.

A Reference can be a Name or an Address.

RDF (which I use extensively) is a problem when it comes to value 
proposition articulation. Its way too prone to the kind of thread that's 
making me miss Brazil vs. Netherlands (right now).


Anyway, I  am talking about the most basic foundation for Linked Data. 
It doens't need RDF overhang.


Simple story:

An HTTP Name for the things you deem worthy of describing and then 
sharing with others via a network (e.g. World Wide Web).
Application of said Names to Description Subject, its Attributes, and 
Attribute Values.


Do that and we can Link and Lookup stuff across an HTTP network, really 
simple!

I think it may be best to think in terms of arrows between things, as shown 
below. I think
since the 60ies everyone at the age of 5 starts learning about mappings between 
objects, these
mappings are arrows, and are very easy to understand.


  









All of these are ok with me. I also like RDF, it means many things, and
most of all Reality Distortion Field. Because as you know, our view of
reality is very distorted (just think of how people 2000 years ago saw the 
world),
and so to get to understand things better we need to enter what will seem 
a reality distortion field from our very limited point of view.
  


BTW -- Richard packs a goatee these days. Need a temporal dimension for 
richer representation LOL!



Kingsley


Henry




  



--

Regards,

Kingsley Idehen	  
President & CEO 
OpenLink Software 
Web: http://www.openlinksw.com

Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Kingsley Idehen]

Michael Schneider wrote:

Kingsley Idehen wrote:

  

So why: Subject-Predicate-Object  (SPO) everywhere re. RDF?

O-R-O reflects what you've just described.

Like many of the RDF oddities (playing out nicely in this thread), you
have an O-R-O but everyone talks about S-P-O.

"Subject" has implicit meaning, it lends itself to describing stuff.  If
I recall, RDF stands for: Resource Description Framework.

I guess "Description" also means nothing?



"S-P-O" typically refers to a syntactic aspect of RDF triples, while "O-R-O"
refers to a semantic aspect.

"S-P-O": "S" ("subject") stands for the first node in an RDF triple. "P"
("predicate") for the second node. "O" ("object") for the third node. The
nodes and the triples are entities of the RDF Abstract Syntax. They don't
have any semantic meaning on their own.

"O-R-O": In the RDF semantics, a syntactic RDF triple is interpreted as a
relationship that holds between two individuals. The two "O"s refer the two
individuals (or resources, or objects), being taken from the domain of
discourse (the "world", about which assertions are made). The "R" stands for
the property (or relation; in any case a semantic entity) that is used to
define the relationship between the two individuals. 


So, these are very different aspects that must not be confused. An "S-P-O"
syntactic RDF triple is interpreted as a "O-R-O" semantic relationship
between individuals. The "S" in "S-P-O" can be a URI, a bNode, and maybe
also a literal in the future. The "O"s in "O-R-O" stand for entities in the
"world". A semantic interpretation function can then use the "S" to denote
(to "name") the "O". But there is no a-priory connection between the two:
any "S-P-O" triple can be interpreted by any "O-R-O" relationship.

I think, the main confusion comes from the use of the term "object" for two
entirely different things: In the case of "O-R-O", it refers to (semantic)
individuals. In the case of "S-P-O", it refers to a position in a
(syntactic) RDF triple.
  


Conflation Conflation. It makes RDF a real PITA, unfortunately.


EAV model is crystal clear:

Entity-Attribute-Value.

Slap on HTTP names for Entity, Attribute, and Value, optionally,  and 
you get an HTTP based World Wide Web of Structured Linked Data.



This is why conflating RDF and Linked Data has nothing but downside IMHO.


Kingsley

Michael

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schnei...@fzi.de
WWW  : http://www.fzi.de/michael.schneider
===
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
===


  



--

Regards,

Kingsley Idehen	  
President & CEO 
OpenLink Software 
Web: http://www.openlinksw.com

Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 

Re: Show me the money - (was Subjects as Literals)

[Kingsley Idehen]

Patrick Durusau wrote:

Henry,

Another reason why the SW is failing:

You don't see it as a need because you don't think of the options you 
are missing. Like people in 1800 did not think horses were slow, 
because they did not consider that they could fly. Or if they did 
think of that it was just as a dream.


Or closer to home, in the 80ies most people did not miss getting 
information quickly, the library was around the corner. Or they did 
not miss buying their tickets online.


You need a bit of imagination to see what you are missing. Which is 
why a lot of people stop dreaming.

It's painful.
   


I would reply with equally ad hominem remarks but it isn't worth the 
effort.

Patrick,

There is no Semantic Web.
There will be no Semantic Web.
There was/is a Semantic Web Project.
Key output from the Semantic Web Project is the burgeoning Web of Linked 
Data.


The Web of Linked Data enhances what can be done with the Web.

We just need to get RDF out of the way re. distractions!

Linking Data across Data Spaces offers unique value that's bubbling up 
the value chain, exponentially.


As I once said. Obama is going to be remembered for Linked Open Data 
rather than healthcare.


Just stay tuned!


Kingsley


Patrick

On 7/2/2010 7:03 AM, Henry Story wrote:

On 2 Jul 2010, at 12:49, Patrick Durusau wrote:

  

Henry,

On 7/2/2010 6:03 AM, Henry Story wrote:


On 2 Jul 2010, at 11:57, Patrick Durusau wrote:


  

On 7/2/2010 5:27 AM, Ian Davis wrote:


On Fri, Jul 2, 2010 at 10:19 AM, Patrick 
Durusauwrote:




  
I make this point in another post this morning but is your 
argument that

investment by vendors =



 
I think I just answered it there, before reading this message. 
Let me

know if not!



   
I think you made a very good point about needing examples so user 
can say: "I want to do that."


Which was one of the strong points of HTML.

 
Ok, what users will want is the Social Web. And here is the way to 
convince people:

"The Social Network Privacy Mess: Why we Need the Social Web"

http://www.youtube.com/watch?v=994DvSJZyww&feature=channel


( This can of course be improved) The general ideas should be clear:

  dystopia: we cannot have all social data centralised on one server.
  utopia: there is a lot of money to be made in creating the social 
web, and thereby

 increasing democracy in the world.

  This can ONLY be done with linked data. And there is a real need 
for it.



   

Several presumptions:

1) "there is a lot of money to be made creating the social web" - ? 
On what economic model? Advertising? Can't simply presume that money 
can be made.
 
Look I could leave that to you as an exercise to the reader. I don't 
know why people want me
to give them answers also on how to make money. Sometimes you have to 
think for yourself.


Just think how much bigger a global social web is. Then think 
everyone connecting to everyone.
Then think that perhaps you could sell software to firms that have 
certain needs, to doctors and hostpitals that have other needs, to 
universities, etc. etc...


It's up to your imagination really.

  
2) "thereby increasing democracy in the world" - ??? Not real sure 
what that has to do with social networks. However popular 
"increasing democracy" may be as a slogan, it is like "fighting 
terrorism."
 
Because people can publish their own data, and control what they say 
and to whome they say it a lot more.


  
Different governments and populations have different definitions for 
both. I have my own preferences but realize there are different 
definitions used by others.
 

I don't care what dictators think about democracy frankly.


  
3) "can ONLY be done with linked data." Really? Seems like the phone 
companies from your example did it long before linked data.
 


Phone companies do something very simple: connect phones. The 
internet connects computers. The web connects pages. You need the 
semantic web to connect things (and hence people)



  
4) "there is a real need for it." ? I get as annoyed as anyone with 
the multiple logins and universities do have some common logins for 
their internal systems but I am not sure I would describe it as a need.
 
You don't see it as a need because you don't think of the options you 
are missing. Like people in 1800 did not think horses were slow, 
because they did not consider that they could fly. Or if they did 
think of that it was just as a dream.


Or closer to home, in the 80ies most people did not miss getting 
information quickly, the library was around the corner. Or they did 
not miss buying their tickets online.


You need a bit of imagination to see what you are missing. Which is 
why a lot of people stop dreaming.

It's painful.

  
At least until some survey shows that a large number of users are 
willing to pay for such a service.
 
I have never heard of an inventor making surveys to test things out. 
Th

Re: Show me the money - (was Subjects as Literals)

[Paul Gearon]

On Fri, Jul 2, 2010 at 2:01 AM, Benjamin Nowack  wrote:
>
> On 01.07.2010 22:44:48, Pat Hayes wrote:
>>Jeremy, your argument is perfectly sound from your company's POV, but
>>not from a broader perspective. Of course, any change will incur costs
>
> Well, I think the "broader perspective" that the RDF workshop
> failed to consider is exactly companies' costs and spec
> marketability. The message still sent out is a crazy (or
> "visionary" ;) research community creating spec after spec, with
> no stability in sight.

Not being a recipient of the message, I'm not in an appropriate
position to judge there. However, I *can* say that the workshop did
indeed consider companies' costs and spec marketability. There were
numerous proposals that had some interest, but were ultimately
ignored, with cost being the single biggest reason.

> And with the W3C process not really
> encouraging the quick or full refactoring of existing specs (like
> getting rid of once recommended features), each spec adds *new*
> features

A lot of the discussion at the workshop was about *removing* features.
A number of things have revealed themselves as a bad idea, and the
community in general wants to be rid of them. However, no one wants to
break existing systems, so a notion of "weakly deprecating" these
features was introduced instead.

Similarly, for new features there was a lot of discussion about how
these could be introduced without breaking anything. In a number of
cases, proposals were abandoned simply because it would impact
existing systems too much.

Where new features did receive support, it was due to widespread
deployment despite there being no standard. Turtle and names graphs
are the obvious ones here.

The message that came out may have been quite different to this, but I
think that the majority of the workshop was extremely conservative.
Indeed, there were representatives from several companies and open
source implementors who were there specifically to make sure that
nothing too radical would receive serious attention.

> and increases the overall complexity of identifying
> market-ready Recs: RIF seems to be a replacement for OWL, but
> OWL2 was only just Rec'd. Which should I implement? RDFa 1.1 and
> SPARQL 1.1 both look like implementation nightmares to me. Current
> RDF stores can't even be used for semantic feed readers because of
> poor "ORDER BY DESC(?date)" implementations, but the group is
> already working on query federation. RDFa is becoming the new
> RSS 1.0, with each publisher triggering the development of
> dedicated parsers (one for SearchMonkey data, one for RichSnippets,
> one for Facebook's OGP, etc., but a single interoperable one? Very
> hard work.) Something is wrong here. Featuritis is the reason for
> the tiny number of complete toolkits. It's extremely frustrating
> when you know in advance that you won't be able to pass the tests
> *and* have your own (e.g. performance) needs covered. Why start at
> all then?
>
> The W3C groups still seem to believe that syntactic sugar is
> harmless. We suffer from spec obesity, badly. If we really want to
> improve RDF, then we should go, well, for a low-carb layer cake.
> Or better, several new ones. One for each target audience. KR pros
> probably need OWL 2.0 *and* RIF, others may already be amazed by
> "scoped key-value storage with a universal API" (aka triples + SPARQL).
> These groups are equally important, but have to be addressed
> differently.

I think that part of the problem is the spec process itself. For
instance, RDF 1.0 has too many features that we don't want (eg.
reification), but how does something like that get removed? RDF 1.0
can't be modified at this point. All we can do is write something new
that builds on previous versions. This is why features can only be
"deprecated" rather than removed. So even if RDF 1.1 doesn't introduce
any new features at all, and only removes things (through deprecation)
it still adds to the document bloat.

If the process allowed documents to be culled and reworked, then I
think they would be.

> Our problem is not lack of features (native literal subjects? c'mon!).

You'll note that the group specifically said that this wasn't worth working on.

(Incidentally, that's not a yes or a no. The group couldn't make those
decisions. This process was simply about identifying if there is
enough interest in updating RDF, and what should be worked on if it
is).

> It is identifying the individual user stories in our broad community
> and marketing respective solution bundles. The RDFa and LOD folks
> have demonstrated that this is possible. Similar success stories are
> probably RIF for the business rules market, OWL for the DL/KR sector,
> and many more. (Mine is agile, flexi-schema website development.)
>
> RDF "Next Steps" should be all about scoped learning material and
> deployment. There were several workshop submissions (e.g. by Jeremy,
> Lee, and Richard) that mentioned this issue, but the workshop outcom

Re: Show me the money - (was Subjects as Literals)

[Kingsley Idehen]

Patrick Durusau wrote:

Henry,

On 7/2/2010 6:03 AM, Henry Story wrote:

On 2 Jul 2010, at 11:57, Patrick Durusau wrote:

  

On 7/2/2010 5:27 AM, Ian Davis wrote:

On Fri, Jul 2, 2010 at 10:19 AM, Patrick 
Durusau   wrote:



  
I make this point in another post this morning but is your 
argument that

investment by vendors =


 

I think I just answered it there, before reading this message. Let me
know if not!


   
I think you made a very good point about needing examples so user 
can say: "I want to do that."


Which was one of the strong points of HTML.
 
Ok, what users will want is the Social Web. And here is the way to 
convince people:

"The Social Network Privacy Mess: Why we Need the Social Web"

http://www.youtube.com/watch?v=994DvSJZyww&feature=channel


( This can of course be improved) The general ideas should be clear:

  dystopia: we cannot have all social data centralised on one server.
  utopia: there is a lot of money to be made in creating the social 
web, and thereby

 increasing democracy in the world.

  This can ONLY be done with linked data. And there is a real need 
for it.


   

Several presumptions:

1) "there is a lot of money to be made creating the social web" - ? On 
what economic model? Advertising? Can't simply presume that money can 
be made.


Shallowness of Web 2.0 doesn't apply to Web 3.0.

Business is ultimately about providing tangible value packaged and 
delivered in appropriate for re. target audience.


Data by its very essence is amenable to a variety of business models 
once messaging (story telling), problem palpability, and value 
proposition articulation intersect.


2) "thereby increasing democracy in the world" - ??? Not real sure 
what that has to do with social networks. However popular "increasing 
democracy" may be as a slogan, it is like "fighting terrorism."


Simple slogan for social networking: Discover The Magic of Being You!

Value Prop: No matter how much data you may have on Facebook, Google, 
LinkedIn, and wherever else, "You" are the one who holds the key to Your 
Identity. You are the only one truly capable of creating effective 
context for those data fragments loosely associated with you.


What I describe above has a number of productization style monikers 
associated with it:


1. Personal Data Spaces -- how I see it
2. Personal Data Locker -- as Dave Siegel sees it
3. Personal Data Bank -- as Marc Davis sees it
4. Others..

What important here is that there is overwhelming evidence that the 
"Social Network Privacy" mess is problem that's reached its palpability 
point on a global scale. Thus, even though DBpedia may have bootstrapped 
the Web of Linked Data, its signature effect is going to materialize via 
fixing today's broken social networking landscape.


Different governments and populations have different definitions for 
both. I have my own preferences but realize there are different 
definitions used by others.


3) "can ONLY be done with linked data." Really? Seems like the phone 
companies from your example did it long before linked data.

Of course not.

You need a Web of Structured Linked Data.


4) "there is a real need for it." ? I get as annoyed as anyone with 
the multiple logins and universities do have some common logins for 
their internal systems but I am not sure I would describe it as a 
need. At least until some survey shows that a large number of users 
are willing to pay for such a service.


People want to be able to truly control their own privacy, which means 
control their vulnerabilities (many state transitions here), which very 
dependent on controlling their data, which ultimately requires 
verifiable identity in the form of a WebID + Data Access Policies.



Kingsley


Hope you are looking forward to a great weekend!

Patrick


Henry
   





--

Regards,

Kingsley Idehen	  
President & CEO 
OpenLink Software 
Web: http://www.openlinksw.com

Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 

RE: Subjects as Literals, [was Re: The Ordered List Ontology]

[Michael Schneider]

Kingsley Idehen wrote:

>So why: Subject-Predicate-Object  (SPO) everywhere re. RDF?
>
>O-R-O reflects what you've just described.
>
>Like many of the RDF oddities (playing out nicely in this thread), you
>have an O-R-O but everyone talks about S-P-O.
>
>"Subject" has implicit meaning, it lends itself to describing stuff.  If
>I recall, RDF stands for: Resource Description Framework.
>
>I guess "Description" also means nothing?

"S-P-O" typically refers to a syntactic aspect of RDF triples, while "O-R-O"
refers to a semantic aspect.

"S-P-O": "S" ("subject") stands for the first node in an RDF triple. "P"
("predicate") for the second node. "O" ("object") for the third node. The
nodes and the triples are entities of the RDF Abstract Syntax. They don't
have any semantic meaning on their own.

"O-R-O": In the RDF semantics, a syntactic RDF triple is interpreted as a
relationship that holds between two individuals. The two "O"s refer the two
individuals (or resources, or objects), being taken from the domain of
discourse (the "world", about which assertions are made). The "R" stands for
the property (or relation; in any case a semantic entity) that is used to
define the relationship between the two individuals. 

So, these are very different aspects that must not be confused. An "S-P-O"
syntactic RDF triple is interpreted as a "O-R-O" semantic relationship
between individuals. The "S" in "S-P-O" can be a URI, a bNode, and maybe
also a literal in the future. The "O"s in "O-R-O" stand for entities in the
"world". A semantic interpretation function can then use the "S" to denote
(to "name") the "O". But there is no a-priory connection between the two:
any "S-P-O" triple can be interpreted by any "O-R-O" relationship.

I think, the main confusion comes from the use of the term "object" for two
entirely different things: In the case of "O-R-O", it refers to (semantic)
individuals. In the case of "S-P-O", it refers to a position in a
(syntactic) RDF triple.

Michael

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schnei...@fzi.de
WWW  : http://www.fzi.de/michael.schneider
===
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
===

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Ivan Mikhailov]

On Fri, 2010-07-02 at 12:42 +0200, Richard Cyganiak wrote:
> Hi Yves,

> On 2 Jul 2010, at 11:15, Yves Raimond wrote:
> > I am not arguing for each vendor to implement that. I am arguing for
> > removing this arbitrary limitation from the RDF spec. Also marked as
> > an issue since 2000:
> > http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects
> 
> The demand that W3C modify the specs to allow literals as subjects  
> should be rejected on a simple principle: Those who demand that  
> change, including yourself, have failed to put their money where their  
> mouth is. Where is the alternative specification that documents the  
> syntactic and semantic extension? Where are the proposed "RDF/XML++"  
> and "RDFa++" that support literals as subjects? Where are the patches  
> to Jena, Sesame, Redland and ARC2 that support these changes?

+1, with a small correction. I'd expect a patch for Virtuoso as well ;)

Actually, the approval of a new spec will require two adequate
implementations. I can't imagine that existing vendors will decide to
waste their time to make their products worse in terms of speed and disk
footprint and scalability. "The most efficient critics is sabotage", you
know.

Some new vendor may of course try to become a "strikebreaker" but his
benchmark runs will look quite poorly, because others will continue to
optimize any SPARQL BGP like

?s ?p ?o .
?o ?p2 ?s2 .

into more selective

?s ?p ?o . FILTER (isREFERENCE (?o)) .
?o ?p2 ?s2 .

and this sort of rewriting will easily bring them two orders of
magnitude of speed on a simple query with less than 10 triple patterns.
Keeping in mind that Bio2RDF people tend to write queries with 20-30
triple patterns mostly connected into long chains, the speed difference
on real life queries will be a blocking issue.

-

The discussion is quite long; I'm sorry I can't continue to track it
accurately, I'm on a critical path of a new Virtuoso release.

If somebody is interested in
a whole list of reasons why I will not put this feature into the DB core
or
a whole list of workarounds for it at DB application level
or
a detailed history of round Earth and Columbus
then
ping me and I'll write a page at ESW wiki.

Best Regards,

Ivan Mikhailov
OpenLink Virtuoso
http://virtuoso.openlinksw.com

Re: Show me the money - (was Subjects as Literals)

[Nathan]

Patrick Durusau wrote:

Henry,

On 7/2/2010 6:03 AM, Henry Story wrote:
On 2 Jul 2010, at 11:57, Patrick Durusau wrote:  
On 7/2/2010 5:27 AM, Ian Davis wrote:
On Fri, Jul 2, 2010 at 10:19 AM, Patrick 
Durusau   wrote:   
I make this point in another post this morning but is your argument 
that

investment by vendors =
 

I think I just answered it there, before reading this message. Let me
know if not!
   
I think you made a very good point about needing examples so user can 
say: "I want to do that."


Which was one of the strong points of HTML.
 
Ok, what users will want is the Social Web. And here is the way to 
convince people:

"The Social Network Privacy Mess: Why we Need the Social Web"

http://www.youtube.com/watch?v=994DvSJZyww&feature=channel


( This can of course be improved) The general ideas should be clear:

  dystopia: we cannot have all social data centralised on one server.
  utopia: there is a lot of money to be made in creating the social 
web, and thereby

 increasing democracy in the world.

  This can ONLY be done with linked data. And there is a real need for 
it.


   

Several presumptions:

1) "there is a lot of money to be made creating the social web" - ? On 
what economic model? Advertising? Can't simply presume that money can be 
made.


If I may :) I'd recommend having a read of the CloudStorage design issue 
[1] - this puts forward not just a way to make money, but describes an 
entirely new model/marketplace that opens doors for everybody to make 
money, save money, become more efficient and have a waiting community 
potentially the size of the web - regardless of whether they work in 
their bedroom or are a multinational enterprise. For some inspiration 
you need look no further than payswarm [2], the open market place or 
almost anything good relations related. The 'social web' (powered by 
linked data) is very much the enabler in all of this, which brings the 
overall web right back to what it was designed to be, a social 
collaborative space for the world to benefit from.


[1] http://www.w3.org/DesignIssues/CloudStorage.html
[2] http://payswarm.com/

I'll hope that a read over the aforementioned cloud storage di will help 
you align visions with henry on this a bit :)


Also, if I may - some of the meetings with Manu et al for payswarm are 
very good listening http://payswarm.com/community/meetings/


Best!

2) "thereby increasing democracy in the world" - ??? Not real sure what 
that has to do with social networks. However popular "increasing 
democracy" may be as a slogan, it is like "fighting terrorism."


Different governments and populations have different definitions for 
both. I have my own preferences but realize there are different 
definitions used by others.


3) "can ONLY be done with linked data." Really? Seems like the phone 
companies from your example did it long before linked data.


4) "there is a real need for it." ? I get as annoyed as anyone with the 
multiple logins and universities do have some common logins for their 
internal systems but I am not sure I would describe it as a need. At 
least until some survey shows that a large number of users are willing 
to pay for such a service.


Hope you are looking forward to a great weekend!

Patrick


Henry
   

Re: Subjects as Literals

[Paul Gearon]

On Fri, Jul 2, 2010 at 2:16 AM, Reto Bachmann-Gmuer
 wrote:
> Serialization formats could support
>
> "Jo" :nameOf :Jo
>
> as a shortcut for
>
> [ owl:sameAs "Jo"; :nameOf :Jo]
>
> and a store could (internally) store the latter as
>
> "Jo" :nameOf :Jo
>
> for compactness and efficiency.

While this may be possible, you've promoted owl:sameAs to have a true
semantic relationship at this level. You're treating it as if it
really does mean "equals". Given your scenario, I'd expect:

[ owl:sameAs "foo", "bar" ]

to lead to the following being stored:

"foo" owl:sameAs "bar"

Since we only got here because owl:sameAs is being treated as having
equality semantics at the RDF level, then I *think* that this is
inconsistent. I'll confess that I don't understand some of the
subtleties surrounding datatypes, so I'll let others confirm this for
me. Presuming that it *is* wrong, then this introduces the possibility
of inconsistent RDF, something that is currently impossible (with the
exception of XML literals, but that's another story), and something we
don't want. I'm more than happy for inconsistencies to be possible at
a higher level (e.g. OWL-DL), but not in RDF.

Even if I'm wrong and it's OK, I'd still feel uncomfortable building a
system that can do this.

Regards,
Paul Gearon

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Yves Raimond]

Hi Richard!

>
> [trimmed cc list]
>
> On 2 Jul 2010, at 11:15, Yves Raimond wrote:
>>
>> I am not arguing for each vendor to implement that. I am arguing for
>> removing this arbitrary limitation from the RDF spec. Also marked as
>> an issue since 2000:
>> http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects
>
> The demand that W3C modify the specs to allow literals as subjects should be
> rejected on a simple principle: Those who demand that change, including
> yourself, have failed to put their money where their mouth is. Where is the
> alternative specification that documents the syntactic and semantic
> extension? Where are the proposed "RDF/XML++" and "RDFa++" that support
> literals as subjects? Where are the patches to Jena, Sesame, Redland and
> ARC2 that support these changes?

This is a really unfair comment, Richard, and I am sure you realise
that. We are arguing for a very small modification of
http://www.w3.org/TR/rdf-concepts/#section-Literals - not of any
serialisation at the moment. Some of them happen to already support
that (the RDF subset of N3). The serialisation work is outside of the
scope of this discussion (but should happen, I agree) - let's stick to
small, iterative, improvements and bug fixes.

>
> The restriction seems to bother some people enough that they write noisy
> emails, but it apparently doesn't bother them enough to actually do anything
> about it.
>

Same thing - very unfair. We are being very specific about the change
we want made. Some of us implemented patches and libraries supporting
that (I wrote a swi-prolog one, Toby mentioned a Perl one, CWM
supports it since ages, as well as all other N3 engines). So, please,
if you want to criticise our proposal, do it on a sound basis, instead
of just trying to get as many people as you can very frustrated at the
way such decisions are being made.

Also, putting forward the "us vs. them" argument is not really the
best way to move forward, as I am sure you would agree. We suffered
from that in the LOD community a lot (and as Dan points out, still
suffer from that a lot in the whole Semantic Web community), so please
stop sending such emails anytime you feel in opposition with a
proposal, and let's have a fruitful debate.

> W3C's job should be to broker compromises between non-interoperable
> approaches by different vendors, and to foster adoption by putting its stamp
> of approval on already widely deployed technologies developed by the
> community. You know, the kind of stuff that actually came out near the top
> of the RDF Next Steps work item poll [1]: named graphs, Turtle, RDF/JSON.
>

W3C's job is also to provide bug-free specs, and interoperable one.
The fact that you can CONSTRUCT an invalid RDF document in SPARQL,
whilst still being valid SPARQL, is bad IMHO.

> Someone mentioned HTML 3.2 in this thread. Let me mention the ill-fated
> XHTML 2.0. A group of markup purists who were more interested in polishing
> the arcane details of the language, rather than meeting the interests of the
> heaviest users and the vendors. They did an enormous disservice to W3C and
> the web. The users and vendors turned their back on W3C, started their own
> effort, and W3C ultimately had to abandon XHTML 2.0 or risk to become
> irrelevant to the future of HTML.
>
> Literals as subjects feels very much like an XHTML 2.0 kind of feature to
> me.
>
> Or, coming at it from a completely different direction: I have yet to meet a
> person (except Nathan perhaps) who says, "Yeah that RDF stuff, I had a look
> at it but then saw that it does not support literals as subjects, so I gave
> up on it."

The same reasoning can be applied to all the things in the current
item poll: Turtle not existing didn't stop people publishing RDF/XML.
Named Graphs not being spec'ed out didn't stop them either. So I would
also argue this is a buggy argument, mostly there for drawing more FUD
on a thread that, I think, doesn't need more.

Best,
y

>
> Best,
> Richard
>
> [1] http://www.w3.org/2010/06/rdf-work-items/table
>
>
>>
>> That aside, I don't see your point about extra hardware. There is, in
>> my experience, no substantial difference between storing
>>
>> <#me> foaf:name "Ivan" and "Ivan" :name_of <#me>.
>>
>>> _not_enough_unique_ to interlink data.
>>
>> There are. Their value is their identity. They are *perfectly* unique.
>> "cat" is uniquely identifying the string made of c, a and t. From your
>> previous email, I suppose you're concerned about rounding for floats
>> and doubles, is that it? If so, whatever you write as their rounded
>> value is their identity (and we can't write "Pi"^^xsd:real afaik :) ).
>>
>>>
>>> [ ] str:double_metaphone_word "Acton" ; str:double_metaphone "AKTN" .
>>> and
>>> [ ] str:soundex_word "Smith" ; str:soundex "S530" .
>>>
>>
>> I agree this is another way to model it, and Jeremy suggested it as
>> well. But it creates a level of indirection and, from a modeling point
>> of view, does look very weird. If you we

Re: Show me the money - (was Subjects as Literals)

[Henry Story]

On 2 Jul 2010, at 13:20, Patrick Durusau wrote:

> Henry,
> 
> Another reason why the SW is failing:

It is not failing, it is growing from strength to strength.

> 
>> You don't see it as a need because you don't think of the options you are 
>> missing. Like people in 1800 did not think horses were slow, because they 
>> did not consider that they could fly. Or if they did think of that it was 
>> just as a dream.
>> 
>> Or closer to home, in the 80ies most people did not miss getting information 
>> quickly, the library was around the corner. Or they did not miss buying 
>> their tickets online.
>> 
>> You need a bit of imagination to see what you are missing. Which is why a 
>> lot of people stop dreaming.
>> It's painful.
>>   
> 
> I would reply with equally ad hominem remarks but it isn't worth the effort.

What definition of ad hominem are you using. From Wikipedia:

[[
Ad hominem abusive usually involves insulting or belittling one's opponent, but 
can also involve pointing out factual but ostensible character flaws or actions 
which are irrelevant to the opponent's argument. This tactic is logically 
fallacious because insults and even true negative facts about the opponent's 
personal character have nothing to do with the logical merits of the opponent's 
arguments or assertions.
]]

I did not insult you. 

First: you did not present an argument. You just said:

>>> I get as annoyed as anyone with the multiple logins and universities do 
>>> have some common logins for their internal systems but I am not sure I 
>>> would describe it as a need. At least until some survey shows that a large 
>>> number of users are willing to pay for such a service.


So you are basing your argument on what the majority of people think. You won't 
consider something an issue until the majority of people consider it an issue, 
and not even then: until it is proven statistically that the majority of people 
think it is an issue! 

And so my argument is an reasonable answer to that: the people won't see what 
is a problem until after the problem has been solved. And I gave historical and 
recent examples to back up my case,

So again what is your argument that it is not needed, other than waiting for 
people to tell you that it is? I give an argument in the video that to enable 
the Social Web it is needed.  See the last few minuttes.

 http://www.youtube.com/watch?v=994DvSJZyww&feature=channel



Henry


> 
> Patrick
> 
> On 7/2/2010 7:03 AM, Henry Story wrote:
>> On 2 Jul 2010, at 12:49, Patrick Durusau wrote:
>> 
>>   
>>> Henry,
>>> 
>>> On 7/2/2010 6:03 AM, Henry Story wrote:
>>> 
 On 2 Jul 2010, at 11:57, Patrick Durusau wrote:
 
 
   
> On 7/2/2010 5:27 AM, Ian Davis wrote:
> 
> 
>> On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusau
>> wrote:
>> 
>> 
>> 
>>   
>>> I make this point in another post this morning but is your argument that
>>> investment by vendors =
>>> 
>>> 
>>> 
>>> 
>> I think I just answered it there, before reading this message. Let me
>> know if not!
>> 
>> 
>> 
>>   
> I think you made a very good point about needing examples so user can 
> say: "I want to do that."
> 
> Which was one of the strong points of HTML.
> 
> 
 Ok, what users will want is the Social Web. And here is the way to 
 convince people:
 "The Social Network Privacy Mess: Why we Need the Social Web"
 
http://www.youtube.com/watch?v=994DvSJZyww&feature=channel
 
 
 ( This can of course be improved) The general ideas should be clear:
 
  dystopia: we cannot have all social data centralised on one server.
  utopia: there is a lot of money to be made in creating the social web, 
 and thereby
 increasing democracy in the world.
 
  This can ONLY be done with linked data. And there is a real need for it.
 
 
   
>>> Several presumptions:
>>> 
>>> 1) "there is a lot of money to be made creating the social web" - ? On what 
>>> economic model? Advertising? Can't simply presume that money can be made.
>>> 
>> Look I could leave that to you as an exercise to the reader. I don't know 
>> why people want me
>> to give them answers also on how to make money. Sometimes you have to think 
>> for yourself.
>> 
>> Just think how much bigger a global social web is. Then think everyone 
>> connecting to everyone.
>> Then think that perhaps you could sell software to firms that have certain 
>> needs, to doctors and hostpitals that have other needs, to universities, 
>> etc. etc...
>> 
>> It's up to your imagination really.
>> 
>>   
>>> 2) "thereby increasing democracy in the world" - ??? Not real sure what 
>>> that has to do with social networks. However popular "increasing democracy" 
>>> may be as a slogan, it is like "fighting terrorism."
>>> 
>> Because people can pub

Re: Show me the money - (was Subjects as Literals)

[Benjamin Nowack]

On 02.07.2010 12:53:11, Richard Cyganiak wrote:
>But telling those user stories and marketing the solution bundles is
>not something that can realistically be done via the medium of *specs*.
Yes, full agreement here. That's why the thread felt so weird to me,
I think the entire focus is wrong. But I'm starting to realize that
this is apparently the wrong forum to state this ;) (It was the last
W3C list I was still subscribed, too, though. Time to stop whining and
move on, I guess).

>In all fairness, the workshop was specifically about figuring out what
>changes and additions to the RDF core specifications make sense, and
>it was limited by a tight schedule. Better learning material and
>similar work items were not in scope.
I see now, thx, I just re-read the workshop page. Should have known
better that this stuff is still not considered important enough to
put it on an agenda..

>W3C is running a number of XGs and IGs, which are in a position to
>produce marketing and teaching materials. Do you have proposals for
>concrete things that the existing groups should tackle?
If the XGs can't figure that out on their own, we're pretty lost.
What about interactive tools that answer "find the specs relevant to
me", "who is using this?", "what tools exist for this?", "what are
the dependencies?", "examples?", "what should I read next?". We'd
need an annotation tool for the individual specs and spec sections.
But then we'd have to use our own boring technology for what we say
it's made for. Nah.., just had this cool idea of sub-queries in
property paths, gotta work on that first.

;)
Benji


>
>Best,
>Richard
>
>
>
>>
>> Benji
>>
>> --
>> Benjamin Nowack
>> http://bnode.org/
>> http://semsol.com/
>>
>>
>
>

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Kingsley Idehen]

Pat Hayes wrote:


On Jul 1, 2010, at 9:42 AM, Kingsley Idehen wrote:


Pat Hayes wrote:


On Jun 30, 2010, at 3:49 PM, Kingsley Idehen wrote:


Pat Hayes wrote:


On Jun 30, 2010, at 1:30 PM, Kingsley Idehen wrote:


Nathan wrote:

Pat Hayes wrote:

On Jun 30, 2010, at 6:45 AM, Toby Inkster wrote:

On Wed, 30 Jun 2010 10:54:20 +0100
Dan Brickley  wrote:
That said, i'm sure sameAs and differentIndividual (or 
however it is
called) claims could probably make a mess, if added or 
removed...


You can create some pretty awesome messes even without OWL:

 # An rdf:List that loops around...

 <#mylist> a rdf:List ;
 rdf:first <#Alice> ;
 rdf:next <#mylist> .

 # A looping, branching mess...

 <#anotherlist> a rdf:List ;
 rdf:first <#anotherlist> ;
 rdf:next <#anotherlist> .



They might be messy, but they are *possible* structures using 
pointers, which is what the RDF vocabulary describes.  Its just 
about impossible to guarantee that messes can't happen when all 
you are doing is describing structures in an open-world 
setting. But I think the cure is to stop thinking that 
possible-messes are a problem to be solved. So, there is dung 
in the road. Walk round it.




Could we also apply that to the 'subjects as literals' general 
discussion that's going on then?


For example I've heard people saying that it encourages bad 
'linked data' practise by using examples like { 'London' a 
x:Place } - whereas I'd immediately counter with { x:London a 
'Place' }.


Surely all of the subjects as literals arguments can be 
countered with 'walk round it', and further good practise could 
be aided by a few simple notes on best practise for linked data 
etc.


IMHO an emphatic NO.

RDF is about constructing structured descriptions where 
"Subjects" have Identifiers in the form of Name References (which 
may or many resolve to Structured Representations of Referents 
carried or borne by Descriptor Docs/Resources). An "Identifier" 
!= Literal.


What ARE you talking about? You sound like someone reciting doctrine.

Literals in RDF are just as much 'identifiers' or 'names' as URIs 
are. They identify their value, most clearly and emphatically. 
They denote in exactly the same way that URIs denote. 
"23"^^xsd:number   is about as good an identification of the 
number twenty-three as you are ever likely to get in any 
notational system since ancient Babylonia.


Yes, but ancient Bablyonia != World Wide Web of Structured Linked 
Data, slightly different mediums with some shared characteristics :-)


The World Wide Web is becoming a Distributed DBMS (in my eyes). 
Thus, unambiguous naming matters.


A topic for a longer discussion; but irrelevant here, since typed 
literals are as unambiguous as a name can possibly get.




Literal Subjects aren't a "show stopper" per se. (esp. for local 
RDF data). My gripe simply boils down to the nuisance factor 
introduced by data object name ambiguity in a distributed data 
object oriented realm such as the emerging Web of Linked Data.


What does ""23"^^xsd:number " mean to anyone in a global data space?


It means the number twenty-three, everywhere and for all time, 
because this meaning can be computed from the very syntactic form of 
the name. How unambiguous can something get?


Pat,

Re. RDF's triples, What is a Subject? What is an Object?.


"subject' refers to the first element in a triple, "object" to the 
last. One might as well call them 'first' and 'third'. The names
'subject' and 'object' are used purely for convenience, and have no 
formal or semantic significance.




If they are the same thing, why on earth do we use Names (with 
implications) to describe the slots in an RDF triple?


I do not understand the question here well enough to provide an 
answer. Have you actually read the RDF spec documents? The RDF syntax 
model and the semantics?


You don't understand the question enough to provide an answer, but you 
are able to compute an assessment of spec assimilation. WOW !!




I've only once seen the RDF triple referred to as O-R-O (by @danbri) 
i.e., Object-Relation-Object.


IF you read the specs, however, it is abundantly clear that this is 
what an RDF triple means, viz. that a relation holds between two 
objects (I prefer "things", but).


Exactly!

So why: Subject-Predicate-Object  (SPO) everywhere re. RDF?

O-R-O reflects what you've just described.

Like many of the RDF oddities (playing out nicely in this thread), you 
have an O-R-O but everyone talks about S-P-O.


"Subject" has implicit meaning, it lends itself to describing stuff.  If 
I recall, RDF stands for: Resource Description Framework.


I guess "Description" also mean

Re: Show me the money - (was Subjects as Literals)

[Patrick Durusau]

Henry,

Another reason why the SW is failing:


You don't see it as a need because you don't think of the options you are 
missing. Like people in 1800 did not think horses were slow, because they did 
not consider that they could fly. Or if they did think of that it was just as a 
dream.

Or closer to home, in the 80ies most people did not miss getting information 
quickly, the library was around the corner. Or they did not miss buying their 
tickets online.

You need a bit of imagination to see what you are missing. Which is why a lot 
of people stop dreaming.
It's painful.
   


I would reply with equally ad hominem remarks but it isn't worth the effort.

Patrick

On 7/2/2010 7:03 AM, Henry Story wrote:

On 2 Jul 2010, at 12:49, Patrick Durusau wrote:

   

Henry,

On 7/2/2010 6:03 AM, Henry Story wrote:
 

On 2 Jul 2010, at 11:57, Patrick Durusau wrote:


   

On 7/2/2010 5:27 AM, Ian Davis wrote:

 

On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusauwrote:



   

I make this point in another post this morning but is your argument that
investment by vendors =



 

I think I just answered it there, before reading this message. Let me
know if not!



   

I think you made a very good point about needing examples so user can say: "I want 
to do that."

Which was one of the strong points of HTML.

 

Ok, what users will want is the Social Web. And here is the way to convince 
people:
"The Social Network Privacy Mess: Why we Need the Social Web"

http://www.youtube.com/watch?v=994DvSJZyww&feature=channel


( This can of course be improved) The general ideas should be clear:

  dystopia: we cannot have all social data centralised on one server.
  utopia: there is a lot of money to be made in creating the social web, and 
thereby
 increasing democracy in the world.

  This can ONLY be done with linked data. And there is a real need for it.


   

Several presumptions:

1) "there is a lot of money to be made creating the social web" - ? On what 
economic model? Advertising? Can't simply presume that money can be made.
 

Look I could leave that to you as an exercise to the reader. I don't know why 
people want me
to give them answers also on how to make money. Sometimes you have to think for 
yourself.

Just think how much bigger a global social web is. Then think everyone 
connecting to everyone.
Then think that perhaps you could sell software to firms that have certain 
needs, to doctors and hostpitals that have other needs, to universities, etc. 
etc...

It's up to your imagination really.

   

2) "thereby increasing democracy in the world" - ??? Not real sure what that has to do with social 
networks. However popular "increasing democracy" may be as a slogan, it is like "fighting 
terrorism."
 

Because people can publish their own data, and control what they say and to 
whome they say it a lot more.

   

Different governments and populations have different definitions for both. I 
have my own preferences but realize there are different definitions used by 
others.
 

I don't care what dictators think about democracy frankly.


   

3) "can ONLY be done with linked data." Really? Seems like the phone companies 
from your example did it long before linked data.
 


Phone companies do something very simple: connect phones. The internet connects 
computers. The web connects pages. You need the semantic web to connect things 
(and hence people)


   

4) "there is a real need for it." ? I get as annoyed as anyone with the 
multiple logins and universities do have some common logins for their internal systems 
but I am not sure I would describe it as a need.
 

You don't see it as a need because you don't think of the options you are 
missing. Like people in 1800 did not think horses were slow, because they did 
not consider that they could fly. Or if they did think of that it was just as a 
dream.

Or closer to home, in the 80ies most people did not miss getting information 
quickly, the library was around the corner. Or they did not miss buying their 
tickets online.

You need a bit of imagination to see what you are missing. Which is why a lot 
of people stop dreaming.
It's painful.

   

At least until some survey shows that a large number of users are willing to 
pay for such a service.
 

I have never heard of an inventor making surveys to test things out. That is 
nonsense. At most what that can tell you is little details, ways to fine tune a 
system. It will never let you see the big changes coming.

   

Hope you are looking forward to a great weekend!
 

you too.

   

Patrick

 

Henry

   

--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://ww

Re: Show me the money - (was Subjects as Literals)

[Henry Story]

On 2 Jul 2010, at 12:49, Patrick Durusau wrote:

> Henry,
> 
> On 7/2/2010 6:03 AM, Henry Story wrote:
>> On 2 Jul 2010, at 11:57, Patrick Durusau wrote:
>> 
>>   
>>> On 7/2/2010 5:27 AM, Ian Davis wrote:
>>> 
 On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusau   
 wrote:
 
 
   
> I make this point in another post this morning but is your argument that
> investment by vendors =
> 
> 
> 
 I think I just answered it there, before reading this message. Let me
 know if not!
 
 
   
>>> I think you made a very good point about needing examples so user can say: 
>>> "I want to do that."
>>> 
>>> Which was one of the strong points of HTML.
>>> 
>> Ok, what users will want is the Social Web. And here is the way to convince 
>> people:
>> "The Social Network Privacy Mess: Why we Need the Social Web"
>> 
>>http://www.youtube.com/watch?v=994DvSJZyww&feature=channel
>> 
>> 
>> ( This can of course be improved) The general ideas should be clear:
>> 
>>  dystopia: we cannot have all social data centralised on one server.
>>  utopia: there is a lot of money to be made in creating the social web, and 
>> thereby
>> increasing democracy in the world.
>> 
>>  This can ONLY be done with linked data. And there is a real need for it.
>> 
>>   
> Several presumptions:
> 
> 1) "there is a lot of money to be made creating the social web" - ? On what 
> economic model? Advertising? Can't simply presume that money can be made.

Look I could leave that to you as an exercise to the reader. I don't know why 
people want me
to give them answers also on how to make money. Sometimes you have to think for 
yourself.

Just think how much bigger a global social web is. Then think everyone 
connecting to everyone.
Then think that perhaps you could sell software to firms that have certain 
needs, to doctors and hostpitals that have other needs, to universities, etc. 
etc...

It's up to your imagination really.

> 
> 2) "thereby increasing democracy in the world" - ??? Not real sure what that 
> has to do with social networks. However popular "increasing democracy" may be 
> as a slogan, it is like "fighting terrorism."

Because people can publish their own data, and control what they say and to 
whome they say it a lot more.

> 
> Different governments and populations have different definitions for both. I 
> have my own preferences but realize there are different definitions used by 
> others.

I don't care what dictators think about democracy frankly.


> 3) "can ONLY be done with linked data." Really? Seems like the phone 
> companies from your example did it long before linked data.


Phone companies do something very simple: connect phones. The internet connects 
computers. The web connects pages. You need the semantic web to connect things 
(and hence people)


> 
> 4) "there is a real need for it." ? I get as annoyed as anyone with the 
> multiple logins and universities do have some common logins for their 
> internal systems but I am not sure I would describe it as a need.

You don't see it as a need because you don't think of the options you are 
missing. Like people in 1800 did not think horses were slow, because they did 
not consider that they could fly. Or if they did think of that it was just as a 
dream.

Or closer to home, in the 80ies most people did not miss getting information 
quickly, the library was around the corner. Or they did not miss buying their 
tickets online.

You need a bit of imagination to see what you are missing. Which is why a lot 
of people stop dreaming.
It's painful.

> At least until some survey shows that a large number of users are willing to 
> pay for such a service.

I have never heard of an inventor making surveys to test things out. That is 
nonsense. At most what that can tell you is little details, ways to fine tune a 
system. It will never let you see the big changes coming.

> 
> Hope you are looking forward to a great weekend!

you too.

> 
> Patrick
> 
>>  Henry
>>   
> 
> -- 
> Patrick Durusau
> patr...@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
> 
> Another Word For It (blog): http://tm.durusau.net
> Homepage: http://www.durusau.net
> Twitter: patrickDurusau
> 

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Henry Story]

On 2 Jul 2010, at 12:42, Richard Cyganiak wrote:

> Hi Yves,
> 
> [trimmed cc list]
> 
> On 2 Jul 2010, at 11:15, Yves Raimond wrote:
>> I am not arguing for each vendor to implement that. I am arguing for
>> removing this arbitrary limitation from the RDF spec. Also marked as
>> an issue since 2000:
>> http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects
> 
> The demand that W3C modify the specs to allow literals as subjects should be 
> rejected on a simple principle: Those who demand that change, including 
> yourself, have failed to put their money where their mouth is. Where is the 
> alternative specification that documents the syntactic and semantic 
> extension? Where are the proposed "RDF/XML++" and "RDFa++" that support 
> literals as subjects? Where are the patches to Jena, Sesame, Redland and ARC2 
> that support these changes?
> 
> The restriction seems to bother some people enough that they write noisy 
> emails, but it apparently doesn't bother them enough to actually do anything 
> about it.

Sorry it is implemented in Cwm, and Euler sharp, and the N3 javascript parser 
in tabulator, and we
hear about rules having them, and even them being allowed by the latest OWL 2 
spec.

Furthermore as argued it is not complicated to do allow existing systems to use 
this:

take any 

 "ted" chars 3 .

and transform to

 [] sameas "ted"
chars 3.

There is even a language for it called N3, that is what SPARQL was based on.

   So I don't see why you have to be so agressive here.

Henry

Re: Show me the money - (was Subjects as Literals)

[Richard Cyganiak]

Hi Benjamin,

On 2 Jul 2010, at 11:01, Benjamin Nowack wrote:

Our problem is not lack of features (native literal subjects? c'mon!).
It is identifying the individual user stories in our broad community
and marketing respective solution bundles. The RDFa and LOD folks
have demonstrated that this is possible. Similar success stories are
probably RIF for the business rules market, OWL for the DL/KR sector,
and many more. (Mine is agile, flexi-schema website development.)


Quite right.

But telling those user stories and marketing the solution bundles is  
not something that can realistically be done via the medium of *specs*.



RDF "Next Steps" should be all about scoped learning material and
deployment. There were several workshop submissions (e.g. by Jeremy,
Lee, and Richard) that mentioned this issue, but the workshop outcome
seems to be purely technical. Too bad.


In all fairness, the workshop was specifically about figuring out what  
changes and additions to the RDF core specifications make sense, and  
it was limited by a tight schedule. Better learning material and  
similar work items were not in scope.


W3C is running a number of XGs and IGs, which are in a position to  
produce marketing and teaching materials. Do you have proposals for  
concrete things that the existing groups should tackle?


Best,
Richard





Benji

--
Benjamin Nowack
http://bnode.org/
http://semsol.com/

Re: Show me the money - (was Subjects as Literals)

[Bob Ferris]

Hi Richard,

> Such

work can not be realistically done within W3C for obvious reasons. It
has to be done outside W3C by the community.


I believe that's what the "normal/standard" web developers (I think 
Henry Story called them "Web Monkeys" ;) ) do already, or?


Cheers,


Bob

Re: Show me the money - (was Subjects as Literals)

[Patrick Durusau]

Henry,

On 7/2/2010 6:03 AM, Henry Story wrote:

On 2 Jul 2010, at 11:57, Patrick Durusau wrote:

   

On 7/2/2010 5:27 AM, Ian Davis wrote:
 

On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusau   wrote:


   

I make this point in another post this morning but is your argument that
investment by vendors =


 

I think I just answered it there, before reading this message. Let me
know if not!


   

I think you made a very good point about needing examples so user can say: "I want 
to do that."

Which was one of the strong points of HTML.
 

Ok, what users will want is the Social Web. And here is the way to convince 
people:
"The Social Network Privacy Mess: Why we Need the Social Web"

http://www.youtube.com/watch?v=994DvSJZyww&feature=channel


( This can of course be improved) The general ideas should be clear:

  dystopia: we cannot have all social data centralised on one server.
  utopia: there is a lot of money to be made in creating the social web, and 
thereby
 increasing democracy in the world.

  This can ONLY be done with linked data. And there is a real need for it.

   

Several presumptions:

1) "there is a lot of money to be made creating the social web" - ? On 
what economic model? Advertising? Can't simply presume that money can be 
made.


2) "thereby increasing democracy in the world" - ??? Not real sure what 
that has to do with social networks. However popular "increasing 
democracy" may be as a slogan, it is like "fighting terrorism."


Different governments and populations have different definitions for 
both. I have my own preferences but realize there are different 
definitions used by others.


3) "can ONLY be done with linked data." Really? Seems like the phone 
companies from your example did it long before linked data.


4) "there is a real need for it." ? I get as annoyed as anyone with the 
multiple logins and universities do have some common logins for their 
internal systems but I am not sure I would describe it as a need. At 
least until some survey shows that a large number of users are willing 
to pay for such a service.


Hope you are looking forward to a great weekend!

Patrick


Henry
   


--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau

Re: Subjects as Literals, [was Re: The Ordered List Ontology]

[Richard Cyganiak]

Hi Yves,

[trimmed cc list]

On 2 Jul 2010, at 11:15, Yves Raimond wrote:

I am not arguing for each vendor to implement that. I am arguing for
removing this arbitrary limitation from the RDF spec. Also marked as
an issue since 2000:
http://www.w3.org/2000/03/rdf-tracking/#rdfms-literalsubjects


The demand that W3C modify the specs to allow literals as subjects  
should be rejected on a simple principle: Those who demand that  
change, including yourself, have failed to put their money where their  
mouth is. Where is the alternative specification that documents the  
syntactic and semantic extension? Where are the proposed "RDF/XML++"  
and "RDFa++" that support literals as subjects? Where are the patches  
to Jena, Sesame, Redland and ARC2 that support these changes?


The restriction seems to bother some people enough that they write  
noisy emails, but it apparently doesn't bother them enough to actually  
do anything about it.


W3C's job should be to broker compromises between non-interoperable  
approaches by different vendors, and to foster adoption by putting its  
stamp of approval on already widely deployed technologies developed by  
the community. You know, the kind of stuff that actually came out near  
the top of the RDF Next Steps work item poll [1]: named graphs,  
Turtle, RDF/JSON.


Someone mentioned HTML 3.2 in this thread. Let me mention the ill- 
fated XHTML 2.0. A group of markup purists who were more interested in  
polishing the arcane details of the language, rather than meeting the  
interests of the heaviest users and the vendors. They did an enormous  
disservice to W3C and the web. The users and vendors turned their back  
on W3C, started their own effort, and W3C ultimately had to abandon  
XHTML 2.0 or risk to become irrelevant to the future of HTML.


Literals as subjects feels very much like an XHTML 2.0 kind of feature  
to me.


Or, coming at it from a completely different direction: I have yet to  
meet a person (except Nathan perhaps) who says, "Yeah that RDF stuff,  
I had a look at it but then saw that it does not support literals as  
subjects, so I gave up on it."


Best,
Richard

[1] http://www.w3.org/2010/06/rdf-work-items/table




That aside, I don't see your point about extra hardware. There is, in
my experience, no substantial difference between storing

<#me> foaf:name "Ivan" and "Ivan" :name_of <#me>.


_not_enough_unique_ to interlink data.


There are. Their value is their identity. They are *perfectly* unique.
"cat" is uniquely identifying the string made of c, a and t. From your
previous email, I suppose you're concerned about rounding for floats
and doubles, is that it? If so, whatever you write as their rounded
value is their identity (and we can't write "Pi"^^xsd:real afaik :) ).



[ ] str:double_metaphone_word "Acton" ; str:double_metaphone "AKTN" .
and
[ ] str:soundex_word "Smith" ; str:soundex "S530" .



I agree this is another way to model it, and Jeremy suggested it as
well. But it creates a level of indirection and, from a modeling point
of view, does look very weird. If you were to extend that model to,
say, "1" list:in (1 2 3), that would look very nasty...

Best,
y

are at least protected from collisions and allow more properties to  
be added in a safe way.



Best Regards,

Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com

Re: Show me the money - (was Subjects as Literals)

[Hugh Glaser]

On 02/07/2010 05:36, "Pat Hayes"  wrote:
> In OWL-DL it is so restricted. Emphasis on the DL. So, don't use
> owl:sameAs. Use your own propietary sameAs; it needn't even be
> symmetric. We are after all taking RDF here, not OWL-DL. And in the
> case under discussion (keeping Jeremy from losing thousands of dollars
> or much restful sleep), nobody outside the company is ever going to
> see the strange sameAs triples which protect his archaic but expensive
> code from the wild syntactic deviance in the new RDF.
Sure - just as we don't actually use owl:sameAs triples for internal storage
in http://sameas.org/
We just provide them as an output format.
Hugh
> 
> Pat

Re: Show me the money - (was Subjects as Literals)

[Richard Cyganiak]

[trimming cc list]

On 2 Jul 2010, at 11:19, Patrick Durusau wrote:
As I say in another post, I am not suggesting I have an alternative  
but am suggesting that we broaden the conversation to more than "we  
have invested so much so we have to be right" sort of reasoning.


The argument that Ian and various other vendors made in this thread is  
not:


  "We have invested so much that we can't afford to be wrong."

The argument is:

  "We have invested so much that we want to see a clear potential
   benefit to any spec changes."

And the concrete change discussed in this thread fails this test.

Regarding your broader point that RDF may not need sufficient user  
requirements: This is possible, but the rational response to this  
possibility is to explore alternatives (possibly including mutations  
of RDF) and test them against user needs to see if they fare better.  
Such work can not be realistically done within W3C for obvious  
reasons. It has to be done outside W3C by the community.


Unlike you, both Dan and Ian have contributed concrete proposals for  
directions of such exploration.


Best,
Richard






Hope you are having a great day!

Patrick


--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau

Re: Show me the money - (was Subjects as Literals)

[Toby Inkster]

On Fri, 2010-07-02 at 08:39 +0100, Ian Davis wrote:
> I would prefer to see this kind of effort put into n3 as a general
> logic expression system and superset of RDF that perhaps we can move
> towards once we have achieved mainstream with the core data expression
> in RDF. I'd like to see 5 or 6 alternative and interoperable n3
> implementations in use to iron out the problems, just like we have
> with RDF engines (I can name 10+ and know of no interop issues between
> them) 

I agree with this, but think it's largely a matter of terminology.

I think as a community we ought to be moving to a multi-graph model with
literal subjects, blank node predicates, etc. Whether that new model is
called "RDF" or "RDF 2" or something else entirely is largely a matter
of branding. Though that's not to say that branding isn't important - it
may be that calling the superset something other than RDF increases
confidence in both RDF and its superset.

As it happens I've recently been looking at implementing N3 (the syntax
and data model, though not the rules language) in Perl. (The RDF::Trine
framework was so incredibly close to supporting the data model already,
so I'm building on that.)

-- 
Toby A Inkster

Re: Show me the money - (was Subjects as Literals)

[Yves Raimond]

On Fri, Jul 2, 2010 at 10:38 AM, Henry Story  wrote:
>
> On 2 Jul 2010, at 09:39, Ian Davis wrote:
>
>> On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes  wrote:
>>> Jeremy, your argument is perfectly sound from your company's POV, but not
>>> from a broader perspective. Of course, any change will incur costs by those
>>> who have based their assumptions upon no change happening. Your company took
>>> a risk, apparently. IMO it was a bad risk, as you could have implemented a
>>> better inference engine if you had allowed literal subjects internally in
>>> the first place, but whatever. But that is not an argument for there to be
>>> no further change for the rest of the world and for all future time. Who
>>> knows what financial opportunities might become possible when this change is
>>> made, opportunities which have not even been contemplated until now?
>>>
>>
>> I think Jeremy speaks for most vendors that have made an investment in
>> the RDF stack. In my opinion the time for this kind of low level
>> change was back in 2000/2001 not after ten years of investment and
>> deployment. Right now the focus is rightly on adoption and fiddling
>> with the fundamentals will scare off the early majority for another 5
>> years. You are right that we took a risk on a technology and made our
>> investment accordingly, but it was a qualified risk because many of us
>> also took membership of the W3C to have influence over the technology
>> direction.
>>
>> I would prefer to see this kind of effort put into n3 as a general
>> logic expression system and superset of RDF that perhaps we can move
>> towards once we have achieved mainstream with the core data expression
>> in RDF. I'd like to see 5 or 6 alternative and interoperable n3
>> implementations in use to iron out the problems, just like we have
>> with RDF engines (I can name 10+ and know of no interop issues between
>> them)
>
> I like this solution.
>
> There are a lot of good reasons for keeping rdf/xml as is.
> For one many people use it. Secondly it does not have named graphs, which 
> means that
> at least people using it, must stick to saying what they know/believe, 
> instead of trying to
> say what they think other people know. This means there is a lot less ways for
> people to go wrong.
>
> But we could focus on N3 and standardise it as N4 perhaps. This would
> give us a powerful notation for writing out rules, doing clever belief based
> reasoning, add methematical functions, ... which will be needed by any linked
> data application: those apps need to have rules such as "believe what Jane 
> says
> about knitting but not about medicine".
>
> As those advanced usages get to be tested we can then finally come back to 
> rdf/xml
> and other formats if needed and enhance them. I think doing this will help the
> vendors start thinking about enhancing their rdf machinery making
> it a lot more flexible over time. For some reason these vendors seem to
> have unnecessarily limited the functioning of their engines.
>
> It is also a lot easier to teach something like N3.

+1

I would be very happy with that as well. A standardised N3 would be great.

Best,
y

>
> Henry
>
>
>> Ian
>>
>
>

Re: Show me the money - (was Subjects as Literals)

[Henry Story]

On 2 Jul 2010, at 11:57, Patrick Durusau wrote:

> On 7/2/2010 5:27 AM, Ian Davis wrote:
>> On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusau  wrote:
>> 
>>   
>>> I make this point in another post this morning but is your argument that
>>> investment by vendors =
>>> 
>>> 
>> I think I just answered it there, before reading this message. Let me
>> know if not!
>> 
>>   
> I think you made a very good point about needing examples so user can say: "I 
> want to do that."
> 
> Which was one of the strong points of HTML.

Ok, what users will want is the Social Web. And here is the way to convince 
people:
"The Social Network Privacy Mess: Why we Need the Social Web"

   http://www.youtube.com/watch?v=994DvSJZyww&feature=channel


( This can of course be improved) The general ideas should be clear: 
 
 dystopia: we cannot have all social data centralised on one server.
 utopia: there is a lot of money to be made in creating the social web, and 
thereby
increasing democracy in the world.

 This can ONLY be done with linked data. And there is a real need for it.


Henry

RE: Show me the money - (was Subjects as Literals)

[Michael Schneider]

Pat Hayes wrote:

>It is also important to distinguish changes which actually harm your
>code, and changes which simply make it less complete. Allowing literal
>subjects will not invalidate your engines in any way: it will simply
>mean that there will be some RDF out there which they may be unable to
>process, or which might require them to do some preprocessing (such as
>replacing
> :p :o .
>with
>_:x :p :o .
>_:x :same  .
>with a special company-specific :same property marker. For example.)
>But none of this *invalidates* your huge pile of expensive investment
>in code base; it merely makes it just a wee bit obsolete. But by the
>time this process is over, it will be obsolete anyway, I am sure,
>simply by virtue of being about four or five years older.

If I were forced to update an existing/in-use RDF-based system to treat
literal subjects, without changing the core of the system (for the moment at
least), the following idea comes to mind:

1) The parsers and formatters would need to be extended to treat
generalized RDF syntax, and there would need to be some internal
representation of generalized RDF graphs. Ok, this would be some work to do,
but...

2) Once I have an internal representation of generalized RDF graphs, we
can come up with a set of new URIs to replace all the "bad" literal subjects
with these URIs. There would be a table representing this replacement.

3) Now, I can give the translated RDF to the original tool. The RDF is
fine now (conforming to RDF2004), and so the tool will work without
problems. The output of the tool would also be RDF2004 compliant. Because,
the tool, being a traditional RDF tool, won't introduce literals in subject
position itself.

4) All output is then be re-translated to a generalized RDF form, by
substituting the special URIs with the original literals, and can be
presented as such by the new formatters (see 1).

There is certainly some code to write here, but most of it should be
straightforward to create and could be written once and made into an
open-source/free-software library to be used by everyone who needs it. And,
why shouldn't this library not be created by the RDF2 working group itself?

So, the "investment-killer" argument should not be a major one, at least...

Michael

--
Dipl.-Inform. Michael Schneider
Research Scientist, Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: michael.schnei...@fzi.de
WWW  : http://www.fzi.de/michael.schneider
===
FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts, Az 14-0563.1, RP Karlsruhe
Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
===

Re: Show me the money - (was Subjects as Literals)

[Patrick Durusau]

Ian,

On 7/2/2010 5:27 AM, Ian Davis wrote:

On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusau  wrote:

   

I make this point in another post this morning but is your argument that
investment by vendors =

 

I think I just answered it there, before reading this message. Let me
know if not!

   
I think you made a very good point about needing examples so user can 
say: "I want to do that."


Which was one of the strong points of HTML.

I am less convinced that argues in favor of vendor position that their 
investment equals how things have to be on the technical side.


Consider that when users see a large visualization of the WWW they 
think, "I want to do that!", but when they see the graph code required, 
they become less interested. ;-)


I am less inclined to listen to vendors and much more inclined to listen 
to users.


A short story to illustrate the issue:

The Library of Congress Subject Headings, could be considered an 
"ontology" of sorts, has been under construction for decades. But until 
Karen Drabenstott (now Karen Marley) decided to ask the question of how 
effectively do users of the LCSH fare, no one had asked the question. I 
won't keep you in suspense, the results were:


Overall percentages of correct meanings for subject headings in the 
original order of subdivisions were as follows: children, 32%, adults, 
40%, reference 53%, and technical services librarians, 56%.


Ouch!

See "Understanding Subject Heading in Library Catalogs" 
http://www-personal.si.umich.edu/~ylime/meaning/meaning.pdf


It may be that the RDF stack is everything it is reported to be, but 
that does not mean that it fits the needs of users as they see them. The 
only way to know that is to ask. Asking the few users that mistakenly 
wander into working group meetings is probably insufficient.


Hope you are looking forward to a great weekend!

Patrick

--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau

Re: Show me the money - (was Subjects as Literals)

[Henry Story]

On 2 Jul 2010, at 09:39, Ian Davis wrote:

> On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes  wrote:
>> Jeremy, your argument is perfectly sound from your company's POV, but not
>> from a broader perspective. Of course, any change will incur costs by those
>> who have based their assumptions upon no change happening. Your company took
>> a risk, apparently. IMO it was a bad risk, as you could have implemented a
>> better inference engine if you had allowed literal subjects internally in
>> the first place, but whatever. But that is not an argument for there to be
>> no further change for the rest of the world and for all future time. Who
>> knows what financial opportunities might become possible when this change is
>> made, opportunities which have not even been contemplated until now?
>> 
> 
> I think Jeremy speaks for most vendors that have made an investment in
> the RDF stack. In my opinion the time for this kind of low level
> change was back in 2000/2001 not after ten years of investment and
> deployment. Right now the focus is rightly on adoption and fiddling
> with the fundamentals will scare off the early majority for another 5
> years. You are right that we took a risk on a technology and made our
> investment accordingly, but it was a qualified risk because many of us
> also took membership of the W3C to have influence over the technology
> direction.
> 
> I would prefer to see this kind of effort put into n3 as a general
> logic expression system and superset of RDF that perhaps we can move
> towards once we have achieved mainstream with the core data expression
> in RDF. I'd like to see 5 or 6 alternative and interoperable n3
> implementations in use to iron out the problems, just like we have
> with RDF engines (I can name 10+ and know of no interop issues between
> them)

I like this solution.

There are a lot of good reasons for keeping rdf/xml as is.
For one many people use it. Secondly it does not have named graphs, which means 
that
at least people using it, must stick to saying what they know/believe, instead 
of trying to
say what they think other people know. This means there is a lot less ways for
people to go wrong.

But we could focus on N3 and standardise it as N4 perhaps. This would
give us a powerful notation for writing out rules, doing clever belief based 
reasoning, add methematical functions, ... which will be needed by any linked 
data application: those apps need to have rules such as "believe what Jane says 
about knitting but not about medicine".

As those advanced usages get to be tested we can then finally come back to 
rdf/xml
and other formats if needed and enhance them. I think doing this will help the
vendors start thinking about enhancing their rdf machinery making
it a lot more flexible over time. For some reason these vendors seem to 
have unnecessarily limited the functioning of their engines.

It is also a lot easier to teach something like N3. 

Henry


> Ian
> 

Re: Subjects as Literals

[Patrick Durusau]

Pat,

On 7/1/2010 11:14 PM, Pat Hayes wrote:






That is fine. Nobody mandates that your (or anyone else's) software 
must be able to handle all cases of RDF. But to impose an irrational 
limitation on a standard just because someone has spent a lot of money 
is a very bad way to make progress, IMO. Although, I believe that 
there are still people using COBOL, so you may have a point.




It was reported that the average American has nearly 4,000 interactions 
with COBOL based transaction systems per year. 
http://www.itjungle.com/tfh/tfh060109-story03.html


So, yes, there are people still using COBOL.

Hope you are having a great day!

Patrick

--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau