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

2010-07-11 Thread Jeremy Carroll

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


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


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


Jeremy





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

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

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

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

Dave

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






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

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


Andy

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

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


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

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

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

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

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

Jeremy







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

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

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

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

John

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



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



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

2010-07-04 Thread Jeremy Carroll

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


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


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


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


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


Jeremy






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

2010-07-04 Thread Michael Schneider
Henry Story wrote:

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

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

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

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

Michael

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




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

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

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

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

   -- Sandro


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






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

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


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


Pat

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


Ian Davis wrote:

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

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


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


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


my how this has came full circle,

Best,

Nathan





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

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


Pat

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


Ian Davis wrote:

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

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

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

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

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

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

them)


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


my how this has came full circle,

Best,

Nathan





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








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

2010-07-02 Thread Kingsley Idehen

Patrick Durusau wrote:

Henry,

Another reason why the SW is failing:

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


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


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

It's painful.
   


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

Patrick,

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


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

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

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


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


Just stay tuned!


Kingsley


Patrick

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

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

  

Henry,

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


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


  

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


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




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

investment by vendors =



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

know if not!



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


Which was one of the strong points of HTML.

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

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

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


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

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

 increasing democracy in the world.

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



   

Several presumptions:

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


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


It's up to your imagination really.

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


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

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


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


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



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


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


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

It's painful.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2010-07-02 Thread Kingsley Idehen

Patrick Durusau wrote:

Henry,

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

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

  

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

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



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

investment by vendors =


 

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


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


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

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

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


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

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

 increasing democracy in the world.

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


   

Several presumptions:

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


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

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


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


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


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

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


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


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

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


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


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

Of course not.

You need a Web of Structured Linked Data.


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


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



Kingsley


Hope you are looking forward to a great weekend!

Patrick


Henry
   





--

Regards,

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

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









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

2010-07-02 Thread Nathan

Patrick Durusau wrote:

Henry,

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

investment by vendors =
 

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


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

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

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


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

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

 increasing democracy in the world.

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


   

Several presumptions:

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


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


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

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


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


Best!

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


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


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


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


Hope you are looking forward to a great weekend!

Patrick


Henry
   







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

2010-07-02 Thread Henry Story

On 2 Jul 2010, at 13:20, Patrick Durusau wrote:

> Henry,
> 
> Another reason why the SW is failing:

It is not failing, it is growing from strength to strength.

> 
>> You don't see it as a need because you don't think of the options you are 
>> missing. Like people in 1800 did not think horses were slow, because they 
>> did not consider that they could fly. Or if they did think of that it was 
>> just as a dream.
>> 
>> Or closer to home, in the 80ies most people did not miss getting information 
>> quickly, the library was around the corner. Or they did not miss buying 
>> their tickets online.
>> 
>> You need a bit of imagination to see what you are missing. Which is why a 
>> lot of people stop dreaming.
>> It's painful.
>>   
> 
> I would reply with equally ad hominem remarks but it isn't worth the effort.

What definition of ad hominem are you using. From Wikipedia:

[[
Ad hominem abusive usually involves insulting or belittling one's opponent, but 
can also involve pointing out factual but ostensible character flaws or actions 
which are irrelevant to the opponent's argument. This tactic is logically 
fallacious because insults and even true negative facts about the opponent's 
personal character have nothing to do with the logical merits of the opponent's 
arguments or assertions.
]]

I did not insult you. 

First: you did not present an argument. You just said:

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


So you are basing your argument on what the majority of people think. You won't 
consider something an issue until the majority of people consider it an issue, 
and not even then: until it is proven statistically that the majority of people 
think it is an issue! 

And so my argument is an reasonable answer to that: the people won't see what 
is a problem until after the problem has been solved. And I gave historical and 
recent examples to back up my case,

So again what is your argument that it is not needed, other than waiting for 
people to tell you that it is? I give an argument in the video that to enable 
the Social Web it is needed.  See the last few minuttes.

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



Henry


> 
> Patrick
> 
> On 7/2/2010 7:03 AM, Henry Story wrote:
>> On 2 Jul 2010, at 12:49, Patrick Durusau wrote:
>> 
>>   
>>> Henry,
>>> 
>>> On 7/2/2010 6:03 AM, Henry Story wrote:
>>> 
 On 2 Jul 2010, at 11:57, Patrick Durusau wrote:
 
 
   
> On 7/2/2010 5:27 AM, Ian Davis wrote:
> 
> 
>> On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusau
>> wrote:
>> 
>> 
>> 
>>   
>>> I make this point in another post this morning but is your argument that
>>> investment by vendors =
>>> 
>>> 
>>> 
>>> 
>> I think I just answered it there, before reading this message. Let me
>> know if not!
>> 
>> 
>> 
>>   
> I think you made a very good point about needing examples so user can 
> say: "I want to do that."
> 
> Which was one of the strong points of HTML.
> 
> 
 Ok, what users will want is the Social Web. And here is the way to 
 convince people:
 "The Social Network Privacy Mess: Why we Need the Social Web"
 
http://www.youtube.com/watch?v=994DvSJZyww&feature=channel
 
 
 ( This can of course be improved) The general ideas should be clear:
 
  dystopia: we cannot have all social data centralised on one server.
  utopia: there is a lot of money to be made in creating the social web, 
 and thereby
 increasing democracy in the world.
 
  This can ONLY be done with linked data. And there is a real need for it.
 
 
   
>>> Several presumptions:
>>> 
>>> 1) "there is a lot of money to be made creating the social web" - ? On what 
>>> economic model? Advertising? Can't simply presume that money can be made.
>>> 
>> Look I could leave that to you as an exercise to the reader. I don't know 
>> why people want me
>> to give them answers also on how to make money. Sometimes you have to think 
>> for yourself.
>> 
>> Just think how much bigger a global social web is. Then think everyone 
>> connecting to everyone.
>> Then think that perhaps you could sell software to firms that have certain 
>> needs, to doctors and hostpitals that have other needs, to universities, 
>> etc. etc...
>> 
>> It's up to your imagination really.
>> 
>>   
>>> 2) "thereby increasing democracy in the world" - ??? Not real sure what 
>>> that has to do with social networks. However popular "increasing democracy" 
>>> may be as a slogan, it is like "fighting terrorism."
>>> 
>> Because people can pub

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

2010-07-02 Thread Benjamin Nowack
On 02.07.2010 12:53:11, Richard Cyganiak wrote:
>But telling those user stories and marketing the solution bundles is
>not something that can realistically be done via the medium of *specs*.
Yes, full agreement here. That's why the thread felt so weird to me,
I think the entire focus is wrong. But I'm starting to realize that
this is apparently the wrong forum to state this ;) (It was the last
W3C list I was still subscribed, too, though. Time to stop whining and
move on, I guess).

>In all fairness, the workshop was specifically about figuring out what
>changes and additions to the RDF core specifications make sense, and
>it was limited by a tight schedule. Better learning material and
>similar work items were not in scope.
I see now, thx, I just re-read the workshop page. Should have known
better that this stuff is still not considered important enough to
put it on an agenda..

>W3C is running a number of XGs and IGs, which are in a position to
>produce marketing and teaching materials. Do you have proposals for
>concrete things that the existing groups should tackle?
If the XGs can't figure that out on their own, we're pretty lost.
What about interactive tools that answer "find the specs relevant to
me", "who is using this?", "what tools exist for this?", "what are
the dependencies?", "examples?", "what should I read next?". We'd
need an annotation tool for the individual specs and spec sections.
But then we'd have to use our own boring technology for what we say
it's made for. Nah.., just had this cool idea of sub-queries in
property paths, gotta work on that first.

;)
Benji


>
>Best,
>Richard
>
>
>
>>
>> Benji
>>
>> --
>> Benjamin Nowack
>> http://bnode.org/
>> http://semsol.com/
>>
>>
>
>




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

2010-07-02 Thread Patrick Durusau

Henry,

Another reason why the SW is failing:


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

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

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


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

Patrick

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

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

   

Henry,

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

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


   

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

 

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



   

I make this point in another post this morning but is your argument that
investment by vendors =



 

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



   

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

Which was one of the strong points of HTML.

 

Ok, what users will want is the Social Web. And here is the way to convince 
people:
"The Social Network Privacy Mess: Why we Need the Social Web"

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


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

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

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


   

Several presumptions:

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

Look I could leave that to you as an exercise to the reader. I don't know why 
people want me
to give them answers also on how to make money. Sometimes you have to think for 
yourself.

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

It's up to your imagination really.

   

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

Because people can publish their own data, and control what they say and to 
whome they say it a lot more.

   

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

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


   

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


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


   

4) "there is a real need for it." ? I get as annoyed as anyone with the 
multiple logins and universities do have some common logins for their internal systems 
but I am not sure I would describe it as a need.
 

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

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

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

   

At least until some survey shows that a large number of users are willing to 
pay for such a service.
 

I have never heard of an inventor making surveys to test things out. That is 
nonsense. At most what that can tell you is little details, ways to fine tune a 
system. It will never let you see the big changes coming.

   

Hope you are looking forward to a great weekend!
 

you too.

   

Patrick

 

Henry

   

--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://ww

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

2010-07-02 Thread Henry Story

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

> Henry,
> 
> On 7/2/2010 6:03 AM, Henry Story wrote:
>> On 2 Jul 2010, at 11:57, Patrick Durusau wrote:
>> 
>>   
>>> On 7/2/2010 5:27 AM, Ian Davis wrote:
>>> 
 On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusau   
 wrote:
 
 
   
> I make this point in another post this morning but is your argument that
> investment by vendors =
> 
> 
> 
 I think I just answered it there, before reading this message. Let me
 know if not!
 
 
   
>>> I think you made a very good point about needing examples so user can say: 
>>> "I want to do that."
>>> 
>>> Which was one of the strong points of HTML.
>>> 
>> Ok, what users will want is the Social Web. And here is the way to convince 
>> people:
>> "The Social Network Privacy Mess: Why we Need the Social Web"
>> 
>>http://www.youtube.com/watch?v=994DvSJZyww&feature=channel
>> 
>> 
>> ( This can of course be improved) The general ideas should be clear:
>> 
>>  dystopia: we cannot have all social data centralised on one server.
>>  utopia: there is a lot of money to be made in creating the social web, and 
>> thereby
>> increasing democracy in the world.
>> 
>>  This can ONLY be done with linked data. And there is a real need for it.
>> 
>>   
> Several presumptions:
> 
> 1) "there is a lot of money to be made creating the social web" - ? On what 
> economic model? Advertising? Can't simply presume that money can be made.

Look I could leave that to you as an exercise to the reader. I don't know why 
people want me
to give them answers also on how to make money. Sometimes you have to think for 
yourself.

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

It's up to your imagination really.

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

Because people can publish their own data, and control what they say and to 
whome they say it a lot more.

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

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


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


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


> 
> 4) "there is a real need for it." ? I get as annoyed as anyone with the 
> multiple logins and universities do have some common logins for their 
> internal systems but I am not sure I would describe it as a need.

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

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

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

> At least until some survey shows that a large number of users are willing to 
> pay for such a service.

I have never heard of an inventor making surveys to test things out. That is 
nonsense. At most what that can tell you is little details, ways to fine tune a 
system. It will never let you see the big changes coming.

> 
> Hope you are looking forward to a great weekend!

you too.

> 
> Patrick
> 
>>  Henry
>>   
> 
> -- 
> Patrick Durusau
> patr...@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
> 
> Another Word For It (blog): http://tm.durusau.net
> Homepage: http://www.durusau.net
> Twitter: patrickDurusau
> 




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

2010-07-02 Thread Richard Cyganiak

Hi Benjamin,

On 2 Jul 2010, at 11:01, Benjamin Nowack wrote:

