FYI: Blog on HTTP Link header and host-wide well-known URI-s, and Linked Data

[Ivan Herman]

This is just to draw attention on Jonathan Rees' blog on these subjects:

http://www.w3.org/QA/2010/07/new_opportunities_for_linked_d.html

Ivan (the go-between:-)


Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf







smime.p7s
Description: S/MIME cryptographic signature

Re: Subjects as Literals

[Danny Ayers]

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

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

My mistake, it is rdf:value

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

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

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

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

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

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

Cheers,
Danny.

-- 
http://danny.ayers.name

Security of Dereference in Linked Data

[Sandro Hawke]

On Tue, 2010-07-06 at 23:27 +0200, Dan Brickley wrote:
> On Tue, Jul 6, 2010 at 11:17 PM, Pat Hayes  wrote:
> [...]
> >> This is
> >> the canonical way to find it's meaning, and is the initial procedure we
> >> should use to arbitrate between competing understandings of its meaning.
> >
> > Whoo, I doubt if that idea is going to fly. I sincerely hope not. Using
> > that, how would you determine the meaning of the DC vocabulary?
> 
> It's also worth bearing in mind that Web sites get hacked from time to
> time. W3C gets attacked regularly (but is pretty robust). The FOAF
> servers were compromised a year or two back (but the xmlns.com site
> was untouched). For a while, foaf-project.org was serving evil PHP and
> ugly links, as was my own home page. This kind of mischief should be
> kept in mind by anyone building a system that assumes you'll get
> canonical meaning from an HTTP GET...

My first answer to this is that lots and lots of society trusts the Web
in general and certain websites in particular.  Before the world learns
to adopt and trust linked data, the vocabulary servers are probably
going to have to become more robust and carefully managed.

My second answer is to mention a proposal I worked on some years back to
tackle this with crypto:  http://www.w3.org/2003/08/introhash/v2

I backed off that proposal because I think, at least for now, the first
answer is good enough.   But I still like the general idea of putting
hashes into URIs to make them more secure and to  allow for secure
mirroring, ... but we'll have to see if it becomes worthwhile some day.

  -- Sandro

Re: Subjects as Literals

[Ivan Mikhailov]

Antoine, all,

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

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

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

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

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

2. It will throw it away later.

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

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

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

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

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

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

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

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

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

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

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

Capturing the discussion (RE: Subjects as Literals)

[Sandro Hawke]

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

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

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

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

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

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

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

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

Linked Data Spec (was Re: Subjects as Literals)

[Sandro Hawke]

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

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

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

Two questions for the W3C community going forward are:

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

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

The workshop output on these subjects is here:

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

and see the strawpoll results:

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

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

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

-- Sandro

Re: Subjects as Literals

[Sampo Syreeni]

On 2010-07-05, Pat Hayes wrote:

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


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


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



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


Why? Is there a lesson to be learnt there?

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


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


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


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


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


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


That I know too.

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


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


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


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


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


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


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

--
Sampo Syreeni, aka decoy - de

Re: Subjects as Literals

[Jeremy Carroll]

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

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



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






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


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

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

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


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

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


This would have interesting consequences for n-ary predicates

Jeremy

Re: Subjects as Literals

[David Booth]

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

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

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



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

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

Re: [ANN] Major update of Lexvo.org

[Gerard de Melo]

Hi Ian,

Congratulations. This looks like a really valuable resource. I took a
tour around as many parts I could find and started incorporating parts
into my cross-linking project.

Is there a guide to the various URI patterns you have used? For
example, you have resources such as
http://www.lexvo.org/page/iso3166-1/AE but I don't know which other
ISO standard codings are included without randomly trying them.
   

Thanks. The details page now has a more exhaustive list of URI patterns:
http://www.lexvo.org/linkeddata/details.html

The ISO 3166-1 URIs were the only ones we did not give examples for on
the main page, simply because there are many existing sites already
defining URIs for countries. The main reason for creating new ISO 3166-1
URIs was to serve language-related data about the countries and
facilitate browsing the site. We do not recommend using these URIs
externally. We'll be adding owl:sameAs links to GeoNames soon.

