Re: subjects as literals
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]
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)
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: Show me the money - (was Subjects as Literals)
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: Subjects as Literals
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: Subjects as Literals
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
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
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 even better
Re: Capturing the discussion (RE: Subjects as Literals)
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
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.
http://bblfish.net/#me 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 http://bblfish.net/;
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
http://bblfish.net/#me then referred to any person named Henry Story ? In
any possible world?
In the foaf+ssl space perhaps it
Re: Subjects as Literals
On Tue, Jul 6, 2010 at 10:23 AM, Danny Ayers danny.ay...@gmail.com 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 reto.bachm...@trialox.org 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
On Mon, 5 Jul 2010 17:43:17 -0500 Pat Hayes pha...@ihmc.us 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 mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: Subjects as Literals
On Tue, Jul 6, 2010 at 12:40 AM, Hugh Glaser h...@ecs.soton.ac.uk 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 MS 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
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 reto.bachm...@trialox.org 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
+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-Gmuerreto.bachm...@trialox.org 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
On 6 Jul 2010, at 09:19, Dan Brickley wrote: On Tue, Jul 6, 2010 at 12:40 AM, Hugh Glaser h...@ecs.soton.ac.uk 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 MS 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
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 reto.bachm...@trialox.org 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
Toby Inkster: On Mon, 5 Jul 2010 17:43:17 -0500 Pat Hayes pha...@ihmc.us 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] http://www.w3.org/TR/owl2-rdf-based-semantics/#topic-ont-generalrdf -- 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 wrote: On Tue, 6 Jul 2010 14:03:19 +0200 Michael Schneider schn...@fzi.de 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
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
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
On Tue, 6 Jul 2010 16:30:06 +0200 Michael Schneider schn...@fzi.de wrote: What do you mean by false statement? False in the same sense that this is false: http://danbri.org/foaf.rdf#danbri 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 mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: Subjects as Literals
On 6 Jul 2010, at 14:03, Michael Schneider wrote: Toby Inkster: On Mon, 5 Jul 2010 17:43:17 -0500 Pat Hayes pha...@ihmc.us 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
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
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
On Jul 6, 2010, at 2:05 AM, Toby Inkster wrote:
On Mon, 5 Jul 2010 17:43:17 -0500
Pat Hayes pha...@ihmc.us 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
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk
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
+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 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
Hello! On Tue, Jul 6, 2010 at 10:02 PM, Nathan nat...@webr3.org 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
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 pha...@ihmc.us 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
On Tue, Jul 6, 2010 at 11:17 PM, Pat Hayes pha...@ihmc.us 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
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
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
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
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
On 06/07/2010 09:44, Henry Story henry.st...@gmail.com wrote: On 6 Jul 2010, at 09:19, Dan Brickley wrote: On Tue, Jul 6, 2010 at 12:40 AM, Hugh Glaser h...@ecs.soton.ac.uk 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 MS 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
Re: Subjects as Literals
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
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, SNIP 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. SNIP 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
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:googol 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 -
Linked Data Spec (was Re: Subjects as Literals)
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
Capturing the discussion (RE: Subjects as Literals)
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 ===
Re: Subjects as Literals
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.
Re: Subjects as Literals
On 6 July 2010 13:34, Nathan nat...@webr3.org 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: Show me the money - (was Subjects as Literals)
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 jer...@topquadrant.com 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)
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: Subjects as Literals
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]
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: Subjects as Literals
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 de...@iki.fi 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
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: Show me the money - (was Subjects as Literals)
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]
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] http://www.w3.org/TR/rdf-mt/ -- 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)
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: Show me the money - (was Subjects as Literals)
On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes pha...@ihmc.us 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) Ian
Re: Show me the money - (was Subjects as Literals)
Ian Davis wrote: On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes pha...@ihmc.us 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)
Nathan wrote: Ian Davis wrote: On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes pha...@ihmc.us 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 :) (at RDF Semantic level.. my how this has came full circle, Best, Nathan
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
[cc's trimmed] I'm with Jeremy here, the problem's economic not technical. If we could introduce subjects-as-literals in a way that: (a) doesn't invalidate any existing RDF, and (b) doesn't permit the generation of RDF/XML that existing applications cannot parse, then I think there's a possible way forward. #g -- BTW, which list is the most appropriate for this discussion? I seem to be getting 4 copies of some messages! Jeremy Carroll wrote: Jiří Procházka wrote: I wonder, when using owl:sameAs or related, to name literals to be able to say other useful thing about them in normal triples (datatype, language, etc) does it break OWL DL yes it does (or any other formalism which is base of some ontology extending RDF semantics)? Not OWL full Or would it if rdf:sameAs was introduced? It would still break OWL DL Best, Jiri OWL DL is orthogonal to this issue. The OWL DLers already prohibit certain RDF - specifically the workaround for not having literal as subjects. So they are neutral. I reiterate that I agree whole-heartedly with the technical arguments for making this change; however the economic case is missing. Jeremy
Re: Show me the money - (was Subjects as Literals)
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. 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 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. 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.) 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. Benji -- Benjamin Nowack http://bnode.org/ http://semsol.com/
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
Hello Ivan! On Fri, Jul 2, 2010 at 5:50 AM, Ivan Mikhailov imikhai...@openlinksw.com wrote: Hello Yves, It's a virtuoso function surfaced as a predicate. magic predicate was an initial moniker used at creation time. bif:contains doesn't exist in pure triple form etc.. Why couldn't it? For example, you may want to express exactly what triple lead you to give a particular result, and within that scope you may end up having to write: Brickley bif:contains ckley in RDF. Forbidding literals as subjects makes this statement impossible to express, however that's a very sensible thing you may want to express. There are also lots of literal search examples that comes to mind: Acton str:double_metaphone AKTN . Smith str:soundex S530 . Yes, SPARQL permits literals in subject position, and we use that for dirty hacks. That does not mean that raw data should permit the same. SPARQL (and especially our SPARQL/BI) uses many different things in subject position, e.g., variables (and expressions, up to subqueries) that's not an excuse to allow the same in raw data. First: this is *not* a dirty hack. Brickley bif:contains ckley is a perfectly valid thing to say. I don't even say about technical price of the extension for both developers (extra work) and each user of any big RDF storage (extra hardware). I simply don't see a reason, because literals are simply 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 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: Subjects as Literals
On Thu, Jul 1, 2010 at 4:20 AM, Hugh Glaser h...@ecs.soton.ac.uk wrote: In fact, a question I would like to ask, but suspect that noone who can answer it is still reading this thread ( :-) ): For those who implement RDF stores, do you have to do something special to reject RDF that has literals as subject? I think more important than storing RDF is storing the expressed content. For the content expressed with RDF and OWL, resources can have 0 to n names and 0 or 1 literal value. When the content has to be represented as RDF triples owl:sameAs statements are created for the multiple names as well as possibly a bnode to prevent the literal being in subject position. As by using OWL this limitation of the RDF Abstract Syntax does not limit the expressiveness I see no need to change anything. 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. Reto
Re: Show me the money - (was Subjects as Literals)
Ian, On 7/2/2010 3:39 AM, Ian Davis wrote: On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayespha...@ihmc.us 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 make this point in another post this morning but is your argument that investment by vendors = 1) technology meets need perceived by users, and 2) technology meets the need in a way acceptable to users ?? What early majority? How long did it take HTML to take off? Or XML for that matter, at least in its simpler forms? 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. 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: Subjects as Literals, [was Re: The Ordered List Ontology]
Pat Hayes wrote: Just to clarify, this is a purely syntactic restriction. Allowing literals in subject position would require **no change at all** to the RDF semantics. Indeed. And this is probably one of the reasons why several RDF-related standards have already adopted literal subjects. Some examples: * For the OWL 2 RDF-Based Semantics, being an extension of the RDF Semantics, it has been explicitly allowed (in the MAY sense) to apply it to generalized RDF, where literals and bNodes may occur in any position of a triple: http://www.w3.org/TR/owl2-rdf-based-semantics/#topic-ont-generalrdf (However, OWL 2 Full is still defined to be the language that consists of the RDF-Based Semantics and the official RDF Syntax, i.e. where subjects are not allowed to be literals.) * The OWL 2 RL/RDF Ruleset also allows for generalized RDF, see the second paragraph of http://www.w3.org/2007/OWL/wiki/Profiles#Reasoning_in_OWL_2_RL_and_RDF_Grap hs_using_Rules * The RIF RDF and OWL Compatibility specification (just became a W3C Recommendation) also uses generalized RDF, see the note at http://www.w3.org/TR/2010/REC-rif-rdf-owl-20100622/#note-generalized-rdf-gr aphs and the definitions at http://www.w3.org/TR/2010/REC-rif-rdf-owl-20100622/#RDF_Vocabularies_and_Gr aphs * SPARQL 1.1 (still work in progress) allows literal subjects in Triple Patterns: http://www.w3.org/TR/sparql11-query/#defn_TriplePattern I could imagine that this list of important technologies allowing for literal subjects will grow over time, and maybe there even exist some more today that I missed. If RDF2 would also adopt generalized RDF, all these RDF-dependent standards could then be updated by dropping all these MAYs and similar statements. 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)
On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusau patr...@durusau.net 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! Ian Ian
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
Yves, On Fri, Jul 2, 2010 at 10:15 AM, Yves Raimond yves.raim...@gmail.com wrote: First: this is *not* a dirty hack. Brickley bif:contains ckley is a perfectly valid thing to say. You could, today, use data: URIs to represent literals with no change to any RDF system. Ian
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
On Fri, 2010-07-02 at 08:50 +0100, Graham Klyne wrote: [cc's trimmed] I'm with Jeremy here, the problem's economic not technical. If we could introduce subjects-as-literals in a way that: (a) doesn't invalidate any existing RDF, and (b) doesn't permit the generation of RDF/XML that existing applications cannot parse, then I think there's a possible way forward. Yes, there's such a way, more over, it will be just a small subset of a richer language that is widely used already, so it will require very little coding. When there's a need in SPARQL-like extensions, like subjects-as-literals, there's a straightforward way of serializing data as SPARQL fragments. Note that in this way not only subjects-as-literals are available, but even SPARQL 1.1 features like path expressions or for each X expressed as ?X in an appropriate place of an appropriate BGP. Best Regards, Ivan Mikhailov, OpenLink Software http://virtuoso.openlinksw.com
Re: Subjects as Literals
Pat, On 7/1/2010 11:14 PM, Pat Hayes wrote: snip 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
Re: Show me the money - (was Subjects as Literals)
On 2 Jul 2010, at 09:39, Ian Davis wrote: On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes pha...@ihmc.us 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: Show me the money - (was Subjects as Literals)
Ian, On 7/2/2010 5:27 AM, Ian Davis wrote: On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusaupatr...@durusau.net 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)
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 literal :p :o . with _:x :p :o . _:x :same literal . 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)
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 Durusaupatr...@durusau.net 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=994DvSJZywwfeature=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)
On Fri, Jul 2, 2010 at 10:38 AM, Henry Story henry.st...@gmail.com wrote: On 2 Jul 2010, at 09:39, Ian Davis wrote: On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes pha...@ihmc.us 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: Subjects as Literals, [was Re: The Ordered List Ontology]
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)
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 Durusaupatr...@durusau.net 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=994DvSJZywwfeature=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: Show me the money - (was Subjects as Literals)
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)
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: Subjects as Literals, [was Re: The Ordered List Ontology]
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)
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 Durusaupatr...@durusau.net 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=994DvSJZywwfeature=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: Show me the money - (was Subjects as Literals)
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 Durusaupatr...@durusau.netwrote: 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=994DvSJZywwfeature=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:
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
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 dan...@danbri.org 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 means nothing?
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
Re: Show me the money - (was Subjects as Literals)
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]
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 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
Re: Subjects as Literals
On Fri, Jul 2, 2010 at 2:16 AM, Reto Bachmann-Gmuer reto.bachm...@trialox.org 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]
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: Subjects as Literals, [was Re: The Ordered List Ontology]
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 Os 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 Os 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: Show me the money - (was Subjects as Literals)
On Fri, Jul 2, 2010 at 2:01 AM, Benjamin Nowack bnow...@semsol.com 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 outcome seems to be purely technical. Too bad. I
Re: Show me the money - (was Subjects as Literals)
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 Durusaupatr...@durusau.netwrote: 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=994DvSJZywwfeature=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.
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
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 Os 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 Os 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: Subjects as Literals, [was Re: The Ordered List Ontology]
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]
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: Show me the money - (was Subjects as Literals)
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 pha...@ihmc.us 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: Show me the money - (was Subjects as Literals)
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 pha...@ihmc.us 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: Subjects as Literals, [was Re: The Ordered List Ontology]
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 dan...@danbri.org 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 ?
So why: Subject-Predicate-Object (SPO) everywhere re. RDF?
As I said, the terminology is used so as to make it easier to refer to
the various parts of a triple. Yes, triples are ordered. The
'linguistic' flavor of the SPO terminology is an unfortunate accident
of history. In other forums, people
Re: Subjects as Literals
On Fri, Jul 2, 2010 at 8:34 AM, Pat Hayes pha...@ihmc.us 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
On Jul 2, 2010, at 11:06 AM, Paul Gearon wrote: On Fri, Jul 2, 2010 at 8:34 AM, Pat Hayes pha...@ihmc.us 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: Show me the money - (was Subjects as Literals)
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, [was Re: The Ordered List Ontology]
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 dan...@danbri.org 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 commentary and unnecessary
insults.
You can have a conversation without being insulting, you know.
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
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
[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]
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]
On Fri, Jul 2, 2010 at 8:34 PM, Jeremy Carroll jer...@topquadrant.com 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]
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]
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 dan...@danbri.org 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 believe an S-P-O triple is a piece of information (Data Object has a
Name and at least one Attribute=Value pair).
What I desscribe actually has zilch to do with RDF as I am inclined to
believe you see RDF :-) Thus, in a way, the literal-subject