Our problem is not lack of features (native literal subjects? c'mon!).
It is identifying the individual user stories in our broad community
and marketing respective solution bundles. The RDFa and LOD folks
have demonstrated that this is possible. Similar success stories are
probably RIF for the business rules market, OWL for the DL/KR sector,
and many more. (Mine is agile, flexi-schema website development.)


Quite right.

But telling those user stories and marketing the solution bundles is  
not something that can realistically be done via the medium of *specs*.



RDF "Next Steps" should be all about scoped learning material and
deployment. There were several workshop submissions (e.g. by Jeremy,
Lee, and Richard) that mentioned this issue, but the workshop outcome
seems to be purely technical. Too bad.


In all fairness, the workshop was specifically about figuring out what  
changes and additions to the RDF core specifications make sense, and  
it was limited by a tight schedule. Better learning material and  
similar work items were not in scope.


W3C is running a number of XGs and IGs, which are in a position to  
produce marketing and teaching materials. Do you have proposals for  
concrete things that the existing groups should tackle?


Best,
Richard





Benji

--
Benjamin Nowack
http://bnode.org/
http://semsol.com/







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

2010-07-02 Thread Bob Ferris

Hi Richard,

> Such

work can not be realistically done within W3C for obvious reasons. It
has to be done outside W3C by the community.


I believe that's what the "normal/standard" web developers (I think 
Henry Story called them "Web Monkeys" ;) ) do already, or?


Cheers,


Bob



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

2010-07-02 Thread Patrick Durusau

Henry,

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

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

   

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

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


   

I make this point in another post this morning but is your argument that
investment by vendors =


 

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


   

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

Which was one of the strong points of HTML.
 

Ok, what users will want is the Social Web. And here is the way to convince 
people:
"The Social Network Privacy Mess: Why we Need the Social Web"

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


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

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

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

   

Several presumptions:

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


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


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


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


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


Hope you are looking forward to a great weekend!

Patrick


Henry
   


--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau




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

2010-07-02 Thread Hugh Glaser

On 02/07/2010 05:36, "Pat Hayes"  wrote:
> In OWL-DL it is so restricted. Emphasis on the DL. So, don't use
> owl:sameAs. Use your own propietary sameAs; it needn't even be
> symmetric. We are after all taking RDF here, not OWL-DL. And in the
> case under discussion (keeping Jeremy from losing thousands of dollars
> or much restful sleep), nobody outside the company is ever going to
> see the strange sameAs triples which protect his archaic but expensive
> code from the wild syntactic deviance in the new RDF.
Sure - just as we don't actually use owl:sameAs triples for internal storage
in http://sameas.org/
We just provide them as an output format.
Hugh
> 
> Pat




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

2010-07-02 Thread Richard Cyganiak

[trimming cc list]

On 2 Jul 2010, at 11:19, Patrick Durusau wrote:
As I say in another post, I am not suggesting I have an alternative  
but am suggesting that we broaden the conversation to more than "we  
have invested so much so we have to be right" sort of reasoning.


The argument that Ian and various other vendors made in this thread is  
not:


  "We have invested so much that we can't afford to be wrong."

The argument is:

  "We have invested so much that we want to see a clear potential
   benefit to any spec changes."

And the concrete change discussed in this thread fails this test.

Regarding your broader point that RDF may not need sufficient user  
requirements: This is possible, but the rational response to this  
possibility is to explore alternatives (possibly including mutations  
of RDF) and test them against user needs to see if they fare better.  
Such work can not be realistically done within W3C for obvious  
reasons. It has to be done outside W3C by the community.


Unlike you, both Dan and Ian have contributed concrete proposals for  
directions of such exploration.


Best,
Richard






Hope you are having a great day!

Patrick


--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau







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

2010-07-02 Thread Toby Inkster
On Fri, 2010-07-02 at 08:39 +0100, Ian Davis wrote:
> I would prefer to see this kind of effort put into n3 as a general
> logic expression system and superset of RDF that perhaps we can move
> towards once we have achieved mainstream with the core data expression
> in RDF. I'd like to see 5 or 6 alternative and interoperable n3
> implementations in use to iron out the problems, just like we have
> with RDF engines (I can name 10+ and know of no interop issues between
> them) 

I agree with this, but think it's largely a matter of terminology.

I think as a community we ought to be moving to a multi-graph model with
literal subjects, blank node predicates, etc. Whether that new model is
called "RDF" or "RDF 2" or something else entirely is largely a matter
of branding. Though that's not to say that branding isn't important - it
may be that calling the superset something other than RDF increases
confidence in both RDF and its superset.

As it happens I've recently been looking at implementing N3 (the syntax
and data model, though not the rules language) in Perl. (The RDF::Trine
framework was so incredibly close to supporting the data model already,
so I'm building on that.)

-- 
Toby A Inkster






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

2010-07-02 Thread Yves Raimond
On Fri, Jul 2, 2010 at 10:38 AM, Henry Story  wrote:
>
> On 2 Jul 2010, at 09:39, Ian Davis wrote:
>
>> On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes  wrote:
>>> Jeremy, your argument is perfectly sound from your company's POV, but not
>>> from a broader perspective. Of course, any change will incur costs by those
>>> who have based their assumptions upon no change happening. Your company took
>>> a risk, apparently. IMO it was a bad risk, as you could have implemented a
>>> better inference engine if you had allowed literal subjects internally in
>>> the first place, but whatever. But that is not an argument for there to be
>>> no further change for the rest of the world and for all future time. Who
>>> knows what financial opportunities might become possible when this change is
>>> made, opportunities which have not even been contemplated until now?
>>>
>>
>> I think Jeremy speaks for most vendors that have made an investment in
>> the RDF stack. In my opinion the time for this kind of low level
>> change was back in 2000/2001 not after ten years of investment and
>> deployment. Right now the focus is rightly on adoption and fiddling
>> with the fundamentals will scare off the early majority for another 5
>> years. You are right that we took a risk on a technology and made our
>> investment accordingly, but it was a qualified risk because many of us
>> also took membership of the W3C to have influence over the technology
>> direction.
>>
>> I would prefer to see this kind of effort put into n3 as a general
>> logic expression system and superset of RDF that perhaps we can move
>> towards once we have achieved mainstream with the core data expression
>> in RDF. I'd like to see 5 or 6 alternative and interoperable n3
>> implementations in use to iron out the problems, just like we have
>> with RDF engines (I can name 10+ and know of no interop issues between
>> them)
>
> I like this solution.
>
> There are a lot of good reasons for keeping rdf/xml as is.
> For one many people use it. Secondly it does not have named graphs, which 
> means that
> at least people using it, must stick to saying what they know/believe, 
> instead of trying to
> say what they think other people know. This means there is a lot less ways for
> people to go wrong.
>
> But we could focus on N3 and standardise it as N4 perhaps. This would
> give us a powerful notation for writing out rules, doing clever belief based
> reasoning, add methematical functions, ... which will be needed by any linked
> data application: those apps need to have rules such as "believe what Jane 
> says
> about knitting but not about medicine".
>
> As those advanced usages get to be tested we can then finally come back to 
> rdf/xml
> and other formats if needed and enhance them. I think doing this will help the
> vendors start thinking about enhancing their rdf machinery making
> it a lot more flexible over time. For some reason these vendors seem to
> have unnecessarily limited the functioning of their engines.
>
> It is also a lot easier to teach something like N3.

+1

I would be very happy with that as well. A standardised N3 would be great.

Best,
y

>
> Henry
>
>
>> Ian
>>
>
>



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

2010-07-02 Thread Henry Story

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

> On 7/2/2010 5:27 AM, Ian Davis wrote:
>> On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusau  wrote:
>> 
>>   
>>> I make this point in another post this morning but is your argument that
>>> investment by vendors =
>>> 
>>> 
>> I think I just answered it there, before reading this message. Let me
>> know if not!
>> 
>>   
> I think you made a very good point about needing examples so user can say: "I 
> want to do that."
> 
> Which was one of the strong points of HTML.

Ok, what users will want is the Social Web. And here is the way to convince 
people:
"The Social Network Privacy Mess: Why we Need the Social Web"

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


( This can of course be improved) The general ideas should be clear: 
 
 dystopia: we cannot have all social data centralised on one server.
 utopia: there is a lot of money to be made in creating the social web, and 
thereby
increasing democracy in the world.

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


Henry


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

2010-07-02 Thread Michael Schneider
Pat Hayes wrote:

>It is also important to distinguish changes which actually harm your
>code, and changes which simply make it less complete. Allowing literal
>subjects will not invalidate your engines in any way: it will simply
>mean that there will be some RDF out there which they may be unable to
>process, or which might require them to do some preprocessing (such as
>replacing
> :p :o .
>with
>_:x :p :o .
>_:x :same  .
>with a special company-specific :same property marker. For example.)
>But none of this *invalidates* your huge pile of expensive investment
>in code base; it merely makes it just a wee bit obsolete. But by the
>time this process is over, it will be obsolete anyway, I am sure,
>simply by virtue of being about four or five years older.

If I were forced to update an existing/in-use RDF-based system to treat
literal subjects, without changing the core of the system (for the moment at
least), the following idea comes to mind:

1) The parsers and formatters would need to be extended to treat
generalized RDF syntax, and there would need to be some internal
representation of generalized RDF graphs. Ok, this would be some work to do,
but...

2) Once I have an internal representation of generalized RDF graphs, we
can come up with a set of new URIs to replace all the "bad" literal subjects
with these URIs. There would be a table representing this replacement.

3) Now, I can give the translated RDF to the original tool. The RDF is
fine now (conforming to RDF2004), and so the tool will work without
problems. The output of the tool would also be RDF2004 compliant. Because,
the tool, being a traditional RDF tool, won't introduce literals in subject
position itself.

4) All output is then be re-translated to a generalized RDF form, by
substituting the special URIs with the original literals, and can be
presented as such by the new formatters (see 1).

There is certainly some code to write here, but most of it should be
straightforward to create and could be written once and made into an
open-source/free-software library to be used by everyone who needs it. And,
why shouldn't this library not be created by the RDF2 working group itself?

So, the "investment-killer" argument should not be a major one, at least...

Michael

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




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

2010-07-02 Thread Patrick Durusau

Ian,

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

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

   

I make this point in another post this morning but is your argument that
investment by vendors =

 

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

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


Which was one of the strong points of HTML.

I am less convinced that argues in favor of vendor position that their 
investment equals how things have to be on the technical side.


Consider that when users see a large visualization of the WWW they 
think, "I want to do that!", but when they see the graph code required, 
they become less interested. ;-)


I am less inclined to listen to vendors and much more inclined to listen 
to users.


A short story to illustrate the issue:

The Library of Congress Subject Headings, could be considered an 
"ontology" of sorts, has been under construction for decades. But until 
Karen Drabenstott (now Karen Marley) decided to ask the question of how 
effectively do users of the LCSH fare, no one had asked the question. I 
won't keep you in suspense, the results were:


Overall percentages of correct meanings for subject headings in the 
original order of subdivisions were as follows: children, 32%, adults, 
40%, reference 53%, and technical services librarians, 56%.


Ouch!

See "Understanding Subject Heading in Library Catalogs" 
http://www-personal.si.umich.edu/~ylime/meaning/meaning.pdf


It may be that the RDF stack is everything it is reported to be, but 
that does not mean that it fits the needs of users as they see them. The 
only way to know that is to ask. Asking the few users that mistakenly 
wander into working group meetings is probably insufficient.


Hope you are looking forward to a great weekend!

Patrick

--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau




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

2010-07-02 Thread Henry Story

On 2 Jul 2010, at 09:39, Ian Davis wrote:

> On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes  wrote:
>> Jeremy, your argument is perfectly sound from your company's POV, but not
>> from a broader perspective. Of course, any change will incur costs by those
>> who have based their assumptions upon no change happening. Your company took
>> a risk, apparently. IMO it was a bad risk, as you could have implemented a
>> better inference engine if you had allowed literal subjects internally in
>> the first place, but whatever. But that is not an argument for there to be
>> no further change for the rest of the world and for all future time. Who
>> knows what financial opportunities might become possible when this change is
>> made, opportunities which have not even been contemplated until now?
>> 
> 
> I think Jeremy speaks for most vendors that have made an investment in
> the RDF stack. In my opinion the time for this kind of low level
> change was back in 2000/2001 not after ten years of investment and
> deployment. Right now the focus is rightly on adoption and fiddling
> with the fundamentals will scare off the early majority for another 5
> years. You are right that we took a risk on a technology and made our
> investment accordingly, but it was a qualified risk because many of us
> also took membership of the W3C to have influence over the technology
> direction.
> 
> I would prefer to see this kind of effort put into n3 as a general
> logic expression system and superset of RDF that perhaps we can move
> towards once we have achieved mainstream with the core data expression
> in RDF. I'd like to see 5 or 6 alternative and interoperable n3
> implementations in use to iron out the problems, just like we have
> with RDF engines (I can name 10+ and know of no interop issues between
> them)

I like this solution.

There are a lot of good reasons for keeping rdf/xml as is.
For one many people use it. Secondly it does not have named graphs, which means 
that
at least people using it, must stick to saying what they know/believe, instead 
of trying to
say what they think other people know. This means there is a lot less ways for
people to go wrong.

But we could focus on N3 and standardise it as N4 perhaps. This would
give us a powerful notation for writing out rules, doing clever belief based 
reasoning, add methematical functions, ... which will be needed by any linked 
data application: those apps need to have rules such as "believe what Jane says 
about knitting but not about medicine".

As those advanced usages get to be tested we can then finally come back to 
rdf/xml
and other formats if needed and enhance them. I think doing this will help the
vendors start thinking about enhancing their rdf machinery making
it a lot more flexible over time. For some reason these vendors seem to 
have unnecessarily limited the functioning of their engines.

It is also a lot easier to teach something like N3. 

Henry


> Ian
> 




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

2010-07-02 Thread Ian Davis
On Fri, Jul 2, 2010 at 10:19 AM, Patrick Durusau  wrote:

> I make this point in another post this morning but is your argument that
> investment by vendors =
>

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

Ian
Ian



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

2010-07-02 Thread Patrick Durusau

Ian,

On 7/2/2010 3:39 AM, Ian Davis wrote:

On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes  wrote:
   

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

 

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

I would prefer to see this kind of effort put into n3 as a general
logic expression system and superset of RDF that perhaps we can move
towards once we have achieved mainstream with the core data expression
in RDF. I'd like to see 5 or 6 alternative and interoperable n3
implementations in use to iron out the problems, just like we have
with RDF engines (I can name 10+ and know of no interop issues between
them)

   
I make this point in another post this morning but is your argument that 
investment by vendors =


1) technology meets need perceived by users, and

2) technology meets the need in a way acceptable to users

??

What early majority? How long did it take HTML to take off? Or XML for 
that matter, at least in its simpler forms?


As I say in another post, I am not suggesting I have an alternative but 
am suggesting that we broaden the conversation to more than "we have 
invested so much so we have to be right" sort of reasoning.


Hope you are having a great day!

Patrick


--
Patrick Durusau
patr...@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau




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

2010-07-02 Thread Benjamin Nowack

On 01.07.2010 22:44:48, Pat Hayes wrote:
>Jeremy, your argument is perfectly sound from your company's POV, but
>not from a broader perspective. Of course, any change will incur costs

Well, I think the "broader perspective" that the RDF workshop
failed to consider is exactly companies' costs and spec
marketability. The message still sent out is a crazy (or
"visionary" ;) research community creating spec after spec, with
no stability in sight. And with the W3C process not really
encouraging the quick or full refactoring of existing specs (like
getting rid of once recommended features), each spec adds *new*
features and increases the overall complexity of identifying
market-ready Recs: RIF seems to be a replacement for OWL, but
OWL2 was only just Rec'd. Which should I implement? RDFa 1.1 and
SPARQL 1.1 both look like implementation nightmares to me. Current
RDF stores can't even be used for semantic feed readers because of
poor "ORDER BY DESC(?date)" implementations, but the group is
already working on query federation. RDFa is becoming the new
RSS 1.0, with each publisher triggering the development of
dedicated parsers (one for SearchMonkey data, one for RichSnippets,
one for Facebook's OGP, etc., but a single interoperable one? Very
hard work.) Something is wrong here. Featuritis is the reason for
the tiny number of complete toolkits. It's extremely frustrating
when you know in advance that you won't be able to pass the tests
*and* have your own (e.g. performance) needs covered. Why start at
all then?

The W3C groups still seem to believe that syntactic sugar is
harmless. We suffer from spec obesity, badly. If we really want to
improve RDF, then we should go, well, for a low-carb layer cake.
Or better, several new ones. One for each target audience. KR pros
probably need OWL 2.0 *and* RIF, others may already be amazed by
"scoped key-value storage with a universal API" (aka triples + SPARQL).
These groups are equally important, but have to be addressed
differently.

Our problem is not lack of features (native literal subjects? c'mon!).
It is identifying the individual user stories in our broad community
and marketing respective solution bundles. The RDFa and LOD folks
have demonstrated that this is possible. Similar success stories are
probably RIF for the business rules market, OWL for the DL/KR sector,
and many more. (Mine is agile, flexi-schema website development.)

RDF "Next Steps" should be all about scoped learning material and
deployment. There were several workshop submissions (e.g. by Jeremy,
Lee, and Richard) that mentioned this issue, but the workshop outcome
seems to be purely technical. Too bad.

Benji

--
Benjamin Nowack
http://bnode.org/
http://semsol.com/




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

2010-07-02 Thread Nathan

Nathan wrote:

Ian Davis wrote:

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

no further change for the rest of the world and for all future time. Who
knows what financial opportunities might become possible when this 
change is

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



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

I would prefer to see this kind of effort put into n3 as a general
logic expression system and superset of RDF that perhaps we can move
towards once we have achieved mainstream with the core data expression
in RDF. I'd like to see 5 or 6 alternative and interoperable n3
implementations in use to iron out the problems, just like we have
with RDF engines (I can name 10+ and know of no interop issues between
them)


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


(at RDF Semantic level..


my how this has came full circle,

Best,

Nathan








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

2010-07-02 Thread Nathan

Ian Davis wrote:

On Fri, Jul 2, 2010 at 4:44 AM, Pat Hayes  wrote:

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



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

I would prefer to see this kind of effort put into n3 as a general
logic expression system and superset of RDF that perhaps we can move
towards once we have achieved mainstream with the core data expression
in RDF. I'd like to see 5 or 6 alternative and interoperable n3
implementations in use to iron out the problems, just like we have
with RDF engines (I can name 10+ and know of no interop issues between
them)


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


my how this has came full circle,

Best,

Nathan



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

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

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

I would prefer to see this kind of effort put into n3 as a general
logic expression system and superset of RDF that perhaps we can move
towards once we have achieved mainstream with the core data expression
in RDF. I'd like to see 5 or 6 alternative and interoperable n3
implementations in use to iron out the problems, just like we have
with RDF engines (I can name 10+ and know of no interop issues between
them)

Ian



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

2010-07-01 Thread Pat Hayes


On Jul 2, 2010, at 12:29 AM, Paul Gearon wrote:


Hi Pat,

On Thu, Jul 1, 2010 at 9:52 PM, Pat Hayes  wrote:
Hey, guys. It is perfectly fine to use OWL properties in RDF. The  
RDF specs
actually encourage this kind of semantic borrowing, it was always  
part of

the RDF design to have this happen. So no need to have a version of
owl:sameAs in the RDFS namespace. Just use the OWL one.


Yes, I know that borrowing terms is allowed. Indeed, it gets used  
every day.


The thing is that we're talking about maybe cleaning RDF up a little.
(emphasis on the "maybe" - though that's starting to look more
likely). In this case, it makes sense to me that a term for equality
would make it's way into RDFS, simply because there are a lot of use
cases where people are sticking to just that namespace, with the
single exception of owl:sameAs. Also from an aesthetics point of view,
equality is such a common concept that I'm surprised it wasn't already
lower in the stack.


Point taken. I agree, except that I think equality is much trickier on  
the Web than we ever realized until recently.




Nothing in RDF *needs* to be changed. But if it does get updated, then
I think that it would be nice to clean things a little while all the
new features get added (such as named graphs).


Agree.

Pat



Regards,
Paul Gearon





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








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

2010-07-01 Thread Nathan

Paul Gearon wrote:

Hi Pat,

On Thu, Jul 1, 2010 at 9:52 PM, Pat Hayes  wrote:

Hey, guys. It is perfectly fine to use OWL properties in RDF. The RDF specs
actually encourage this kind of semantic borrowing, it was always part of
the RDF design to have this happen. So no need to have a version of
owl:sameAs in the RDFS namespace. Just use the OWL one.


fwiw, I was thinking more from a developer standpoint, hitting one 
simple spec doc and finding most of what they need to get modelling 
without being faced with OWL FULL and DL and the vast amounts of docs + 
reading. This is the main reason I personally mentioned :)



Yes, I know that borrowing terms is allowed. Indeed, it gets used every day.

The thing is that we're talking about maybe cleaning RDF up a little.
(emphasis on the "maybe" - though that's starting to look more
likely). In this case, it makes sense to me that a term for equality
would make it's way into RDFS, simply because there are a lot of use
cases where people are sticking to just that namespace, with the
single exception of owl:sameAs. Also from an aesthetics point of view,
equality is such a common concept that I'm surprised it wasn't already
lower in the stack.

Nothing in RDF *needs* to be changed. But if it does get updated, then
I think that it would be nice to clean things a little while all the
new features get added (such as named graphs).

Regards,
Paul Gearon







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

2010-07-01 Thread Paul Gearon
Hi Pat,

On Thu, Jul 1, 2010 at 9:52 PM, Pat Hayes  wrote:
> Hey, guys. It is perfectly fine to use OWL properties in RDF. The RDF specs
> actually encourage this kind of semantic borrowing, it was always part of
> the RDF design to have this happen. So no need to have a version of
> owl:sameAs in the RDFS namespace. Just use the OWL one.

Yes, I know that borrowing terms is allowed. Indeed, it gets used every day.

The thing is that we're talking about maybe cleaning RDF up a little.
(emphasis on the "maybe" - though that's starting to look more
likely). In this case, it makes sense to me that a term for equality
would make it's way into RDFS, simply because there are a lot of use
cases where people are sticking to just that namespace, with the
single exception of owl:sameAs. Also from an aesthetics point of view,
equality is such a common concept that I'm surprised it wasn't already
lower in the stack.

Nothing in RDF *needs* to be changed. But if it does get updated, then
I think that it would be nice to clean things a little while all the
new features get added (such as named graphs).

Regards,
Paul Gearon



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

2010-07-01 Thread Pat Hayes
Hey, guys. It is perfectly fine to use OWL properties in RDF. The RDF  
specs actually encourage this kind of semantic borrowing, it was  
always part of the RDF design to have this happen. So no need to have  
a version of owl:sameAs in the RDFS namespace. Just use the OWL one.


Pat


On Jul 1, 2010, at 4:54 PM, Paul Gearon wrote:


On Thu, Jul 1, 2010 at 1:18 PM, Nathan  wrote:


Something else that keeps coming up, a subset of owl always comes  
in to
conversations, obviously owl:sameAs - there was a proposal from one  
Jim
Hendler [1] at a RDF workshop thing to perhaps do something about  
moving

these up a level to RDFS.

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

Didn't seem to get much feedback or thoughts (afaik), but given the  
climate
perhaps it's worth giving some strong consideration to as a  
community.


(Or just doing because it's a bloody good idea & would remove OWL  
from

virtually every conversation we end up having).


I agree with this. In particular, I'd love to see an equivalent to
owl:sameAs in the rdfs namespace, probably with a more intuitive name,
like rdfs:equals. It would take OWL out of a lot of conversations.

There weren't any accepted proposals for working on RDFS at the
workshop, but that doesn't mean it can't still be done. However, it
would need a lot of public support if this were to be considered. If
people are interested, they should voice their opinions.

Regards,
Paul Gearon





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








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

2010-07-01 Thread Pat Hayes


On Jul 1, 2010, at 2:03 PM, Tim Finin wrote:


On 7/1/10 2:51 PM, Henry Story wrote:
> ...
So just as a matter of interest, imagine a new syntax came along  
that allowed literals in

subject position, could you not write a serialiser for it that turned
   "123" length 3 .
Into
 _:b owl:sameAs "123";
 length 3.
?
So that really you'd have to do no work at all?
Just wondering


Isn't owl:sameAs defined to be a relation between two
URI references?


In OWL-DL it is so restricted. Emphasis on the DL. So, don't use  
owl:sameAs. Use your own propietary sameAs; it needn't even be  
symmetric. We are after all taking RDF here, not OWL-DL. And in the  
case under discussion (keeping Jeremy from losing thousands of dollars  
or much restful sleep), nobody outside the company is ever going to  
see the strange sameAs triples which protect his archaic but expensive  
code from the wild syntactic deviance in the new RDF.


Pat


Even if not, it is symmetric and
would have the above imply {"123" owl:sameAs _:b .}




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








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

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


It is also important to distinguish changes which actually harm your  
code, and changes which simply make it less complete. Allowing literal  
subjects will not invalidate your engines in any way: it will simply  
mean that there will be some RDF out there which they may be unable to  
process, or which might require them to do some preprocessing (such as  
replacing

 :p :o .
with
_:x :p :o .
_:x :same  .
with a special company-specific :same property marker. For example.)  
But none of this *invalidates* your huge pile of expensive investment  
in code base; it merely makes it just a wee bit obsolete. But by the  
time this process is over, it will be obsolete anyway, I am sure,  
simply by virtue of being about four or five years older.


Best wishes

Pat


On Jul 1, 2010, at 10:38 AM, Jeremy Carroll wrote:



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


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


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


But if we make a change,  all of my code base will need to be  
checked for this issue.

This costs my company maybe $100K (very roughly)
No one has even showed me $1K of advantage for this change.

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

Jeremy






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








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

2010-07-01 Thread Kingsley Idehen

Toby Inkster wrote:

On Thu, 01 Jul 2010 13:05:54 -0400
Kingsley Idehen  wrote:

  

W3C only officially acknowledges RDF/XML as Markup Language for RDF
Data Model.



I hear this time and time again, but it is not true anymore.

XHTML+RDFa 1.0 became a W3C Recommendation in October 2008. It has the
same publication status as RDF/XML.
  


You know that and so do I. We aren't the audience with the understanding 
etc..

(And as it happens, XHTML+RDFa 1.0 is capable of representing a larger
subset of the RDF data model than RDF/XML is, as it uses CURIEs rather
than QNames. CURIEs are capable of expressing predicate URIs such as
 which cannot be expressed as QNames.)
  


I am sure you know you are preaching to a believer on this one :-)