Best,
Gerard


On Mon, Jul 5, 2010 at 1:46 PM, Gerard de Melo  wrote:
   

Hi everyone,

We'd like to announce a major update of Lexvo.org [1], a site that brings
information about languages, words, characters, and other human language-
related entities to the LOD cloud. Lexvo.org adds a new perspective to the
Web of Data by exposing how everything in our world is connected in terms
of language, e.g. via words and names and their semantic relationships.

Lexvo.org first went live in 2008 just in time for that year's ISWC.
Recently, the site has undergone a major revamp, with plenty of help from
Bernard Vatant, who has decided to redirect lingvoj.org's language URIs to
the corresponding Lexvo.org ones.

At this point, the site is no longer considered to be in beta testing,
and we invite you to take a closer look. On the front page, you'll find
links to examples that will allow you get a feel for the type of
information being offered. We'd love to hear your comments.

Best,
Gerard

[1] http://www.lexvo.org/

--
Gerard de Melo
Max Planck Institute for Informatics
http://www.mpi-inf.mpg.de/~gdemelo/





 



--
Gerard de Melo
Max Planck Institute for Informatics
http://www.mpi-inf.mpg.de/~gdemelo/

Re: [ANN] Major update of Lexvo.org

[Ian Davis]

Congratulations. This looks like a really valuable resource. I took a
tour around as many parts I could find and started incorporating parts
into my cross-linking project.

Is there a guide to the various URI patterns you have used? For
example, you have resources such as
http://www.lexvo.org/page/iso3166-1/AE but I don't know which other
ISO standard codings are included without randomly trying them.

On Mon, Jul 5, 2010 at 1:46 PM, Gerard de Melo  wrote:
> Hi everyone,
>
> We'd like to announce a major update of Lexvo.org [1], a site that brings
> information about languages, words, characters, and other human language-
> related entities to the LOD cloud. Lexvo.org adds a new perspective to the
> Web of Data by exposing how everything in our world is connected in terms
> of language, e.g. via words and names and their semantic relationships.
>
> Lexvo.org first went live in 2008 just in time for that year's ISWC.
> Recently, the site has undergone a major revamp, with plenty of help from
> Bernard Vatant, who has decided to redirect lingvoj.org's language URIs to
> the corresponding Lexvo.org ones.
>
> At this point, the site is no longer considered to be in beta testing,
> and we invite you to take a closer look. On the front page, you'll find
> links to examples that will allow you get a feel for the type of
> information being offered. We'd love to hear your comments.
>
> Best,
> Gerard
>
> [1] http://www.lexvo.org/
>
> --
> Gerard de Melo
> Max Planck Institute for Informatics
> http://www.mpi-inf.mpg.de/~gdemelo/
>
>
>
>
>

Re: Subjects as Literals

[Hugh Glaser]

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

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

Re: Subjects as Literals

[Henry Story]

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

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

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

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

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

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

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

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

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

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

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

You can keep using URIs as subjects :-)

Henry


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

RE: Subjects as Literals

[Michael Schneider]

Nathan wrote:

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

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

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

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

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

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

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

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

>Best & TIA,
>
>Nathan

Best,
Michael

[1] 
[2] 
[3] 

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

Re: Subjects as Literals

[Nathan]

Thanks for the clarification Antione,

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


Best,

Nathan

Antoine Zimmermann wrote:

So to clarify a bit:

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


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



AZ

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

Pat Hayes wrote:

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


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

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


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

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

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

Preferably a serialization unspecific answer :)

Best & TIA,

Nathan

Re: Subjects as Literals

[Dan Brickley]

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

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

cheers,

Dan

Re: Subjects as Literals

[Antoine Zimmermann]

So to clarify a bit:

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


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



AZ

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

Pat Hayes wrote:

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


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

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

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

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

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

Preferably a serialization unspecific answer :)

Best & TIA,

Nathan

Re: Subjects as Literals

[Pat Hayes]

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



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


Toby Inkster:


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

