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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
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
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
On 2010/7/1 22:35, Kingsley Idehen wrote:
Yves Raimond wrote:
Hello Kingsley!
[snip]
IMHO an emphatic NO.
RDF is about constructing structured descriptions where Subjects have
Identifiers in the form of Name References (which may or many
resolve to
Structured Representations of Referents carried or borne by Descriptor
Docs/Resources). An Identifier != Literal.
If you are in a situation where you can't or don't want to mint an HTTP
based Name, simply use a URN, it does the job.
It does look like you're already using literal subjects in OpenLink
Virtuoso though:
http://docs.openlinksw.com/virtuoso/rdfsparql.html
SQLSELECT *
FROM people
WHERE
{
?s foaf:Name ?name . ?name bif:contains 'rich*'.
}
Best,
y
Were is the Literal Subject in the query above?
bif:contains is a function/magic predicate scoped to Literal Objects.
people != people.
Let's consider the following inequality:
people != people
if we imposed different interpretations on both sides，then we certainly
could conclude the first 'people' is non-equivalence to the second
'people' in semantic. Semantic of things is not reflected in the literal
meaning, but is reflected in interpreter's behavior and its impact on
the environment/world.
my two cents.
regards
Peng
What am I missing?
Re: Subjects as Literals
How about internationalization? If the subject is a literal, how would translations be associated? On Jul 1, 2010, at 5:14 , Pat Hayes wrote: On Jun 30, 2010, at 8:14 PM, Ross Singer wrote: I suppose my questions here would be: 1) What's the use case of a literal as subject statement (besides being an academic exercise)? A few off the top of my head. 1. Titles of books, music and other works might have properties such as the date they were registered, who owns them, etc.. 2. Dates may have significant properties such as being the day that someone was shot or when war broke out. 3. Dates represented as character strings in some known date format other than XSD can be asserted to be the same as a 'real' date by writing things like 01-02-1481 sameDateAs 01022010^^xsd:date . 01-02-1481 isDateIn :MuslimCalendar . I am sure that you can think of many more. In general, allowing strings as subjects opens the door to a wide range of uses of RDF to 'attach' information to pieces of text. Another example which occurs to me: this piece of text is the French translation of that piece of text, expressed as a single RDF triple with two literals. 4. It has been noted that one can map datatyping into RDF itself by treating the datatypes as properties, and there are several use cases for this. The natural way to do it involves having literals as subject, since the dataype map goes from the string to the value: 23 xsd:number 23^^xsd:number . 5. Also, allowing this purely academically has the notable advantage of simplifying RDF(S) inferencing, including making the forward-chaining rules simpler. Right now, there is a strange oddity involving blank node instantiations. One can say things like 'the number of my children is prime by using an blank node: :PatHayes hasNumberOfKids _:x . _:x :a :PrimeNumber . But this legal RDF can't be instantiated in the obvious way: :PatHayes hasNumberOfKids 3^^xsd:number . 3^^xsd:number :a PrimeNumber . This trips up RDFS reasoners, which can often produce inferences by a kind of sneaky use-a-bnode-instead maneuver even when the obvious conclusion cannot be stated because of the restriction. (There are a few examples in the RDF semantics document.) Removing the restriction would enable reasoners to work more efficiently with a smaller set of rules. (I gather that at least some of the RDFS rule engines out there already do this, internally.) 2) Does literal as subject make sense in linked data (I ask mainly from a follow your nose perspective) if blank nodes are considered controversial? Seems to me that from the linked data POV, anything that can be an object should also be useable as a subject. Of course, that does allow for the view that both of them should only ever be IRIs, I guess. Pat Hayes -- Dr. Axel Rauschmayer axel.rauschma...@ifi.lmu.de http://hypergraphs.de/ :: Hyena: connected information manager, free at hypergraphs.de/hyena/ ::
Re: Subjects as Literals
On Wed, 2010-06-30 at 22:14 -0500, Pat Hayes wrote:
On Jun 30, 2010, at 8:14 PM, Ross Singer wrote:
I suppose my questions here would be:
1) What's the use case of a literal as subject statement (besides
being an academic exercise)?
A few off the top of my head.
1. Titles of books, music and other works might have properties such
as the date they were registered, who owns them, etc..
2. Dates may have significant properties such as being the day that
someone was shot or when war broke out.
3. Dates represented as character strings in some known date format
other than XSD can be asserted to be the same as a 'real' date by
writing things like
01-02-1481 sameDateAs 01022010^^xsd:date .
01-02-1481 isDateIn :MuslimCalendar .
I am sure that you can think of many more. In general, allowing
strings as subjects opens the door to a wide range of uses of RDF to
'attach' information to pieces of text. Another example which occurs
to me: this piece of text is the French translation of that piece of
text, expressed as a single RDF triple with two literals.
4. It has been noted that one can map datatyping into RDF itself by
treating the datatypes as properties, and there are several use cases
for this. The natural way to do it involves having literals as
subject, since the dataype map goes from the string to the value:
23 xsd:number 23^^xsd:number .
5. Also, allowing this purely academically has the notable advantage
of simplifying RDF(S) inferencing, including making the forward-
chaining rules simpler. Right now, there is a strange oddity involving
blank node instantiations. One can say things like 'the number of my
children is prime by using an blank node:
:PatHayes hasNumberOfKids _:x .
_:x :a :PrimeNumber .
But this legal RDF can't be instantiated in the obvious way:
:PatHayes hasNumberOfKids 3^^xsd:number .
3^^xsd:number :a PrimeNumber .
This trips up RDFS reasoners, which can often produce inferences by a
kind of sneaky use-a-bnode-instead maneuver even when the obvious
conclusion cannot be stated because of the restriction. (There are a
few examples in the RDF semantics document.) Removing the restriction
would enable reasoners to work more efficiently with a smaller set of
rules. (I gather that at least some of the RDFS rule engines out there
already do this, internally.)
2) Does literal as subject make sense in linked data (I ask mainly
from a follow your nose perspective) if blank nodes are considered
controversial?
Seems to me that from the linked data POV, anything that can be an
object should also be useable as a subject. Of course, that does allow
for the view that both of them should only ever be IRIs, I guess.
Thanks for the good use cases.
So, in my brief unofficial workshop report [1] I kind of oversimplified
(lied) about one thing. In general, topics were included because they
had considerable support present at the workshop. But not
Literals-as-Subject; it was included because TimBL said it was important
to him. That means, however, it had no advocate in the room, so perhaps
it's no great surprise it ended at the bottom. Fortunately, the
workshop is not the final arbiter here.
I think perhaps the biggest reason against Literals-as-Subject is this
RDF/XML concern. To be clear, yes, RDF/XML is already unable to
serialize some graphs, but this would make the matter much worse. It
would make RDF/XML be much more clearly a second-class serialization,
and several people expressed concerns that relegating RDF/XML to such a
position was not a good idea.
People also expressed (to my surprise) willingness to make small,
backward compatible changes to RDF/XML, if necessary to keep up with
changes in the model. This was clear for Add Graphs to RDF/XML which
was 8th on the list, the first that didn't have tons of support, but was
still largely desired.
I think support for literals-as-subject could be added to RDF/XML in a
pretty okay way. Something like a special property, rdf:aboutLiteral:
ns:PrimeNumber
rdf:aboutLiteral rdf:datatype=xs;int3/rdf:aboutLiteral
/ns:PrimeNumber
In v1 parsers, it might generate an RDF namespace warning and it would
generate reasonable but not-quite-right triples: { _:x a ns:PrimeNumber;
_:x rdf:aboutLiteral 3}. V2 parsers would generate the intended { 3 a
ns:PrimeNumber } triple.
(Opinion, Jeremy? *If* we end up doing a v2 for graph naming, the
economic cost of also doing this becomes quite small.)
There's also a school of opposition here which is about aligning RDF
subjects with Object-Oriented Programming's objects. For that school,
literals as subjects could be a real problem. But I'm not sure anyone
takes that school very seriously now, so I'll let someone stand up and
argue that position if they want, rather than trying to do it for them.
-- Sandro
[1] http://www.w3.org/2010/06/rdf-work-items/table
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
On 30 Jun 2010, at 21:09, Pat Hayes wrote:
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.
I wholly agree. Allowing literals in subject position in RDF is a no-brainer.
(BTW, it would also immediately solve the 'bugs in the RDF rules' problem.)
These arguments against it are nonsensical. The REAL argument against it is
that it will mess up OWL-DL, or at any rate it *might* mess up OWL-DL.
The Description Logic police are still in charge:-)
I agree that literals can be subjects. In any case they are, because you just
can take an inverse function from a thing to a string, and you have it.
But I do think
'London' a x:Place
is bad design because really 'London' is a string and not a place.
Now of course x:Place my be the collection of names of places in english, in
which case it is ok. So it is difficult to say just like that. There would have
to be quite a lot of education in the when is it right to use strings as
subjects space.
Henry
Pat
Re: Subjects as Literals
Hello everybody, I think the main issues are already discussed. Hence, here are some summarized notes of my thoughts: 1. We shouldn't propagate that a user (always a machine or human beeing) has to go this way and not the other one. Leaving this decision by the user, leads to more user satisfaction (that's a natural point of view in my mind). That means a inverse relation should exist at every time. If a inverse relation includes a new meaning, e.g. 'child' inverse relation of 'father', than we should define this property explicitly. If not than we should define at least an anonymous inverse property (as also discussed here[1]). The outcome is, that an engine, which processes the statement to the knowledge base, should always be able to resolve incomming statement. If the statement isn't in the form as it can be store in the knowledge base (I think it is better to not store statements of an anonymous inverse property), than the engine has to transform it into the valid form (maybe its even enough to store one way and calculate the inverse relation(s)). (If the machines haven't the calculation power yet, then they will have it at least in the near future) 2. We wouldn't write back some literals, if we wouldn't know their context, e.g. changing a name of a person, wouldn't happen, if we don't know the person (the identifier of that person). That means we have always a context. 3. I really don't understand the decision between datatypes and individuals (and their disjointness as Michael Schneider point it out; maybe it's a bit naive point of view, or that I haven't such deep knowledge about really understanding DL). What about handling (datatyped) literals as in-built individuals, e.g. a string typed literal would be then internally resolved to an ex:String individual. We could reuse the well-defined xsd datatypes etc. 4. Don't believe the JSON hype ;) However, feel free to design a good Semantic Graph serialisation format based on JSON. JSON looks better than XML. N3 looks also better than XML. Currently, we have already a a very good Semantic Graph serialisation format based on N3. Why not hyping this one? ;) Cheers, Bob [1] http://www.semanticoverflow.com/questions/1126/when-should-i-use-explicit-anonymous-defined-inverse-properties Am 01.07.2010 05:14, schrieb Pat Hayes: On Jun 30, 2010, at 8:14 PM, Ross Singer wrote: I suppose my questions here would be: 1) What's the use case of a literal as subject statement (besides being an academic exercise)? A few off the top of my head. 1. Titles of books, music and other works might have properties such as the date they were registered, who owns them, etc.. 2. Dates may have significant properties such as being the day that someone was shot or when war broke out. 3. Dates represented as character strings in some known date format other than XSD can be asserted to be the same as a 'real' date by writing things like 01-02-1481 sameDateAs 01022010^^xsd:date . 01-02-1481 isDateIn :MuslimCalendar . I am sure that you can think of many more. In general, allowing strings as subjects opens the door to a wide range of uses of RDF to 'attach' information to pieces of text. Another example which occurs to me: this piece of text is the French translation of that piece of text, expressed as a single RDF triple with two literals. 4. It has been noted that one can map datatyping into RDF itself by treating the datatypes as properties, and there are several use cases for this. The natural way to do it involves having literals as subject, since the dataype map goes from the string to the value: 23 xsd:number 23^^xsd:number . 5. Also, allowing this purely academically has the notable advantage of simplifying RDF(S) inferencing, including making the forward-chaining rules simpler. Right now, there is a strange oddity involving blank node instantiations. One can say things like 'the number of my children is prime by using an blank node: :PatHayes hasNumberOfKids _:x . _:x :a :PrimeNumber . But this legal RDF can't be instantiated in the obvious way: :PatHayes hasNumberOfKids 3^^xsd:number . 3^^xsd:number :a PrimeNumber . This trips up RDFS reasoners, which can often produce inferences by a kind of sneaky use-a-bnode-instead maneuver even when the obvious conclusion cannot be stated because of the restriction. (There are a few examples in the RDF semantics document.) Removing the restriction would enable reasoners to work more efficiently with a smaller set of rules. (I gather that at least some of the RDFS rule engines out there already do this, internally.) 2) Does literal as subject make sense in linked data (I ask mainly from a follow your nose perspective) if blank nodes are considered controversial? Seems to me that from the linked data POV, anything that can be an object should also be useable as a subject. Of course, that does allow for the view that both of them should only ever be IRIs, I guess. Pat
Re: Subjects as Literals
+1 to the points below. I think one should point out that rdf semantics allows them, and that in an open world they just can't be excluded. In N3 literals as subjects are often used. And the cwm repository is a good place to look for examples @prefix log: http://www.w3.org/2000/10/swap/log#. log:parsedAsN3 rdfs:comment The subject string, parsed as N3, gives this formula. see many of the relations described in http://www.w3.org/2000/10/swap/doc/CwmBuiltins, especially the maths ones. relations between text and its md5 hash, which is used in some of the code in http://www.w3.org/2000/10/swap/doc/Trust I think it would also simplify the prgrammatic apis, such as Java. It is perhaps not the most urgent thing to do, but putting it on the seriously todo list would perhaps help people start shifting the tools to supporting them. Henry On 1 Jul 2010, at 05:14, Pat Hayes wrote: On Jun 30, 2010, at 8:14 PM, Ross Singer wrote: I suppose my questions here would be: 1) What's the use case of a literal as subject statement (besides being an academic exercise)? A few off the top of my head. 1. Titles of books, music and other works might have properties such as the date they were registered, who owns them, etc.. 2. Dates may have significant properties such as being the day that someone was shot or when war broke out. 3. Dates represented as character strings in some known date format other than XSD can be asserted to be the same as a 'real' date by writing things like 01-02-1481 sameDateAs 01022010^^xsd:date . 01-02-1481 isDateIn :MuslimCalendar . I am sure that you can think of many more. In general, allowing strings as subjects opens the door to a wide range of uses of RDF to 'attach' information to pieces of text. Another example which occurs to me: this piece of text is the French translation of that piece of text, expressed as a single RDF triple with two literals. 4. It has been noted that one can map datatyping into RDF itself by treating the datatypes as properties, and there are several use cases for this. The natural way to do it involves having literals as subject, since the dataype map goes from the string to the value: 23 xsd:number 23^^xsd:number . 5. Also, allowing this purely academically has the notable advantage of simplifying RDF(S) inferencing, including making the forward-chaining rules simpler. Right now, there is a strange oddity involving blank node instantiations. One can say things like 'the number of my children is prime by using an blank node: :PatHayes hasNumberOfKids _:x . _:x :a :PrimeNumber . But this legal RDF can't be instantiated in the obvious way: :PatHayes hasNumberOfKids 3^^xsd:number . 3^^xsd:number :a PrimeNumber . This trips up RDFS reasoners, which can often produce inferences by a kind of sneaky use-a-bnode-instead maneuver even when the obvious conclusion cannot be stated because of the restriction. (There are a few examples in the RDF semantics document.) Removing the restriction would enable reasoners to work more efficiently with a smaller set of rules. (I gather that at least some of the RDFS rule engines out there already do this, internally.) 2) Does literal as subject make sense in linked data (I ask mainly from a follow your nose perspective) if blank nodes are considered controversial? Seems to me that from the linked data POV, anything that can be an object should also be useable as a subject. Of course, that does allow for the view that both of them should only ever be IRIs, I guess. Pat Hayes
Re: Subjects as Literals
On 2010-07-01, at 03:20, Hugh Glaser 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? In my defence, I'm not reading this thread, but someone pointed me at it :) Yes, and no. The engine will reject any literals in the subject position, the index can't represent that. It's a source of significant optimisations, and we would have to do a /lot/ of engineering work to allow them. To be brief: I don't care if there are usecases for literals in the subject position. It you could rewind time 10 years I might like them in there, but we've invested millions of pounds in engineering RDF stores conforming to RDF 2004. I can't, and won't throw that work away for some relatively obscure benefits. - Steve -- Steve Harris, Garlik Limited 1-3 Halford Road, Richmond, TW10 6AW, UK +44 20 8439 8203 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
Yves Raimond wrote:
Hello Kingsley!
[snip]
IMHO an emphatic NO.
RDF is about constructing structured descriptions where Subjects have
Identifiers in the form of Name References (which may or many resolve to
Structured Representations of Referents carried or borne by Descriptor
Docs/Resources). An Identifier != Literal.
If you are in a situation where you can't or don't want to mint an HTTP
based Name, simply use a URN, it does the job.
It does look like you're already using literal subjects in OpenLink
Virtuoso though:
http://docs.openlinksw.com/virtuoso/rdfsparql.html
SQLSELECT *
FROM people
WHERE
{
?s foaf:Name ?name . ?name bif:contains 'rich*'.
}
Best,
y
Were is the Literal Subject in the query above?
bif:contains is a function/magic predicate scoped to Literal Objects.
people != people.
What am I missing?
--
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]
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.
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 debate may
simply help everyone understand and accept that RDF != Linked Data.
Thus, providing additional proof that RDF isn't mandatory or even
required re. delivery of HTTP based Linked Data.
RDF based Linked Data != RDF. They are different things, clearly. We
can't have it both ways (** Pat: not for you, that's for those that deem
RDF and Linked
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
On 1 Jul 2010, at 16:35, Kingsley Idehen wrote:
Yves Raimond wrote:
Hello Kingsley!
[snip]
IMHO an emphatic NO.
RDF is about constructing structured descriptions where Subjects have
Identifiers in the form of Name References (which may or many resolve to
Structured Representations of Referents carried or borne by Descriptor
Docs/Resources). An Identifier != Literal.
If you are in a situation where you can't or don't want to mint an HTTP
based Name, simply use a URN, it does the job.
It does look like you're already using literal subjects in OpenLink
Virtuoso though:
http://docs.openlinksw.com/virtuoso/rdfsparql.html
SQLSELECT *
FROM people
WHERE
{
?s foaf:Name ?name . ?name bif:contains 'rich*'.
}
Best,
y
Were is the Literal Subject in the query above?
bif:contains is a function/magic predicate scoped to Literal Objects.
people != people.
What am I missing?
Why do you think it is magic? Such a relation makes complete sense.
Given that is is a relation between literals it can be tested without needing
to look at the world. Just like an math:isgreaterThan relation ...
In fact I wonder how much SPARQL could be simplified by thinking of things this
way. Could one perhaps get rid of the FILTER( ) clause?
In any case RDF Semantics does, I believe,
allow literals in subject position. It is just that many many syntaxes
don't allow that to be expressed,
But there is nothing you can do to stop that happening semantically. A URI or
bnode
can just be names for strings.
And as for it requiring a change to the infrastructure of your DB, it is not
clear that
it immediately does, since you can alwasy rewrite
father containsLetters 6 .
as
[] owl:sameAs father;
containsLetters 6 .
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
Hi, I just want to throw my 2 cents in this discussion. I posted a comment in October 2004 related to Smart Literalproposal in Jena Discussion Group. http://tech.groups.yahoo.com/group/jena-dev/message/11581 Best regards Stephane Fellah smartRealm LLC http://tech.groups.yahoo.com/group/jena-dev/message/11581 On Thu, Jul 1, 2010 at 11:12 AM, Robert Sanderson azarot...@gmail.comwrote: On Wed, Jun 30, 2010 at 9:14 PM, Pat Hayes pha...@ihmc.us wrote: 3. Dates represented as character strings in some known date format other than XSD can be asserted to be the same as a 'real' date by writing things like 01-02-1481 sameDateAs 01022010^^xsd:date . 01-02-1481 isDateIn :MuslimCalendar . This is a great example of what is wrong with the proposal! :) Either, the literals stand by themselves and each occurrence of 01-02-1481 is a completely separate instance (and in the current syntax would get a unique identifier), or *all* occurrences of the literal can be conflated together. The distinction between a token and a type, respectively. Option 1: Literal as Token If each is its own token (unique identifiers) then one string is the same as the date given, and a completely different string is in the Muslim calendar. eg: urn:uuid1 hasValue 01-02-1481 urn:uuid1 sameDateAs 01022010^^xsd:date urn:uuid2 hasValue 01-02-1481 urn:uuid2 isDateIn :MuslimCalendar This makes the proposal pointless, as you can't express two statements about the same literal subject. The only thing you can do is express the inverse of existing properties... at the expense of complexity and the burden of unnecessary choice. (title is easy as the only way to do it, adding isTitleOf gains us nothing we couldn't already express) Option 2: Literal as Type However, if all occurrences of that string are the same entity and can be merged together, then we also have: 01-02-1481 sameDateAs 1481-02-01^^xsd:date .// ddmm 01-02-1481 sameDateAs 1481-01-02^^xsd:date .// mmdd 01-02-1481 isDateIn :RomanCalendar This also makes the proposal pointless as you cannot say anything meaningful which is globally true about a literal. That same string is at least three different dates in two different calendars. Drat that pesky global truth requirement! The only way that Pat's example makes sense is if the context of the literal is constrained to the current named graph. If there was interest in fixing RDF, then making Named Graphs a core feature would be my first agenda item! Rob Sanderson
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
Hello!
IMHO an emphatic NO.
RDF is about constructing structured descriptions where Subjects have
Identifiers in the form of Name References (which may or many resolve to
Structured Representations of Referents carried or borne by Descriptor
Docs/Resources). An Identifier != Literal.
If you are in a situation where you can't or don't want to mint an HTTP
based Name, simply use a URN, it does the job.
It does look like you're already using literal subjects in OpenLink
Virtuoso though:
http://docs.openlinksw.com/virtuoso/rdfsparql.html
SQLSELECT *
FROM people
WHERE
{
?s foaf:Name ?name . ?name bif:contains 'rich*'.
}
Best,
y
Were is the Literal Subject in the query above?
?name is a literal. And it is used as a subject.
Best,
y
bif:contains is a function/magic predicate scoped to Literal Objects.
people != people.
What am I missing?
--
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 1 Jul 2010, at 16:35, Kingsley Idehen wrote:
Yves Raimond wrote:
Hello Kingsley!
[snip]
IMHO an emphatic NO.
RDF is about constructing structured descriptions where Subjects have
Identifiers in the form of Name References (which may or many resolve to
Structured Representations of Referents carried or borne by Descriptor
Docs/Resources). An Identifier != Literal.
If you are in a situation where you can't or don't want to mint an HTTP
based Name, simply use a URN, it does the job.
It does look like you're already using literal subjects in OpenLink
Virtuoso though:
http://docs.openlinksw.com/virtuoso/rdfsparql.html
SQLSELECT *
FROM people
WHERE
{
?s foaf:Name ?name . ?name bif:contains 'rich*'.
}
Best,
y
Were is the Literal Subject in the query above?
bif:contains is a function/magic predicate scoped to Literal Objects.
people != people.
What am I missing?
Why do you think it is magic? Such a relation makes complete sense.
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..
Given that is is a relation between literals it can be tested without needing
to look at the world. Just like an math:isgreaterThan relation ...
In fact I wonder how much SPARQL could be simplified by thinking of things this
way. Could one perhaps get rid of the FILTER( ) clause?
In any case RDF Semantics does, I believe,
allow literals in subject position. It is just that many many syntaxes
don't allow that to be expressed,
But there is nothing you can do to stop that happening semantically. A URI or
bnode
can just be names for strings.
And as for it requiring a change to the infrastructure of your DB, it is not
clear that
it immediately does, since you can alwasy rewrite
father containsLetters 6 .
as
[] owl:sameAs father;
containsLetters 6 .
DBMS wise, indexing is an issue which ultimately leads to data access
performance problems etc.. Steve already covered that ditto Ivan in
earlier comments, I believe.
In Virtuoso an IRI is a native type with implications as per comment above.
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
--
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 Thu, Jul 1, 2010 at 5:22 PM, Kingsley Idehen kide...@openlinksw.com wrote:
Henry Story wrote:
On 1 Jul 2010, at 16:35, Kingsley Idehen wrote:
Yves Raimond wrote:
Hello Kingsley!
[snip]
IMHO an emphatic NO.
RDF is about constructing structured descriptions where Subjects have
Identifiers in the form of Name References (which may or many resolve
to
Structured Representations of Referents carried or borne by Descriptor
Docs/Resources). An Identifier != Literal.
If you are in a situation where you can't or don't want to mint an HTTP
based Name, simply use a URN, it does the job.
It does look like you're already using literal subjects in OpenLink
Virtuoso though:
http://docs.openlinksw.com/virtuoso/rdfsparql.html
SQLSELECT *
FROM people
WHERE
{
?s foaf:Name ?name . ?name bif:contains 'rich*'.
}
Best,
y
Were is the Literal Subject in the query above?
bif:contains is a function/magic predicate scoped to Literal Objects.
people != people.
What am I missing?
Why do you think it is magic? Such a relation makes complete sense.
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 .
...
Best,
y
Given that is is a relation between literals it can be tested without
needing
to look at the world. Just like an math:isgreaterThan relation ...
In fact I wonder how much SPARQL could be simplified by thinking of things
this
way. Could one perhaps get rid of the FILTER( ) clause?
In any case RDF Semantics does, I believe, allow literals in subject
position. It is just that many many syntaxes
don't allow that to be expressed,
But there is nothing you can do to stop that happening semantically. A
URI or bnode
can just be names for strings.
And as for it requiring a change to the infrastructure of your DB, it is
not clear that
it immediately does, since you can alwasy rewrite
father containsLetters 6 .
as
[] owl:sameAs father;
containsLetters 6 .
DBMS wise, indexing is an issue which ultimately leads to data access
performance problems etc.. Steve already covered that ditto Ivan in earlier
comments, I believe.
In Virtuoso an IRI is a native type with implications as per comment above.
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
--
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]
Yves Raimond wrote:
Hello!
IMHO an emphatic NO.
RDF is about constructing structured descriptions where Subjects have
Identifiers in the form of Name References (which may or many resolve to
Structured Representations of Referents carried or borne by Descriptor
Docs/Resources). An Identifier != Literal.
If you are in a situation where you can't or don't want to mint an HTTP
based Name, simply use a URN, it does the job.
It does look like you're already using literal subjects in OpenLink
Virtuoso though:
http://docs.openlinksw.com/virtuoso/rdfsparql.html
SQLSELECT *
FROM people
WHERE
{
?s foaf:Name ?name . ?name bif:contains 'rich*'.
}
Best,
y
Were is the Literal Subject in the query above?
?name is a literal. And it is used as a subject.
Yves,
Here's why its deemed magic/function/unreal predicate (a function
selectively working on literal data associated with the URI):
1. http://bit.ly/cQJTWQ -- SPARQL Query Results Page
2. http://bit.ly/acQc4u -- Actual SPARQL Query
There isn't an actual Literal Subject in the Virtuoso RDF DBMS. The
RDF_QUAD Table explicitly has Column S set to type IRI.
Here is the actual SQL DML for RDF_QUAD:
create table DB.DBA.RDF_QUAD
(
P IRI_ID,
S IRI_ID,
O ANY,
G IRI_ID,
PRIMARY KEY (P, S, O, G)
);
Kingsley
Best,
y
bif:contains is a function/magic predicate scoped to Literal Objects.
people != people.
What am I missing?
--
Regards,
Kingsley Idehen President CEO OpenLink Software Web:
http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
--
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 Thu, Jul 1, 2010 at 5:45 PM, Henry Story henry.st...@gmail.com wrote: On 1 Jul 2010, at 18:18, Yves Raimond wrote: In any case RDF Semantics does, I believe, allow literals in subject position. It is just that many many syntaxes don't allow that to be expressed, It doesn't seem to be allowed in the RDF semantics: http://www.w3.org/TR/rdf-concepts/#section-Literals A literal may be the object of an RDF statement, but not the subject or the predicate. Yes, but a bnode or a URI can refer to a literal. So if those can refer to a literal, then instead of writing [1] _:n1 owl:sameAs hello; numLetters 5 . Why not also allow one to write [2] hello numLetters 5. ? That is what I meant. In any case one can always map [2] to [1], so I am not sure the costs of allowing [2] need be that high. Every current implementation could just parse [2] and write it out as [1]. No? It just seems that [2] is a more concise way of writing things, and it is conceptually cleaner. I definitely agree... For my thesis work, I had to store quite a lot of signal processing computations in RDF, and had to hack a few triple stores (mainly SWI's one) to handle literals as subjects. I used a similar hack to do that, it was very easy to implement... y
Lexvo.org - a semiotic approach to Re: Subjects as Literals
Hi all Re-naming the subject to try and get out of the general noise :) I'm been following this noisy thread with amazement. I've no clear position on the issue, just take the opportunity to attract the attention of the community to the work of Gerard de Melo at Lexvo.org [1] which has been updated lately with new resources. I've posted today [2] why I think this is important and won't repeat it here in details, but in a nutshell Lexvo.org proposes a semiotic and pragmatic approach to this issue. Lexvo.org considers a particular type of Literals, terms in natural language. Say 'mean'@en. Since this literal in the current state of affairs can't be used as a subject, Lexvo.org provides a one-to-one representation of such terms by URIs. http://lexvo.org/id/term/eng/mean identifies the term 'mean'@en This URI, in subject position, can be used to describe the term, and in object position, to assert that a concept uses it as a label.And translations in other languages and so on. I won't elaborate, Gerard is likely to make a formal announcement in the days to come, but I just wanted to point the resource as maybe relevant to this debate. Cheers Bernard [1] http://lexvo.org [2] http://blog.hubjects.com/2010/07/what-mean-means.html -- Bernard Vatant Senior Consultant Vocabulary Data Engineering Tel: +33 (0) 971 488 459 Mail: bernard.vat...@mondeca.com Mondeca 3, cité Nollez 75018 Paris France Web:http://www.mondeca.com Blog:http://mondeca.wordpress.com
Re: Subjects as Literals
On Jul 1, 2010, at 10:12 AM, Robert Sanderson wrote: On Wed, Jun 30, 2010 at 9:14 PM, Pat Hayes pha...@ihmc.us wrote: 3. Dates represented as character strings in some known date format other than XSD can be asserted to be the same as a 'real' date by writing things like 01-02-1481 sameDateAs 01022010^^xsd:date . 01-02-1481 isDateIn :MuslimCalendar . This is a great example of what is wrong with the proposal! :) Either, the literals stand by themselves and each occurrence of 01-02-1481 is a completely separate instance (and in the current syntax would get a unique identifier), or *all* occurrences of the literal can be conflated together. The distinction between a token and a type, respectively. The current RDF model clearly mandates that we understand these as types rather than tokens, just like URIs . So I will only respond to that alternative. Option 2: Literal as Type However, if all occurrences of that string are the same entity and can be merged together, then we also have: 01-02-1481 sameDateAs 1481-02-01^^xsd:date .// ddmm 01-02-1481 sameDateAs 1481-01-02^^xsd:date .// mmdd 01-02-1481 isDateIn :RomanCalendar This also makes the proposal pointless as you cannot say anything meaningful which is globally true about a literal. That same string is at least three different dates in two different calendars. Drat that pesky global truth requirement! So, what is the problem? That one string is, indeed, three different dates in three different calendars. The string chat is one word in French, a different word in English. But it is the same string in both cases; and the literal denotes the string. The only way that Pat's example makes sense is if the context of the literal is constrained to the current named graph. If there was interest in fixing RDF, then making Named Graphs a core feature would be my first agenda item! Well, I agree about the conclusion, but not for this reason. Pat Rob Sanderson IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola(850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
On Jul 1, 2010, at 3:38 AM, Henry Story wrote:
On 30 Jun 2010, at 21:09, Pat Hayes wrote:
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.
I wholly agree. Allowing literals in subject position in RDF is a
no-brainer. (BTW, it would also immediately solve the 'bugs in the
RDF rules' problem.) These arguments against it are nonsensical.
The REAL argument against it is that it will mess up OWL-DL, or at
any rate it *might* mess up OWL-DL.
The Description Logic police are still in charge:-)
I agree that literals can be subjects. In any case they are, because
you just can take an inverse function from a thing to a string, and
you have it.
But I do think
'London' a x:Place
is bad design because really 'London' is a string and not a place.
Absolutely. That triple plus a reasonably sensible ontology of places
plus a basic RDFS reasoner should flag a contradiction fairly directly.
Pat
Now of course x:Place my be the collection of names of places in
english, in which case it is ok. So it is difficult to say just like
that. There would have to be quite a lot of education in the when is
it right to use strings as subjects space.
Henry
Pat
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 1, 2010, at 5:34 AM, Steve Harris wrote: On 2010-07-01, at 03:20, Hugh Glaser 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? In my defence, I'm not reading this thread, but someone pointed me at it :) Yes, and no. The engine will reject any literals in the subject position, the index can't represent that. It's a source of significant optimisations, and we would have to do a /lot/ of engineering work to allow them. To be brief: I don't care if there are usecases for literals in the subject position. It you could rewind time 10 years I might like them in there, but we've invested millions of pounds in engineering RDF stores conforming to RDF 2004. I can't, and won't throw that work away for some relatively obscure benefits. 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. Pat Hayes - Steve -- Steve Harris, Garlik Limited 1-3 Halford Road, Richmond, TW10 6AW, UK +44 20 8439 8203 http://www.garlik.com/ Registered in England and Wales 535 7233 VAT # 849 0517 11 Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola(850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
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?
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).
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.
Why do you say this? It is certainly as much a name as, say, Patrick
J. Hayes. It is a well-formed string which denotes something, and its
denotation is perfectly clear, in fact computable. So, it is a name. I
challenge you to specify what you mean by Name in such a way that it
excludes literals as names, other than by simply reiterating your bare
claim that they are not.
**
I guess my own subtle mistake (re. this thread) is deeming
Identifiers and Names to be equivalent , when they aren't
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
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? variables or formulae as in n3? 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 ;)
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
On Jul 2, 2010, at 12:07 AM, Nathan wrote: Pat Hayes wrote: On Jul 1, 2010, at 11:49 PM, Nathan wrote: 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? variables or formulae as in n3? 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? None at all. The semantics as stated works fine with triples which have any kind of syntactic node in any position in any combination. The same basic semantic construction is used in ISO Common Logic, which allows complete syntactic freedom, so that the the same name can denote an individual, a property, a function and a proposition all at the same time. Pat PS. Its not a dumb question :-) thus is N3 valid RDF? (I read yes, but want/need to hear that's right!) Well, no. It depends what you mean by 'valid RDF'. N3 obviously has a lot of syntax that goes way beyond what is legal in RDF, so its not valid RDF. But if you mean, the basic RDF semantics can be extended to cover all the constructs in N3 (without completely breaking) then yes, it can. In fact, N3 is a subset of Common Logic, and the same basic semantic construction of RDF works for all of CL. But it would be a real extension, in that all the 'extra' syntax of N3 (notably, the graph literals idea) would need to have its semantics specified explicitly. It wouldn't come for free. Hope I've answered your question (?) Pat ty so far, nathan IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola(850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
Pat Hayes wrote: On Jul 2, 2010, at 12:07 AM, Nathan wrote: Pat Hayes wrote: On Jul 1, 2010, at 11:49 PM, Nathan wrote: 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? variables or formulae as in n3? 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? None at all. The semantics as stated works fine with triples which have any kind of syntactic node in any position in any combination. The same basic semantic construction is used in ISO Common Logic, which allows complete syntactic freedom, so that the the same name can denote an individual, a property, a function and a proposition all at the same time. Pat PS. Its not a dumb question :-) thus is N3 valid RDF? (I read yes, but want/need to hear that's right!) Well, no. It depends what you mean by 'valid RDF'. N3 obviously has a lot of syntax that goes way beyond what is legal in RDF, so its not valid RDF. But if you mean, the basic RDF semantics can be extended to cover all the constructs in N3 (without completely breaking) then yes, it can. In fact, N3 is a subset of Common Logic, and the same basic semantic construction of RDF works for all of CL. But it would be a real extension, in that all the 'extra' syntax of N3 (notably, the graph literals idea) would need to have its semantics specified explicitly. It wouldn't come for free. Hope I've answered your question (?) perfectly, thanks!
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
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.
If you are in a situation where you can't or don't want to mint an HTTP
based Name, simply use a URN, it does the job.
Best,
Nathan
--
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
On Wed, 2010-06-30 at 14:30 -0400, Kingsley Idehen wrote: Nathan wrote: Pat Hayes wrote: [ . . . ] 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. If you are in a situation where you can't or don't want to mint an HTTP based Name, simply use a URN, it does the job. Can you explain *why* you think literals should not be permitted as subjects? The rationale you have given above sounds like it is saying that literals should not be subjects because RDF does not permit literals to be subjects. IMHO, RDF should allow anyone to say anything about anything -- not anyone to say anything about anything . . . except a literal. However, if you see some specific harm in permitting statements about literals, please tell us what that harm would be. -- 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, [was Re: The Ordered List Ontology]
On Jun 30, 2010, at 11:50 AM, 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.
I wholly agree. Allowing literals in subject position in RDF is a no-
brainer. (BTW, it would also immediately solve the 'bugs in the RDF
rules' problem.) These arguments against it are nonsensical. The REAL
argument against it is that it will mess up OWL-DL, or at any rate it
*might* mess up OWL-DL.
The Description Logic police are still in charge:-)
Pat
Best,
Nathan
IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St. (850)202 4416 office
Pensacola(850)202 4440 fax
FL 32502 (850)291 0667 mobile
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Re: Subjects as Literals, [was Re: The Ordered List Ontology]
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.
Pat Hayes
If you are in a situation where you can't or don't want to mint an
HTTP based Name, simply use a URN, it does the job.
Best,
Nathan
--
Regards,
Kingsley Idehen President CEO OpenLink Software Web:
http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
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