My critical concern and gripe is that RDF/XML continues to be a source 
of confusion re. RDF and Linked Data.



Some interesting links from prior discussions about RDF/XML and RDF problem:

1. https://gist.github.com/221494/e19ca02a9b5a613705d9160ecb49784c67559898
2. http://bnode.org/media/2009/07/08/semantic_web_technology_stack.png 
-- great visualization for talking about RDF (its role is crystal clear 
with zero conflation or RDF/XML overhang ) .



--

Regards,

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

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









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

2010-07-01 Thread Toby Inkster
On Thu, 01 Jul 2010 13:05:54 -0400
Kingsley Idehen  wrote:

> W3C only officially acknowledges RDF/XML as Markup Language for RDF
> Data Model.

I hear this time and time again, but it is not true anymore.

XHTML+RDFa 1.0 became a W3C Recommendation in October 2008. It has the
same publication status as RDF/XML.

(And as it happens, XHTML+RDFa 1.0 is capable of representing a larger
subset of the RDF data model than RDF/XML is, as it uses CURIEs rather
than QNames. CURIEs are capable of expressing predicate URIs such as
 which cannot be expressed as QNames.)

-- 
Toby A Inkster






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

2010-07-01 Thread Kingsley Idehen

Dan Brickley wrote:

On Thu, Jul 1, 2010 at 11:35 PM, Kingsley Idehen  wrote:
  

The sequence went something like this.

TimBL Design Issues Note. and SPARQL emergence. Before that, RDF was
simply
in the dark ages.



It's only simple if you weren't there :)
  

You mean you didn't see me lurking in the dark? :-)

Humor aside, pre Linked Data meme, RDF just wasn't making any tangible
progress (adoption or comprehension wise) beyond the inner sanctums of the
Semantic Web community, you know what I mean when I say that, right?



And all I'm saying is that it took a lot of work from a lot of people
(most of whom are on these lists) to get to that stage where it was
capable of breaking out. The state of RDF deployment, tooling,
concepts, specs and community in 2006 was a significant improvement on
what we had in, say 1999. The Linked Data push was a breakthrough, but
it didn't happen in a vacuum or overnight; neither did SPARQL...
  


Dan,

Of course a lot of people have put a lot of effort into RDF. I don't 
think I am refuting or in anyway seeking to undermine that obvious fact.


When I express concerns about RDF  (model and representation conflation) 
it typically gets translated into: I don't like RDF or I have a problem 
with RDF.


When outline the path to a breakthrough it gets translated to: SPARQL 
and Linked Data dropping out of the sky etc..


IMHO. A lot of people who put a lot of hard work into RDF still don't 
seem to look back at why it took until 2006-2007 for an eventual 
breakthrough, seriously.


What is the unambiguous definition of RDF?

Which one of these definitions is gospel?

1. http://www.w3.org/TR/2004/REC-rdf-primer-20040210/ -- The Resource 
Description Framework (RDF) is a language for representing information 
about resources in the World Wide Web.


2. http://www.w3.org/RDF/ -- RDF is a standard model for data 
interchange on the Web.


#1 infers Markup
#2 infers Model

While in reality its supposed to be a framework for describing Things 
based on a ??? graph model.


I would really like us to collectively focus on not repeating mistakes 
from the past as we move forward. We've all put lots of energy, 
knowledge,  and hard cash into this journey.


Linked Data remains a pragmatic reflection of getting RDF distractions 
out of the way en route to effectively demonstrating vital evolution of 
the Web IMHO.


A green page may not maketh a standard but it darn well created kinetic 
energy from potential energy :-)





cheers,

Dan

  



--

Regards,

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

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









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

2010-07-01 Thread Paul Gearon
On Thu, Jul 1, 2010 at 1:18 PM, Nathan  wrote:


> Something else that keeps coming up, a subset of owl always comes in to
> conversations, obviously owl:sameAs - there was a proposal from one Jim
> Hendler [1] at a RDF workshop thing to perhaps do something about moving
> these up a level to RDFS.
>
> [1] http://www.w3.org/2009/12/rdf-ws/papers/ws31
>
> Didn't seem to get much feedback or thoughts (afaik), but given the climate
> perhaps it's worth giving some strong consideration to as a community.
>
> (Or just doing because it's a bloody good idea & would remove OWL from
> virtually every conversation we end up having).

I agree with this. In particular, I'd love to see an equivalent to
owl:sameAs in the rdfs namespace, probably with a more intuitive name,
like rdfs:equals. It would take OWL out of a lot of conversations.

There weren't any accepted proposals for working on RDFS at the
workshop, but that doesn't mean it can't still be done. However, it
would need a lot of public support if this were to be considered. If
people are interested, they should voice their opinions.

Regards,
Paul Gearon



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

2010-07-01 Thread Dan Brickley
On Thu, Jul 1, 2010 at 11:35 PM, Kingsley Idehen  wrote:
>>> The sequence went something like this.
>>>
>>> TimBL Design Issues Note. and SPARQL emergence. Before that, RDF was
>>> simply
>>> in the dark ages.
>>>
>>
>> It's only simple if you weren't there :)
>
> You mean you didn't see me lurking in the dark? :-)
>
> Humor aside, pre Linked Data meme, RDF just wasn't making any tangible
> progress (adoption or comprehension wise) beyond the inner sanctums of the
> Semantic Web community, you know what I mean when I say that, right?

And all I'm saying is that it took a lot of work from a lot of people
(most of whom are on these lists) to get to that stage where it was
capable of breaking out. The state of RDF deployment, tooling,
concepts, specs and community in 2006 was a significant improvement on
what we had in, say 1999. The Linked Data push was a breakthrough, but
it didn't happen in a vacuum or overnight; neither did SPARQL...

cheers,

Dan



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

2010-07-01 Thread Kingsley Idehen

Dan Brickley wrote:

On Thu, Jul 1, 2010 at 9:02 PM, Kingsley Idehen  wrote:

  

The sequence went something like this.

TimBL Design Issues Note. and SPARQL emergence. Before that, RDF was simply
in the dark ages.



It's only simple if you weren't there :)
  


You mean you didn't see me lurking in the dark? :-)

Humor aside, pre Linked Data meme, RDF just wasn't making any tangible 
progress (adoption or comprehension wise) beyond the inner sanctums of 
the Semantic Web community, you know what I mean when I say that, right?

cheers,

Dan

  



--

Regards,

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

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









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

2010-07-01 Thread Dan Brickley
On Thu, Jul 1, 2010 at 9:02 PM, Kingsley Idehen  wrote:

> The sequence went something like this.
>
> TimBL Design Issues Note. and SPARQL emergence. Before that, RDF was simply
> in the dark ages.

It's only simple if you weren't there :)

cheers,

Dan



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

2010-07-01 Thread Nathan

Antoine Zimmermann wrote:

Jeremy, et al.,


I think people are already showing the money but they do it 2 cents 
after 2 cents ;-)  Here is my little 2 cent contribution.


To start with, I am on the side of the people in favour of allowing 
literals in the subject position. I've read the discussion and pondered 
the arguments on each side carefully, but I'm still convinced that it 
would ultimately be the better option to allow them. I understand the 
concern of those who would have to rework their architectures. Yet I 
don't believe that the cost exceeds the benefits for those who are 
starting to implement and for future implementations and future 
developments of the standards.
As Sandro said, RIF is using triples with literals as subjects, as 
Robert Fuller said (in the LOD list), reasoners are internally inferring 
triples with literals in subject position, and other use cases (more or 
less convincing) have been proposed here. Why can't those inferences and 
facts be exposed and published in an RDF document?



Now I'd like to show some of the strange things that happen when you 
combine SPARQL with inference regimes, that are due to the inability to 
have literals (in the syntax) as subject.



Assume that you have the following data, harvested from the Web:

:www dc:creator "Tim Berners-Lee" .
:www dc:creator "Tim Berners-Lee"^^xsd:string .
:www dc:creator :timbl .
:timbl owl:sameAs "Tim Berners-Lee" .


Note that literals are commonly used with dc:creator so this example is 
fairly realistic.


Now, let us consider the following query:

SELECT ?x WHERE {
   ?x a rdfs:Resource .
}

under the RDFS-entailment regime, this would provide the following answer:
?x --> :timbl

Now, the following query:

SELECT ?y WHERE {
   ?y a rdfs:Literal .
}

would provide no answer (under RDFS-entailment) and:

SELECT ?z WHERE {
   ?z a xsd:string .
}

would provide no answer (under RDFS-entailment).

Now, imagine a SPARQL engine with an "RDFS+sameAs"-entailment regime. 
The three queries above would give the following results:


?x --> :timbl   // first query
?y --> :timbl   // second query (I can infer that :timbl is a rdfs:Literal)
and the last would give nothing.

Now consider the query:

SELECT ?t WHERE {
?u a rdfs:Literal .
?u owl:sameAs ?t .
}

It would give:

?t --> "Tim Berners-Lee"
?t --> :timbl

However, the query:

SELECT ?u WHERE {
?u a rdfs:Literal .
?u owl:sameAs ?t .
}

would give ?u -> :timbl .


This is very weird for me.



Something else that keeps coming up, a subset of owl always comes in to 
conversations, obviously owl:sameAs - there was a proposal from one Jim 
Hendler [1] at a RDF workshop thing to perhaps do something about moving 
these up a level to RDFS.


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