Well, nobody is suggesting allowing literals as predicates  
(although

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


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

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

officially defined to have no meaning.


So, if

  :s "lit" :o .

must not have a semantic meaning, what about

  "lit" rdf:type rdf:Property .


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


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




What is the difference between the above and

  foaf:knows a rdf:Property .

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


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



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


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


Pat




Henry





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

Re: RDF Extensibility

[Pat Hayes]

On Jul 6, 2010, at 10:03 AM, Dan Brickley wrote:


2010/7/6 Jiří Procházka :

On 07/06/2010 03:35 PM, Toby Inkster wrote:

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


So, if

:s "lit" :o .

must not have a semantic meaning, what about

"lit" rdf:type rdf:Property .

? As, according to what you say above, you are willing to allow for
literals in subject position, this triple is fine for you
syntactically. But what about its meaning? Would this also be
officially defined to have no meaning?


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

  foaf:Person a rdf:Property .


Why do you think so?
I believe it is valid RDF and even valid under RDFS semantic  
extension.
Maybe OWL says something about disjointness of RDF properties and  
classes

URI can be many things.


It just so happens as a fact in the world, that the thing called
foaf:Person isn't a property. It's a class.


The world doesn't have facts like that in it. Classes and properties  
are intellectual constructs, not the stuff of reality. Hell, if a  
particle can be a wave, then surely a class can be a property. Anyway,  
RDF doesn't make logical a priori rulings about these kind of  
metaphysical segregations. For example, xsd:Number is a class, a  
property and an individual in RDF.


Pat



Some might argue that there are no things that are simultaneously RDF
classes and properties, but that doesn't matter for the FOAF case. The
RSS1 vocabulary btw tried to define something that was both,
rss1:image I think; but this was a backwards-compatibility hack.

cheers,

Dan





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

Re: Subjects as Literals

[Yves Raimond]

Hello!

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

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

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

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

Best,
y

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

Re: RDF Extensibility

[Pat Hayes]

On Jul 6, 2010, at 9:34 AM, Jiří Procházka wrote:


On 07/06/2010 03:35 PM, Toby Inkster wrote:

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


So, if

   :s "lit" :o .

must not have a semantic meaning, what about

   "lit" rdf:type rdf:Property .

? As, according to what you say above, you are willing to allow for
literals in subject position, this triple is fine for you
syntactically. But what about its meaning? Would this also be
officially defined to have no meaning?


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

foaf:Person a rdf:Property .


Why do you think so?
I believe it is valid RDF and even valid under RDFS semantic  
extension.
Maybe OWL says something about disjointness of RDF properties and  
classes

URI can be many things.

I think there are issues about RDF extensibility which haven't been
solved and they concern:
a) semantics
b) serializations

In case of a) I don't have cleared up my thoughts yet, but generally I
would like to know:
How are semantic extensions to work together in automated system?


Well, the semantics always defines some notion of entailment, and your  
system is supposed to respect that notion: not draw invalid  
conclusions, draw as many valid conclusions as you feel are useful,  
don't say things are inconsistent when they aren't, etc.. Otherwise,  
you have free rein. So, if you have several semantic extensions, they  
are each provide a set of such entailments and they should add up to  
one single set of legal entailments.



How to let agent know that the data is described using new RDF
extension, which the client doesn't know and the data could be (or
definitely are) false if it is interpreted using vanilla RDF  
semantics?


NOt false, if its a semantic extension (they can't contradict the RDF  
semantics., only extend it.) BUt same point more generally: how do we  
know, given some RDF, what semantic extensions are appropriately to be  
used when interpreting it? That is a VERY good question. This is  
something that RDF2 could most usefully tackle, if only in a first- 
step (ham-fisted?) kind of a way. We were aware that this was an issue  
in the first WG, but it was just too far outside out charter, and our  
energy level, to tackle properly. One obvious (?) thing to say is that  
using a construction from a namespace which is associated with the  
definition of any RDF semantic extension is deemed to bring along the  
necessary interpretation conditions from the extension, so that for  
example if I use owl:sameAs in some RDF, then I mean it to be  
understood using the OWL semantic conditions. We all do this without  
remarking upon it, but loosely, and to make this precise and normative  
would be a very interesting (and useful) exercise. (An issue already  
here is, which version of the OWL semantics is intended? Does the use  
in RDF also "import" the OWL-DL syntactic restrictions on its use, for  
example?)


Pat




b) How should my system know that the data which is just being  
processed

is new revision of RDF/XML and not malformed RDF/XML when forward
compatibility was out of sight, out of mind when RDF/XML was designed?

Best,
Jiri Prochazka




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

[Nathan]

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


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

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


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

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


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


Preferably a serialization unspecific answer :)

Best & TIA,

Nathan

RE: Subjects as Literals

[Michael Schneider]

+1

The fact that

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

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

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

Best,
Michael

[1] 

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

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

Re: Subjects as Literals

[Pat Hayes]

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


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


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


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


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


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


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

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


Pat Hayes




--
Toby A Inkster








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

Re: Subjects as Literals

[Antoine Zimmermann]

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



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


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

What is the difference between the above and

foaf:knows a rdf:Property .


What is the difference between the above and

foaf:lit a rdf:Property .

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


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


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

Henry



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

Re: Subjects as Literals

[Antoine Zimmermann]

Ivan, all,


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


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

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

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


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


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


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



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



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




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




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

Re: Subjects as Literals

[Henry Story]

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

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

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

What is the difference between the above and

   foaf:knows a rdf:Property .

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

Henry

Re: Subjects as Literals

[Toby Inkster]

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

> What do you mean by "false statement"?

False in the same sense that this is false:


foaf:name "Barry Chuckle" .

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

-- 
Toby A Inkster

Re: Subjects as Literals

[Nathan]

Ivan Mikhailov wrote:

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

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


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


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


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


Best,

Nathan

Re: Subjects as Literals

[Ivan Mikhailov]

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

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

Best Regards,

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

RE: RDF Extensibility

[Michael Schneider]

Dan Brickley wrote:

>2010/7/6 Jiří Procházka :
>> On 07/06/2010 03:35 PM, Toby Inkster wrote:

>>> It would have a meaning. It would just be a false statement. The
>>> same as the following is a false statement:
>>>
>>>       foaf:Person a rdf:Property .
>>
>> Why do you think so?
>> I believe it is valid RDF and even valid under RDFS semantic
>extension.
>> Maybe OWL says something about disjointness of RDF properties and
>classes
>> URI can be many things.
>
>It just so happens as a fact in the world, that the thing called
>foaf:Person isn't a property. It's a class.

The semantics of RDFS allows to use the same name for both a class and a
property.

What you call a "fact in the world" is, from a semantics point of view, just
one particular interpretation that you have in mind. Other interpretations
than yours are possible (I hope :)). And the (model-theoretic) semantics of
RDFS is of a form that a given RDF statement is false, only if /all/
possible interpretations are false. (This is not specific to the RDF
semantics, btw.)

>Some might argue that there are no things that are simultaneously RDF
>classes and properties, but that doesn't matter for the FOAF case. 

Let's not forget that we are here discussing a suggested change of the
syntax and (possibly) semantics of the RDF specification, and the FOAF case
doesn't matter for this, I would say. FOAF refers to RDFS (and OWL), not the
other way round (except, perhaps, as a usecase). Of course, one could define
an extension of the RDFS semantics specifically for FOAF that better
reflects the intended situation (either formally or informally, or
implicitly by a reference implementation of a specific FOAF reasoner). But
that's a different discussion.

>The
>RSS1 vocabulary btw tried to define something that was both,
>rss1:image I think; but this was a backwards-compatibility hack.

You might find more of these "hacks" elsewhere, and more to come in the
future. Interestingly, the idea of using the same name for both a class and
a property is somewhat that has been introduced in OWL DL just in OWL 2, so
it exists in OWL DL for less than a year now (officially). In RDFS and
(therefore) in OWL Full, it has always been allowed, though.

>cheers,
>
>Dan

Best,
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: RDF Extensibility

[Ian Davis]