Didn't seem to get much feedback or thoughts (afaik), but given the 
climate perhaps it's worth giving some strong consideration to as a 
community.


(Or just doing because it's a bloody good idea & would remove OWL from 
virtually every conversation we end up having).


ps: my only comment/addition to this was to add in Restriction's too

Best,

Nathan

forking again, sorry!



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

2010-07-01 Thread Antoine Zimmermann

Jeremy, et al.,


I think people are already showing the money but they do it 2 cents 
after 2 cents ;-)  Here is my little 2 cent contribution.


To start with, I am on the side of the people in favour of allowing 
literals in the subject position. I've read the discussion and pondered 
the arguments on each side carefully, but I'm still convinced that it 
would ultimately be the better option to allow them. I understand the 
concern of those who would have to rework their architectures. Yet I 
don't believe that the cost exceeds the benefits for those who are 
starting to implement and for future implementations and future 
developments of the standards.
As Sandro said, RIF is using triples with literals as subjects, as 
Robert Fuller said (in the LOD list), reasoners are internally inferring 
triples with literals in subject position, and other use cases (more or 
less convincing) have been proposed here. Why can't those inferences and 
facts be exposed and published in an RDF document?



Now I'd like to show some of the strange things that happen when you 
combine SPARQL with inference regimes, that are due to the inability to 
have literals (in the syntax) as subject.



Assume that you have the following data, harvested from the Web:

:www dc:creator "Tim Berners-Lee" .
:www dc:creator "Tim Berners-Lee"^^xsd:string .
:www dc:creator :timbl .
:timbl owl:sameAs "Tim Berners-Lee" .


Note that literals are commonly used with dc:creator so this example is 
fairly realistic.


Now, let us consider the following query:

SELECT ?x WHERE {
   ?x a rdfs:Resource .
}

under the RDFS-entailment regime, this would provide the following answer:
?x --> :timbl

Now, the following query:

SELECT ?y WHERE {
   ?y a rdfs:Literal .
}

would provide no answer (under RDFS-entailment) and:

SELECT ?z WHERE {
   ?z a xsd:string .
}

would provide no answer (under RDFS-entailment).

Now, imagine a SPARQL engine with an "RDFS+sameAs"-entailment regime. 
The three queries above would give the following results:


?x --> :timbl   // first query
?y --> :timbl   // second query (I can infer that :timbl is a rdfs:Literal)
and the last would give nothing.

Now consider the query:

SELECT ?t WHERE {
?u a rdfs:Literal .
?u owl:sameAs ?t .
}

It would give:

?t --> "Tim Berners-Lee"
?t --> :timbl

However, the query:

SELECT ?u WHERE {
?u a rdfs:Literal .
?u owl:sameAs ?t .
}

would give ?u -> :timbl .


This is very weird for me.



Anyway, I do not expect such a change in the near future and the spec 
are like they are at the moment, so I live with it.





Regards,
--
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: Show me the money - (was Subjects as Literals)

2010-07-01 Thread Antoine Zimmermann

Dear Tim,


Le 01/07/2010 20:03, Tim Finin a écrit :

On 7/1/10 2:51 PM, Henry Story wrote:
 > ...

So just as a matter of interest, imagine a new syntax came along that
allowed literals in
subject position, could you not write a serialiser for it that turned
"123" length 3 .
Into
_:b owl:sameAs "123";
length 3.
?
So that really you'd have to do no work at all?
Just wondering


Isn't owl:sameAs defined to be a relation between two
URI references?


Not exactly. OWL DL defines this restriction on owl:sameAs, but 
owl:sameAs is not itself defined like this. Plus, OWL DL is 
syntactically a restriction of OWL (Full) (that is, a syntactic 
restriction of RDF). The current discussion is about RDF, so I don't see 
any reason to mention the specificities of OWL DL here. OWL DL, in any 
case, would forbid literals in subject position.


 Even if not, it is symmetric and

would have the above imply {"123" owl:sameAs _:b .}


No it does not imply this because "this" is not in the language. The 
language RDF tells you that triples (the formulas in that language) have 
no literals as subjects. In any logical formalism, you cannot infer 
things that are not in the language.


This is actually what is strange about not allowing literals in the 
subject position: you cannot say things like:


"123" owl:sameAs "123"

and therefore, you cannot infer it. If, for any reason, you want to 
infer this, it means that you are in need of a modification of the RDF 
language which allows literal in the subject position.


Yet, to make things more confusing, the interpretation of the predicate 
owl:sameAs, under the OWL semantics, is reflexive and symmetric.


I am preparing an email about the weird consequences of excluding 
literals in subject position.



Regards,
--
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: Show me the money - (was Subjects as Literals)

2010-07-01 Thread Jeremy Carroll

 On 7/1/2010 11:51 AM, Henry Story wrote:

So just as a matter of interest, imagine a new syntax came along that allowed 
literals in
subject position, could you not write a serialiser for it that turned

"123" length 3 .

Into

_:b owl:sameAs "123";
length 3.

?



I couldn't because chunks of my code are low level utils that are 
expected to, for example, write out what they read in, so I can't make 
transforms in the middle.


Jeremy




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

2010-07-01 Thread Nathan

Jiří Procházka wrote:

On 07/01/2010 09:11 PM, Henry Story wrote:

On 1 Jul 2010, at 21:03, Tim Finin wrote:

On 7/1/10 2:51 PM, Henry Story wrote:

...
So just as a matter of interest, imagine a new syntax came along that allowed 
literals in
subject position, could you not write a serialiser for it that turned
   "123" length 3 .
Into
 _:b owl:sameAs "123";
 length 3.
?
So that really you'd have to do no work at all?
Just wondering

Isn't owl:sameAs defined to be a relation between two
URI references?  

Not sure.


It is, this won't work under OWL DL... In OWL Full if I think it will.
I asked about this recently on this list...


It's fine in RDF(S) and OWL Full, not OWL DL where it relates two object 
property's


(thanks to Michael Schneider for clarifying that to me many times as i 
kept making the same mistake over and over ;)!


Best,

Nathan



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

2010-07-01 Thread Jiří Procházka
On 07/01/2010 09:11 PM, Henry Story wrote:
> 
> Social Web Architect
> http://bblfish.net/
> 
> On 1 Jul 2010, at 21:03, Tim Finin wrote:
> 
>> On 7/1/10 2:51 PM, Henry Story wrote:
>>> ...
>>> So just as a matter of interest, imagine a new syntax came along that 
>>> allowed literals in
>>> subject position, could you not write a serialiser for it that turned
>>>"123" length 3 .
>>> Into
>>>  _:b owl:sameAs "123";
>>>  length 3.
>>> ?
>>> So that really you'd have to do no work at all?
>>> Just wondering
>>
>> Isn't owl:sameAs defined to be a relation between two
>> URI references?  
> 
> Not sure.

It is, this won't work under OWL DL... In OWL Full if I think it will.
I asked about this recently on this list...

> In any case I suppose it would be simple to crete such an identity relation. 
> 
>> Even if not, it is symmetric and
>> would have the above imply {"123" owl:sameAs _:b .}
> 
> It does indeed imply that, though you can't write it out like that 
> in most serialisations, other than N3.
> 
> And being able to write it out, makes it easy to explain what symmetry means.
> 
> I think people keep confusing syntax and semantics for some reason, even on
> the semantic web.
> 
> Henry



signature.asc
Description: OpenPGP digital signature


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

2010-07-01 Thread Henry Story

Social Web Architect
http://bblfish.net/

On 1 Jul 2010, at 21:03, Tim Finin wrote:

> On 7/1/10 2:51 PM, Henry Story wrote:
> > ...
>> So just as a matter of interest, imagine a new syntax came along that 
>> allowed literals in
>> subject position, could you not write a serialiser for it that turned
>>"123" length 3 .
>> Into
>>  _:b owl:sameAs "123";
>>  length 3.
>> ?
>> So that really you'd have to do no work at all?
>> Just wondering
> 
> Isn't owl:sameAs defined to be a relation between two
> URI references?  

Not sure.

In any case I suppose it would be simple to crete such an identity relation. 

> Even if not, it is symmetric and
> would have the above imply {"123" owl:sameAs _:b .}

It does indeed imply that, though you can't write it out like that 
in most serialisations, other than N3.

And being able to write it out, makes it easy to explain what symmetry means.

I think people keep confusing syntax and semantics for some reason, even on
the semantic web.

Henry


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

2010-07-01 Thread Kingsley Idehen

Bernard Vatant wrote:

Hi Dan, Kingsley

Happy to see you expose clearly those things that have been also in 
the corner of my mind since Kingsley started to hammer the EAV drum a 
while ago.


I've been also in training and introduction to RDF insisted on the 
fact that RDF was somehow just an avatar of the old paradigm EAV or 
however you name it, and I think it's a good way to introduce it, and 
keep all the gory aspects for later on, and in particular the 
syntactic mess (or should I say, joyful diversity).


But I follow Dan on the fact that the Linked Data cloud has flourished 
on top of RDF-XML, at least as exchange and publication format. And I 
must say that what I see daily with data providers and consumers 
around Mondeca applications is data coming in and out in RDF-XML, for 
better and worse indeed. And for what I see, it's easier to have data 
providers now familiar with XML understand RDF through RDF-XML, by 
making XML-friendly RDF. RDF-XML has not to be ugly and unreadable and 
untractable, even if some tools have never care about that (no names).
And as the grease-monkey in charge of migrating miscellaneous data to 
feed the semantic engine, I'm still quite happy with the current 
CSV-to-plain-XML-to-RDF-XML (via XSLT, yes) route.


And I will give you the short feedback of our CTO in Mondeca after 
reading the output of RDFNext workshop. "Well, no canonical XML 
syntax?". Believe me, all the rest he did not even care mentioning. 
Don't want to add to the "I wish I'd been there" but I would myself 
exchange every other evolution and future work for a canonical RDF-XML 
syntax. I know, I know, don't tell me.


Bernard


Bernard,

I hope my last response (with some corrections) makes my point clearer 
re. booststrap i.e., broad adoption of Linked Data as expressed via the 
evolution of the LOD cloud pictorial :-)


Ironically, I criticize RDF/XML a lot, but out sponger cartridges (basic 
and meta)  are major exploiters of RDF/XML re. what I see as its best 
use: machine level transformations.


Kingsley






2010/7/1 Dan Brickley mailto:dan...@danbri.org>>

(cc: list trimmed to LOD list.)

On Thu, Jul 1, 2010 at 7:05 PM, Kingsley Idehen
mailto:kide...@openlinksw.com>> wrote:

> Cut long story short.

[-cut-]

> We have an EAV graph model, URIs, triples and a variety of data
> representation mechanisms. N3 is one of those, and its basically the
> foundation that bootstrapped the House of HTTP based Linked Data.

I have trouble believing that last point, so hopefully I am
misunderstanding your point.

Linked data in the public Web was bootstrapped using standard RDF,
serialized primarily in RDF/XML, and initially deployed mostly by
virtue of people enthusiastically publishing 'FOAF files' in the
(RDF)Web. These files, for better or worse, were overwhelmingly in
RDF/XML.

When TimBL wrote http://www.w3.org/DesignIssues/LinkedData.html in
2006 he used what is retrospectively known as Notation 2, not its
successor Notation 3.

"Notation2"[*] was an unstriped XML syntax ( see original in

http://web.archive.org/web/20061115043657/http://www.w3.org/DesignIssues/LinkedData.html
). That DesignIssues note was largely a response to the FOAF
deployment.
"This linking system was very successful, forming a  growing social
network, and dominating, in 2006, the linked data available on the
web."

The LinkedData design note argued that (post RDFCore cleanup and
http-range discussions) we could now use URIs for non-Web things, and
that this would be easier than dealing with bNode-heavy data. Much of
the subsequent successes come from following that advice. Perhaps N3
played an educational role in showing that RDF had other
representations; but by then, SPARQL, NTriples etc were also around.
As was RDFa, http://xtech06.usefulinc.com/schedule/paper/58  ...