2010/7/6 Dan Brickley :
> 2010/7/6 Jiří Procházka :
>>>
>>> It would have a meaning. It would just be a false statement. The
>>> same as the following is a false statement:
>>>
>>>       foaf:Person a rdf:Property .
>>
>> Why do you think so?
>> I believe it is valid RDF and even valid under RDFS semantic extension.
>> Maybe OWL says something about disjointness of RDF properties and classes
>> URI can be many things.
>
> It just so happens as a fact in the world, that the thing called
> foaf:Person isn't a property. It's a class.
>

I think that is your view and the view you have codified as the
authoritative definition that I can look up at that URI, but there is
nothing preventing me from making any assertion I like and working
with that in my own environment. If it's useful to me to say
foaf:Person a rdf:Property then I can just do that. However, I
shouldn't expect that assertion to interoperate with other people's
views of the world.

Ian

Re: RDF Extensibility

[Dan Brickley]

2010/7/6 Jiří Procházka :
> On 07/06/2010 03:35 PM, Toby Inkster wrote:
>> On Tue, 6 Jul 2010 14:03:19 +0200
>> "Michael Schneider"  wrote:
>>
>>> So, if
>>>
>>>     :s "lit" :o .
>>>
>>> must not have a semantic meaning, what about
>>>
>>>     "lit" rdf:type rdf:Property .
>>>
>>> ? As, according to what you say above, you are willing to allow for
>>> literals in subject position, this triple is fine for you
>>> syntactically. But what about its meaning? Would this also be
>>> officially defined to have no meaning?
>>
>> It would have a meaning. It would just be a false statement. The
>> same as the following is a false statement:
>>
>>       foaf:Person a rdf:Property .
>
> Why do you think so?
> I believe it is valid RDF and even valid under RDFS semantic extension.
> Maybe OWL says something about disjointness of RDF properties and classes
> URI can be many things.

It just so happens as a fact in the world, that the thing called
foaf:Person isn't a property. It's a class.

Some might argue that there are no things that are simultaneously RDF
classes and properties, but that doesn't matter for the FOAF case. The
RSS1 vocabulary btw tried to define something that was both,
rss1:image I think; but this was a backwards-compatibility hack.

cheers,

Dan

RDF Extensibility

[Jiří Procházka]

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

Why do you think so?
I believe it is valid RDF and even valid under RDFS semantic extension.
Maybe OWL says something about disjointness of RDF properties and classes
URI can be many things.

I think there are issues about RDF extensibility which haven't been
solved and they concern:
a) semantics
b) serializations

In case of a) I don't have cleared up my thoughts yet, but generally I
would like to know:
How are semantic extensions to work together in automated system?
How to let agent know that the data is described using new RDF
extension, which the client doesn't know and the data could be (or
definitely are) false if it is interpreted using vanilla RDF semantics?

b) How should my system know that the data which is just being processed
is new revision of RDF/XML and not malformed RDF/XML when forward
compatibility was out of sight, out of mind when RDF/XML was designed?

Best,
Jiri Prochazka



signature.asc
Description: OpenPGP digital signature

RE: Subjects as Literals

[Michael Schneider]

Toby Inkster wrote:

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

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

  ex:x owl:differentFrom ex:x .

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

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

Under which semantics is this a false statement?

Michael

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

Re: Subjects as Literals

[Toby Inkster]

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

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

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

foaf:Person a rdf:Property .

-- 
Toby A Inkster

[ANN] Major update of Lexvo.org

[Gerard de Melo]

Hi everyone,

We'd like to announce a major update of Lexvo.org [1], a site that brings
information about languages, words, characters, and other human language-
related entities to the LOD cloud. Lexvo.org adds a new perspective to the
Web of Data by exposing how everything in our world is connected in terms
of language, e.g. via words and names and their semantic relationships.

Lexvo.org first went live in 2008 just in time for that year's ISWC.
Recently, the site has undergone a major revamp, with plenty of help from
Bernard Vatant, who has decided to redirect lingvoj.org's language URIs to
the corresponding Lexvo.org ones.