I have a hard time seeing N3 as the foundation that bootstrapped
things. Most of the substantial linked RDF in Web by 2006 was written
in RDF/XML, and by then the substantive issues around linking,
reference, aggregation, identification and linking etc were pretty
well understood. I don't dislike N3; it was a good technology testbed
and gave us the foundation for SPARQL's syntax, and for the Turtle
subset. But it's role outside our immediate community has been pretty
limited in my experience.

cheers,

Dan

[*] http://www.w3.org/DesignIssues/Syntax.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




--

Regards,

Kingsley Idehen	  
President 

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

2010-07-01 Thread Tim Finin

On 7/1/10 2:51 PM, Henry Story wrote:
> ...

So just as a matter of interest, imagine a new syntax came along that allowed 
literals in
subject position, could you not write a serialiser for it that turned
"123" length 3 .
Into
  _:b owl:sameAs "123";
  length 3.
?
So that really you'd have to do no work at all?
Just wondering


Isn't owl:sameAs defined to be a relation between two
URI references?  Even if not, it is symmetric and
would have the above imply {"123" owl:sameAs _:b .}



smime.p7s
Description: S/MIME Cryptographic Signature


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

2010-07-01 Thread Kingsley Idehen

Dan Brickley wrote:

(cc: list trimmed to LOD list.)

On Thu, Jul 1, 2010 at 7:05 PM, Kingsley Idehen  wrote:

  

Cut long story short.



[-cut-]

  

We have an EAV graph model, URIs, triples and a variety of data
representation mechanisms. N3 is one of those, and its basically the
foundation that bootstrapped the House of HTTP based Linked Data.



I have trouble believing that last point, so hopefully I am
misunderstanding your point.

  
I am basically saying: N3 representation of graphs lead to the Linked 
Data explosion.

Linked data in the public Web was bootstrapped using standard RDF,
serialized primarily in RDF/XML, and initially deployed mostly by
virtue of people enthusiastically publishing 'FOAF files' in the
(RDF)Web. These files, for better or worse, were overwhelmingly in
RDF/XML.
  


Not in my experience.

**critical correction: I should have stated N-Triples instead of N3 re. 
base representation format at the foundation re. DBpedia **



The sequence went something like this.

TimBL Design Issues Note. and SPARQL emergence. Before that, RDF was 
simply in the dark ages.


DBpedia project (which produced and still produces N-Triples dumps).

Cool URIs and Linked Data Deployment/Pubishin guides that added initial 
incorporation of HTML descriptor pages into the mix while relegating 
RDF/XM to a negotiable representation option.


Basically, without DBpedia there wouldn't be today's burgeoning Web of 
Linked Data (what the world has come to sorta understand and started 
using across many frontiers).



IMHO. As I see it, RDF/XML is a course/blessing. Without RDF/XML 
sponging (so called "rdfization")  wouldn't have been possible on the 
scale we've achieve, many transformations would become more painful 
etc.. (Blessing side). On the other hand putting RDF/XML in front of 
people esp., those outside the core semweb community that assume RDF/XML 
== RDF (broader framework comprised of markup and data model) when 
talking about Graph Models is an unfortunate curse.

When TimBL wrote http://www.w3.org/DesignIssues/LinkedData.html in
2006 he used what is retrospectively known as Notation 2, not its
successor Notation 3.

"Notation2"[*] was an unstriped XML syntax ( see original in
http://web.archive.org/web/20061115043657/http://www.w3.org/DesignIssues/LinkedData.html
). That DesignIssues note was largely a response to the FOAF
deployment.
"This linking system was very successful, forming a  growing social
network, and dominating, in 2006, the linked data available on the
web."

The LinkedData design note argued that (post RDFCore cleanup and
http-range discussions) we could now use URIs for non-Web things, and
that this would be easier than dealing with bNode-heavy data. Much of
the subsequent successes come from following that advice. Perhaps N3
played an educational role in showing that RDF had other
representations; but by then, SPARQL, NTriples etc were also around.
As was RDFa, http://xtech06.usefulinc.com/schedule/paper/58  ...
  

Education leads to boostrap. N3 and Turtle are very good in this regard.

Seeing the Triple is the key to comprehending what this whole thing is 
about. I am sure my first few comments on SWEO echoed this fundamental 
sentiment a few years back.


RDF/XML has always made the triple difficult to discern via human eyes 
(esp. the RDF newbie variety). 

Making HTML based presentations (a Chris Bizer & Richard Cyganiak 
obsession at the time) of RDF based resource descriptions, as 
exemplified by DBpedia is how the Web of Linked Data reached its bootstrap.


RDF/XML relegation to machine/program usage (e.g. the stuff we did/do 
with our sponger cartridges) was crucial.



I have a hard time seeing N3 as the foundation that bootstrapped
things. Most of the substantial linked RDF in Web by 2006 was written
in RDF/XML, and by then the substantive issues around linking,
reference, aggregation, identification and linking etc were pretty
well understood. I don't dislike N3; it was a good technology testbed
and gave us the foundation for SPARQL's syntax, and for the Turtle
subset. But it's role outside our immediate community has been pretty
limited in my experience.
  


To be more precise, my view is that the Linked Data bootstrap occurred 
modulo RDF/XML at the front door :-)


Ironically, HTML (those green DBpedia pages) played the most important 
role of all. It allowed people to understand Linked Data via 
conventional Web usage patterns i.e. put a link in the address bar and 
then have something presented to you that made sense.


RDFa impact albeit very significant is a very recent occurrence in the 
grand scheme of things re. Linked Data bootstrap (left most segment of 
the adoption curve). Of course, RDFa is certainly vital to crossing 
current and future adoption chasms as we continue to move from left to 
right along the tech adoption curve.



cheers,

Dan

[*] http://www.w3.org/DesignIssues/Syntax.html

  



--

Regards,

Kingsley Idehen	  

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

2010-07-01 Thread Henry Story

On 1 Jul 2010, at 20:47, Jeremy Carroll wrote:

> 
>> On 1 Jul 2010, at 17:38, Jeremy Carroll wrote:
>> 
>>> 
>>> 
>>> I have loads and loads of code, both open source and commercial that 
>>> assumes throughout that a node in a subject position is not a literal, and 
>>> a node in a predicate position is a URI node.
> On 7/1/2010 8:46 AM, Henry Story wrote:
>> but is that really correct? Because bnodes can be names for literals, and so 
>> you really do have
>> literals in subject positions No?
> It is really correct that I have loads and loads of such code.
> 
> This code conforms with the RDF Concepts and Abstract Syntax Recommendation 
> 2004

So just as a matter of interest, imagine a new syntax came along that allowed 
literals in
subject position, could you not write a serialiser for it that turned 

"123" length 3 .

Into 

_:b owl:sameAs "123";
   length 3. 

? 

So that really you'd have to do no work at all?

Just wondering

Henry

> 
> Jeremy
> 




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

2010-07-01 Thread Jeremy Carroll



On 1 Jul 2010, at 17:38, Jeremy Carroll wrote:




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

On 7/1/2010 8:46 AM, Henry Story wrote:

but is that really correct? Because bnodes can be names for literals, and so 
you really do have
literals in subject positions No?

It is really correct that I have loads and loads of such code.

This code conforms with the RDF Concepts and Abstract Syntax 
Recommendation 2004


Jeremy



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

2010-07-01 Thread Bernard Vatant
Hi Dan, Kingsley

Happy to see you expose clearly those things that have been also in the
corner of my mind since Kingsley started to hammer the EAV drum a while ago.

I've been also in training and introduction to RDF insisted on the fact that
RDF was somehow just an avatar of the old paradigm EAV or however you name
it, and I think it's a good way to introduce it, and keep all the gory
aspects for later on, and in particular the syntactic mess (or should I say,
joyful diversity).

But I follow Dan on the fact that the Linked Data cloud has flourished on
top of RDF-XML, at least as exchange and publication format. And I must say
that what I see daily with data providers and consumers around Mondeca
applications is data coming in and out in RDF-XML, for better and worse
indeed. And for what I see, it's easier to have data providers now familiar
with XML understand RDF through RDF-XML, by making XML-friendly RDF. RDF-XML
has not to be ugly and unreadable and untractable, even if some tools have
never care about that (no names).
And as the grease-monkey in charge of migrating miscellaneous data to feed
the semantic engine, I'm still quite happy with the current
CSV-to-plain-XML-to-RDF-XML (via XSLT, yes) route.

And I will give you the short feedback of our CTO in Mondeca after reading
the output of RDFNext workshop. "Well, no canonical XML syntax?". Believe
me, all the rest he did not even care mentioning. Don't want to add to the
"I wish I'd been there" but I would myself exchange every other evolution
and future work for a canonical RDF-XML syntax. I know, I know, don't tell
me.

Bernard



2010/7/1 Dan Brickley 

> (cc: list trimmed to LOD list.)
>
> On Thu, Jul 1, 2010 at 7:05 PM, Kingsley Idehen 
> wrote:
>
> > Cut long story short.
>
> [-cut-]
>
> > We have an EAV graph model, URIs, triples and a variety of data
> > representation mechanisms. N3 is one of those, and its basically the
> > foundation that bootstrapped the House of HTTP based Linked Data.
>
> I have trouble believing that last point, so hopefully I am
> misunderstanding your point.
>
> Linked data in the public Web was bootstrapped using standard RDF,
> serialized primarily in RDF/XML, and initially deployed mostly by
> virtue of people enthusiastically publishing 'FOAF files' in the
> (RDF)Web. These files, for better or worse, were overwhelmingly in
> RDF/XML.
>
> When TimBL wrote http://www.w3.org/DesignIssues/LinkedData.html in
> 2006 he used what is retrospectively known as Notation 2, not its
> successor Notation 3.
>
> "Notation2"[*] was an unstriped XML syntax ( see original in
>
> http://web.archive.org/web/20061115043657/http://www.w3.org/DesignIssues/LinkedData.html
> ). That DesignIssues note was largely a response to the FOAF
> deployment.
> "This linking system was very successful, forming a  growing social
> network, and dominating, in 2006, the linked data available on the
> web."
>
> The LinkedData design note argued that (post RDFCore cleanup and
> http-range discussions) we could now use URIs for non-Web things, and
> that this would be easier than dealing with bNode-heavy data. Much of
> the subsequent successes come from following that advice. Perhaps N3
> played an educational role in showing that RDF had other
> representations; but by then, SPARQL, NTriples etc were also around.
> As was RDFa, http://xtech06.usefulinc.com/schedule/paper/58  ...
>
> I have a hard time seeing N3 as the foundation that bootstrapped
> things. Most of the substantial linked RDF in Web by 2006 was written
> in RDF/XML, and by then the substantive issues around linking,
> reference, aggregation, identification and linking etc were pretty
> well understood. I don't dislike N3; it was a good technology testbed
> and gave us the foundation for SPARQL's syntax, and for the Turtle
> subset. But it's role outside our immediate community has been pretty
> limited in my experience.
>
> cheers,
>
> Dan
>
> [*] http://www.w3.org/DesignIssues/Syntax.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: Show me the money - (was Subjects as Literals)

2010-07-01 Thread Jeremy Carroll

 On 7/1/2010 10:18 AM, Yves Raimond wrote:


Or, an even simpler use-case: storing metaphones for strings in a 
triple store.





OK - and why are these use cases not reasonably easily addressable using 
the N-ary predicate design pattern with a two place ltieral predicate i.e.


instead of

Lit1 p1 nonLit

use

nonLit p1 Lit1

instead of
Lit1 p lit2

use

_ p1 Lit1
_ p2 Lit2

===

Not quite the same, but it will work - and save me a large amount of 
really very boring work


Jeremy




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

2010-07-01 Thread Dan Brickley
(cc: list trimmed to LOD list.)

On Thu, Jul 1, 2010 at 7:05 PM, Kingsley Idehen  wrote:

> Cut long story short.

[-cut-]