At this point, the site is no longer considered to be in beta testing,
and we invite you to take a closer look. On the front page, you'll find
links to examples that will allow you get a feel for the type of
information being offered. We'd love to hear your comments.

Best,
Gerard

[1] http://www.lexvo.org/

--
Gerard de Melo
Max Planck Institute for Informatics
http://www.mpi-inf.mpg.de/~gdemelo/

Re: [ANN] Uberblic.org V1.0 - data consolidation for the web of data

[Kingsley Idehen]

Georgi Kobilarov wrote:

Hi Kingsley,

  

Congrats re. 1.0 release!



Thanks! 



  

One thing, please confirm the situation re. Uberblic and DBpedia at the
ontology level, are they 1:1 or do you have an alternative ontology for
Uberlic.



No, Uberblic and DBpedia ontology are not 1:1. The Uberblic ontology started
quite similar (Person, Place, Work... the high-level stuff), but is
evolving. One of our main objectives is to properly curate our dataset
structure. So we decided to build our own ontology that we (and later our
community) can control. 
  

Georgi,

Okay, where do I get the ontology? Is it part of the dumps directory?
 
  

BTW -- congrats to Germany re. World Cup! Their's to lose IMHO (so keep
that Jersey on etc..).



I think I'll need to buy a new jersey soon... one with four stars on it ;-)
  


After the world cup, don't change behavior midstream :-)


Kingsley

Cheers,
Georgi



  

Georgi,

Where do I get the ontology? Is it part of the dumps directory?

--

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

[Michael Schneider]

Toby Inkster:

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

So, if 

:s "lit" :o .

must not have a semantic meaning, what about

"lit" rdf:type rdf:Property .

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

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

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

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

Or what about

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

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

:s "lit" :o . 

So we are back at the start.

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

Michael

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

[1] 

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

Re: Subjects as Literals

[Nathan]

Danny Ayers wrote:

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

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

Serialization formats could support

"Jo" :nameOf :Jo

as a shortcut for

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

and a store could (internally) store the latter as

"Jo" :nameOf :Jo

for compactness and efficiency.


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

:Jo rdfs:value "Jo"

together with

:Jo rdf:type rdfs:Literal

?


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

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


Best,

Nathan

RE: [ANN] Uberblic.org V1.0 - data consolidation for the web of data

[Georgi Kobilarov]

Hi Kingsley,

> Congrats re. 1.0 release!

Thanks! 


> One thing, please confirm the situation re. Uberblic and DBpedia at the
> ontology level, are they 1:1 or do you have an alternative ontology for
> Uberlic.

No, Uberblic and DBpedia ontology are not 1:1. The Uberblic ontology started
quite similar (Person, Place, Work... the high-level stuff), but is
evolving. One of our main objectives is to properly curate our dataset
structure. So we decided to build our own ontology that we (and later our
community) can control. 

 
> BTW -- congrats to Germany re. World Cup! Their's to lose IMHO (so keep
> that Jersey on etc..).

I think I'll need to buy a new jersey soon... one with four stars on it ;-)

Cheers,
Georgi

Re: Subjects as Literals

[Henry Story]

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

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

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

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

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

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

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

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


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

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


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

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

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

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

Henry

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

Re: Subjects as Literals

[Robert Fuller]

+1

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

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

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

Serialization formats could support

"Jo" :nameOf :Jo

as a shortcut for

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

and a store could (internally) store the latter as

"Jo" :nameOf :Jo

for compactness and efficiency.


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

:Jo rdfs:value "Jo"

together with

:Jo rdf:type rdfs:Literal

?

Cheers,
Danny.



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

Re: Subjects as Literals

[Danny Ayers]

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

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

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

:Jo rdfs:value "Jo"

together with

:Jo rdf:type rdfs:Literal

?

Cheers,
Danny.

-- 
http://danny.ayers.name

Re: Subjects as Literals

[Dan Brickley]

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


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

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

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

cheers,

Dan

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

Re: Subjects as Literals

[Toby Inkster]

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

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

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

-- 
Toby A Inkster