> We have an EAV graph model, URIs, triples and a variety of data
> representation mechanisms. N3 is one of those, and its basically the
> foundation that bootstrapped the House of HTTP based Linked Data.

I have trouble believing that last point, so hopefully I am
misunderstanding your point.

Linked data in the public Web was bootstrapped using standard RDF,
serialized primarily in RDF/XML, and initially deployed mostly by
virtue of people enthusiastically publishing 'FOAF files' in the
(RDF)Web. These files, for better or worse, were overwhelmingly in
RDF/XML.

When TimBL wrote http://www.w3.org/DesignIssues/LinkedData.html in
2006 he used what is retrospectively known as Notation 2, not its
successor Notation 3.

"Notation2"[*] was an unstriped XML syntax ( see original in
http://web.archive.org/web/20061115043657/http://www.w3.org/DesignIssues/LinkedData.html
). That DesignIssues note was largely a response to the FOAF
deployment.
"This linking system was very successful, forming a  growing social
network, and dominating, in 2006, the linked data available on the
web."

The LinkedData design note argued that (post RDFCore cleanup and
http-range discussions) we could now use URIs for non-Web things, and
that this would be easier than dealing with bNode-heavy data. Much of
the subsequent successes come from following that advice. Perhaps N3
played an educational role in showing that RDF had other
representations; but by then, SPARQL, NTriples etc were also around.
As was RDFa, http://xtech06.usefulinc.com/schedule/paper/58  ...

I have a hard time seeing N3 as the foundation that bootstrapped
things. Most of the substantial linked RDF in Web by 2006 was written
in RDF/XML, and by then the substantive issues around linking,
reference, aggregation, identification and linking etc were pretty
well understood. I don't dislike N3; it was a good technology testbed
and gave us the foundation for SPARQL's syntax, and for the Turtle
subset. But it's role outside our immediate community has been pretty
limited in my experience.

cheers,

Dan

[*] http://www.w3.org/DesignIssues/Syntax.html



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

2010-07-01 Thread Yves Raimond
Or, an even simpler use-case: storing metaphones for strings in a triple
store.

y

On 1 Jul 2010 18:15, "Yves Raimond"  wrote:

Hello Jeremy!

One example on the top of my head. You have a 'magic predicate' such as
Virtuoso bif:contains, but slightly more expansive than that (a large index
lookup, a difficult mathematical computation or fuzzy literal search, etc).
If you were able to store the result in RDF once that magic predicate had
been triggered once, you would just directly match against the cached
version in further queries. Hence, processing time-- and $++ :)

Cheers,
y

>
> On 1 Jul 2010 16:37, "Jeremy Carroll"  wrote:
>
>
> I am still not heari...


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

2010-07-01 Thread Yves Raimond
Hello Jeremy!

One example on the top of my head. You have a 'magic predicate' such as
Virtuoso bif:contains, but slightly more expansive than that (a large index
lookup, a difficult mathematical computation or fuzzy literal search, etc).
If you were able to store the result in RDF once that magic predicate had
been triggered once, you would just directly match against the cached
version in further queries. Hence, processing time-- and $++ :)

Cheers,
y

On 1 Jul 2010 16:37, "Jeremy Carroll"  wrote:


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

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

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

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

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

Jeremy


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

2010-07-01 Thread Kingsley Idehen

Nathan wrote:

Dan, Jeremy, Pat, Henry, Michael, Kinglsey, Ivan, ack.. everyone,

Part of me feels like I should apologise for bringing this to the 
mailing list (even though it was inevitable) - this is all getting out 
of scope and the last thing we need is one of the most critical 
communities in what's a mini revolution to be split over such matters.


Valid arguments from all sides, technical and not - but things are 
really getting conflated here, at least from what I originally 
intended to put forward (probably past that and insignificant now).


I respect that everybody has made large investments, time, money, 
data, deployment, training and so forth; but really, non of that need 
be wasted and nobody need change anything that has any impact on any 
investments thus far.


My (personal) concern is really on the 10 year timeline (a bit shorter 
to be honest ;), there are limitations and things in RDF that do, 
100%, prevent the web of data as a whole from moving forwards - 
however, nobody has to scrap anything.


Simply, define a non serialization specific model that caters for N3 
and RDF - then let each standard or serialization specify what it 
implements/supports - the point here, and I stress, isn't to break 
anything, but to open it up to innovation and allow the next decades 
worth of hacking to get going


So RDF/XML is perhaps broken technically and doesn't support all these 
things, who cares? it obviously works just fine for a deployment of 
several billion triples, why change it? why not define it as a subset 
of some core model? - I can only see one reason not to, and I hate to 
say it, but some kind of pride that the work done thus far and 
commonly adopted *must* be seen to be 'perfect' - please, don't take 
that as any insult, as none is intended.


There are clearly very strong opinions on both sides, and very valid 
reasons too - there's an easy solution that would keep everybody happy 
and allow all to get on being productive and innovative - why not 
enable this?


In all honesty, if this doesn't happen, I personally will have no 
choice but to move to N3 for the bulk of things, and hope for other 
serializations of N3 to come along - I'd do that today, but you see 
I'm a huge linked data proponent and see almost unquantifiable gains 
from adopting linked data - but if what I do to get a full working 
model of the web of data doesn't qualify as valid RDF at some level 
and you all can't utilize it, then it's a wasted effort and a road to 
no where - this, is the real issue, and many others have hit it, and 
will hit it again and again as time moves on.


Please, do consider, nobody need loose anything here

Best,

Nathan

- :(

Jeremy Carroll wrote:


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


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


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


But if we make a change,  all of my code base will need to be checked 
for this issue.

This costs my company maybe $100K (very roughly)
No one has even showed me $1K of advantage for this change.

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

Jeremy









Cut long story short.

RDF/XML != RDF.

Trouble is this though:

World sees RDF/XML == RDF. They don't see RDF Data Model aspect.

W3C only officially acknowledges RDF/XML as Markup Language for RDF Data 
Model.


Even worse, RDF (perceived to be == RDF/XML) is now tagged as mandatory 
for Linked Data, which is simply not so at all.


We have an EAV model, URIs, quads (or triples) and a variety of data 
representation mechanisms. N3 is one of those, and its basically the 
foundation that bootstrapped the House of HTTP based Linked Data.


RDF modulo Linked Data has nothing to show bar the kind to discussion 
thread you might have inadvertently triggered. Which is why I find RDF 
and Linked Data conflation an unfortunate attempt to force RDF (and all 
its troubles) on the truly useful outputs from the Semantic Web Project.


--

Regards,

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

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









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

2010-07-01 Thread Kingsley Idehen

Nathan wrote:

Dan, Jeremy, Pat, Henry, Michael, Kinglsey, Ivan, ack.. everyone,

Part of me feels like I should apologise for bringing this to the 
mailing list (even though it was inevitable) - this is all getting out 
of scope and the last thing we need is one of the most critical 
communities in what's a mini revolution to be split over such matters.


Valid arguments from all sides, technical and not - but things are 
really getting conflated here, at least from what I originally 
intended to put forward (probably past that and insignificant now).


I respect that everybody has made large investments, time, money, 
data, deployment, training and so forth; but really, non of that need 
be wasted and nobody need change anything that has any impact on any 
investments thus far.


My (personal) concern is really on the 10 year timeline (a bit shorter 
to be honest ;), there are limitations and things in RDF that do, 
100%, prevent the web of data as a whole from moving forwards - 
however, nobody has to scrap anything.


Simply, define a non serialization specific model that caters for N3 
and RDF - then let each standard or serialization specify what it 
implements/supports - the point here, and I stress, isn't to break 
anything, but to open it up to innovation and allow the next decades 
worth of hacking to get going


So RDF/XML is perhaps broken technically and doesn't support all these 
things, who cares? it obviously works just fine for a deployment of 
several billion triples, why change it? why not define it as a subset 
of some core model? - I can only see one reason not to, and I hate to 
say it, but some kind of pride that the work done thus far and 
commonly adopted *must* be seen to be 'perfect' - please, don't take 
that as any insult, as none is intended.


There are clearly very strong opinions on both sides, and very valid 
reasons too - there's an easy solution that would keep everybody happy 
and allow all to get on being productive and innovative - why not 
enable this?


In all honesty, if this doesn't happen, I personally will have no 
choice but to move to N3 for the bulk of things, and hope for other 
serializations of N3 to come along - I'd do that today, but you see 
I'm a huge linked data proponent and see almost unquantifiable gains 
from adopting linked data - but if what I do to get a full working 
model of the web of data doesn't qualify as valid RDF at some level 
and you all can't utilize it, then it's a wasted effort and a road to 
no where - this, is the real issue, and many others have hit it, and 
will hit it again and again as time moves on.


Please, do consider, nobody need loose anything here

Best,

Nathan

- :(

Jeremy Carroll wrote:


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


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


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


But if we make a change,  all of my code base will need to be checked 
for this issue.

This costs my company maybe $100K (very roughly)
No one has even showed me $1K of advantage for this change.

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

Jeremy







Nathan,

Cut long story short.

RDF/XML != RDF.

Trouble is this though:

World perceives:  RDF/XML == RDF. They don't see RDF Data Model aspect, 
at all.


W3C only officially acknowledges RDF/XML as Markup Language for RDF Data 
Model.


Even worse, RDF (generally perceived to be == RDF/XML) is now tagged as 
mandatory for Linked Data, which is simply not so at all.


We have an EAV graph model, URIs, triples and a variety of data 
representation mechanisms. N3 is one of those, and its basically the 
foundation that bootstrapped the House of HTTP based Linked Data.


RDF modulo Linked Data has nothing to show bar the kind to discussion 
thread you might have inadvertently triggered on the LOD and Semweb 
mailing lists; the very reason why I see RDF and Linked Data conflation 
an unfortunate attempt to force RDF (and all its troubles) on one of the 
truly useful outputs from the Semantic Web Project.


--

Regards,

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

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









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

2010-07-01 Thread Nathan

Sandro Hawke wrote:

On Thu, 2010-07-01 at 17:10 +0100, Nathan wrote:
In all honesty, if this doesn't happen, I personally will have no choice 
but to move to N3 for the bulk of things, and hope for other 
serializations of N3 to come along.


RIF (which became a W3C Recommendation last week) is N3, mutated (in
some good ways and some bad ways, I suppose) by the community consensus
process.   RIF is simultaneously the heir to N3 and a standard business
rules format.

RIF's central syntax is XML-based, but there's room for a presentation
syntax that looks like N3.   RIF includes triples which can have
literals as subject, of course.  (In RIF, these triples are called
"frames".   Well, sets of triples with a shared subject are called
frames, technically.But they are defined by the spec to be an
extension of RDF triples.)


does it cover formulae in s and o position?

i.e. can the following be expressed (without reification):

{ :thermostat :temp :high } log:implies { :heating :power "0" } .





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

2010-07-01 Thread Dan Brickley
On Thu, Jul 1, 2010 at 6:29 PM, Sandro Hawke  wrote:
> On Thu, 2010-07-01 at 17:10 +0100, Nathan wrote:
>> In all honesty, if this doesn't happen, I personally will have no choice
>> but to move to N3 for the bulk of things, and hope for other
>> serializations of N3 to come along.
>
> RIF (which became a W3C Recommendation last week) is N3, mutated (in
> some good ways and some bad ways, I suppose) by the community consensus
> process.   RIF is simultaneously the heir to N3 and a standard business
> rules format.
>
> RIF's central syntax is XML-based, but there's room for a presentation
> syntax that looks like N3.   RIF includes triples which can have
> literals as subject, of course.  (In RIF, these triples are called
> "frames".   Well, sets of triples with a shared subject are called
> frames, technically.    But they are defined by the spec to be an
> extension of RDF triples.)

Excellent, so there's no need to mess with RDF itself for a while? We
can let RIF settle in for a couple years and see how it shapes up
against people's RDFCore 2.0 aspirations?

Dan



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

2010-07-01 Thread Robert Fuller

Saw them, smiled, threw them in the bin.

I can't present a use case for "Literals as Subject", but I did have a 
relevant experience recently when having written a reasoner for sindice 
I was briefly intrigued to discover that executing some owl rules leads 
to a production of statements where literals appear in the subject 
position.


As the reasoner was written primarily with performance and memory 
constraints in mind, it never occurred to me to investigate whether the 
principles of rdf inferencing prohibit generating such statements.


But since triples with literal in the subject position are currently not 
of any interest to us, we simply discard them during a filtering phase.


Kind regards,
Robert

On 01/07/10 17:05, John Erickson wrote:

RE getting "a full list of the benefits," surely if it's being
discussed here, "Literals as Subjects" must be *somebody's* Real(tm)
Problem and the benefits are inherent in its solution?

And if it isn't, um, why is it being discussed here? ;)

On Thu, Jul 1, 2010 at 11:46 AM, Henry Story  wrote:

Jeremy, the point is to start the process, but put it on a low burner,
so that in 4-5 years time, you will be able to sell a whole new RDF+ suite to 
your customers with this new benefit.  ;-)

On 1 Jul 2010, at 17:38, Jeremy Carroll wrote:



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

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


but is that really correct? Because bnodes can be names for literals, and so 
you really do have
literals in subject positions No?



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

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


I agree, it would be good to get a full list of the benefits.



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

Jeremy












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



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

2010-07-01 Thread Sandro Hawke
On Thu, 2010-07-01 at 17:10 +0100, Nathan wrote:
> In all honesty, if this doesn't happen, I personally will have no choice 
> but to move to N3 for the bulk of things, and hope for other 
> serializations of N3 to come along.

RIF (which became a W3C Recommendation last week) is N3, mutated (in
some good ways and some bad ways, I suppose) by the community consensus
process.   RIF is simultaneously the heir to N3 and a standard business
rules format.

RIF's central syntax is XML-based, but there's room for a presentation
syntax that looks like N3.   RIF includes triples which can have
literals as subject, of course.  (In RIF, these triples are called
"frames".   Well, sets of triples with a shared subject are called
frames, technically.But they are defined by the spec to be an
extension of RDF triples.)

 -- Sandro





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

2010-07-01 Thread Axel Rauschmayer
Excellent point!

I can easily come up with examples where current SPARQL capabilities are too 
limiting or where atomic list nodes would tremendously help. But for 
literals-as-subjects, I do not see the need. It might also depend on how you 
interpret RDF:
(1) A triple is an element in a relation/predicate and thus loosely similar to 
a Prolog fact. It just so happens that the predicate is written infix.
(2) A triple describes a property of a resource, the resource is the dominant 
conceptual element

For (1), literals make sense, just for the sake of symmetry. For (2), they do 
not make sense, because identity becomes an issue. Well, this might just be my 
intuition, so I might be wrong.

As for the cost: Some improvement will eventually be made to RDF. Can we find a 
way to version the currently used standard? Loosely related, the transition 
from HTTP 1.0 to HTTP 1.1 seemed to have gone smoothly and they always include 
versions.

Axel

On Jul 1, 2010, at 18:05 , John Erickson wrote:

> RE getting "a full list of the benefits," surely if it's being
> discussed here, "Literals as Subjects" must be *somebody's* Real(tm)
> Problem and the benefits are inherent in its solution?
> 
> And if it isn't, um, why is it being discussed here? ;)
> 
> On Thu, Jul 1, 2010 at 11:46 AM, Henry Story  wrote:
>> Jeremy, the point is to start the process, but put it on a low burner,
>> so that in 4-5 years time, you will be able to sell a whole new RDF+ suite 
>> to your customers with this new benefit.  ;-)
>> 
>> On 1 Jul 2010, at 17:38, Jeremy Carroll wrote:
>> 
>>> 
>>> I am still not hearing any argument to justify the costs of literals as 
>>> subjects
>>> 
>>> I have loads and loads of code, both open source and commercial that 
>>> assumes throughout that a node in a subject position is not a literal, and 
>>> a node in a predicate position is a URI node.
>> 
>> but is that really correct? Because bnodes can be names for literals, and so 
>> you really do have
>> literals in subject positions No?
>> 
>> 
>>> Of course, the "correct" thing to do is to allow all three node types in 
>>> all three positions. (Well four if we take the graph name as well!)
>>> 
>>> But if we make a change,  all of my code base will need to be checked for 
>>> this issue.
>>> This costs my company maybe $100K (very roughly)
>>> No one has even showed me $1K of advantage for this change.
>> 
>> I agree, it would be good to get a full list of the benefits.
>> 
>>> 
>>> It is a no brainer not to do the fix even if it is technically correct
>>> 
>>> Jeremy
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 
> -- 
> John S. Erickson, Ph.D.
> http://bitwacker.wordpress.com
> olyerick...@gmail.com
> Twitter: @olyerickson
> 
> 

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






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

2010-07-01 Thread Dan Brickley
On Thu, Jul 1, 2010 at 5:38 PM, Jeremy Carroll  wrote:
>
> I am still not hearing any argument to justify the costs of literals as
> subjects
>
> I have loads and loads of code, both open source and commercial that assumes
> throughout that a node in a subject position is not a literal, and a node in
> a predicate position is a URI node.
>
> Of course, the "correct" thing to do is to allow all three node types in all
> three positions. (Well four if we take the graph name as well!)
>
> But if we make a change,  all of my code base will need to be checked for
> this issue.
> This costs my company maybe $100K (very roughly)
> No one has even showed me $1K of advantage for this change.
>
> It is a no brainer not to do the fix even if it is technically correct

Well said. Spend the money on a W3C-license javascript SPARQL engine,
or on fixing and documenting and test suiting what's out there
already. And whatever's left on rewriting it in Ruby, Scale, Lua ...

Better still, put the money up as a prize, then you only have to give
it to one party, while dozens of others will slave away for free in
pursuit of said loot ;)

Dan



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

2010-07-01 Thread Nathan

Dan, Jeremy, Pat, Henry, Michael, Kinglsey, Ivan, ack.. everyone,

Part of me feels like I should apologise for bringing this to the 
mailing list (even though it was inevitable) - this is all getting out 
of scope and the last thing we need is one of the most critical 
communities in what's a mini revolution to be split over such matters.


Valid arguments from all sides, technical and not - but things are 
really getting conflated here, at least from what I originally intended 
to put forward (probably past that and insignificant now).


I respect that everybody has made large investments, time, money, data, 
deployment, training and so forth; but really, non of that need be 
wasted and nobody need change anything that has any impact on any 
investments thus far.


My (personal) concern is really on the 10 year timeline (a bit shorter 
to be honest ;), there are limitations and things in RDF that do, 100%, 
prevent the web of data as a whole from moving forwards - however, 
nobody has to scrap anything.


Simply, define a non serialization specific model that caters for N3 and 
RDF - then let each standard or serialization specify what it 
implements/supports - the point here, and I stress, isn't to break 
anything, but to open it up to innovation and allow the next decades 
worth of hacking to get going


So RDF/XML is perhaps broken technically and doesn't support all these 
things, who cares? it obviously works just fine for a deployment of 
several billion triples, why change it? why not define it as a subset of 
some core model? - I can only see one reason not to, and I hate to say 
it, but some kind of pride that the work done thus far and commonly 
adopted *must* be seen to be 'perfect' - please, don't take that as any 
insult, as none is intended.


There are clearly very strong opinions on both sides, and very valid 
reasons too - there's an easy solution that would keep everybody happy 
and allow all to get on being productive and innovative - why not enable 
this?


In all honesty, if this doesn't happen, I personally will have no choice 
but to move to N3 for the bulk of things, and hope for other 
serializations of N3 to come along - I'd do that today, but you see I'm 
a huge linked data proponent and see almost unquantifiable gains from 
adopting linked data - but if what I do to get a full working model of 
the web of data doesn't qualify as valid RDF at some level and you all 
can't utilize it, then it's a wasted effort and a road to no where - 
this, is the real issue, and many others have hit it, and will hit it 
again and again as time moves on.


Please, do consider, nobody need loose anything here

Best,

Nathan

- :(

Jeremy Carroll wrote:


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


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


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


But if we make a change,  all of my code base will need to be checked 
for this issue.

This costs my company maybe $100K (very roughly)
No one has even showed me $1K of advantage for this change.

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

Jeremy








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

2010-07-01 Thread John Erickson
RE getting "a full list of the benefits," surely if it's being
discussed here, "Literals as Subjects" must be *somebody's* Real(tm)
Problem and the benefits are inherent in its solution?

And if it isn't, um, why is it being discussed here? ;)

On Thu, Jul 1, 2010 at 11:46 AM, Henry Story  wrote:
> Jeremy, the point is to start the process, but put it on a low burner,
> so that in 4-5 years time, you will be able to sell a whole new RDF+ suite to 
> your customers with this new benefit.  ;-)
>
> On 1 Jul 2010, at 17:38, Jeremy Carroll wrote:
>
>>
>> I am still not hearing any argument to justify the costs of literals as 
>> subjects
>>
>> I have loads and loads of code, both open source and commercial that assumes 
>> throughout that a node in a subject position is not a literal, and a node in 
>> a predicate position is a URI node.
>
> but is that really correct? Because bnodes can be names for literals, and so 
> you really do have
> literals in subject positions No?
>
>
>> Of course, the "correct" thing to do is to allow all three node types in all 
>> three positions. (Well four if we take the graph name as well!)
>>
>> But if we make a change,  all of my code base will need to be checked for 
>> this issue.
>> This costs my company maybe $100K (very roughly)
>> No one has even showed me $1K of advantage for this change.
>
> I agree, it would be good to get a full list of the benefits.
>
>>
>> It is a no brainer not to do the fix even if it is technically correct
>>
>> Jeremy
>>
>>
>
>
>



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



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

2010-07-01 Thread Henry Story
Jeremy, the point is to start the process, but put it on a low burner,
so that in 4-5 years time, you will be able to sell a whole new RDF+ suite to 
your customers with this new benefit.  ;-)

On 1 Jul 2010, at 17:38, Jeremy Carroll wrote:

> 
> I am still not hearing any argument to justify the costs of literals as 
> subjects
> 
> I have loads and loads of code, both open source and commercial that assumes 
> throughout that a node in a subject position is not a literal, and a node in 
> a predicate position is a URI node.

but is that really correct? Because bnodes can be names for literals, and so 
you really do have
literals in subject positions No?


> Of course, the "correct" thing to do is to allow all three node types in all 
> three positions. (Well four if we take the graph name as well!)
> 
> But if we make a change,  all of my code base will need to be checked for 
> this issue.
> This costs my company maybe $100K (very roughly)
> No one has even showed me $1K of advantage for this change.

I agree, it would be good to get a full list of the benefits.

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




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

2010-07-01 Thread Michael Hausenblas
> I am still not hearing any argument to justify the costs of literals as
> subjects.

+1

Cheers,
  Michael

-- 
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html



> From: Jeremy Carroll 
> Date: Thu, 01 Jul 2010 08:38:00 -0700
> To: Yves Raimond 
> Cc: Pat Hayes , Toby A Inkster , David Booth
> , , Dan Brickley ,
> Linked Data community , Semantic Web community
> 
> Subject: Show me the money - (was  Subjects as Literals)
> Resent-From: Linked Data community 
> Resent-Date: Thu, 01 Jul 2010 15:38:42 +
> 
> 
> I am still not hearing any argument to justify the costs of literals as
> subjects
> 
> I have loads and loads of code, both open source and commercial that
> assumes throughout that a node in a subject position is not a literal,
> and a node in a predicate position is a URI node.
> 
> Of course, the "correct" thing to do is to allow all three node types in
> all three positions. (Well four if we take the graph name as well!)
> 
> But if we make a change,  all of my code base will need to be checked
> for this issue.
> This costs my company maybe $100K (very roughly)
> No one has even showed me $1K of advantage for this change.
> 
> It is a no brainer not to do the fix even if it is technically correct
> 
> Jeremy
> 
>