Re: What is the current thinking about how to tie a concept or "tag" to a webpage via LinkedData?

[Daniel O'Connor]

On Sat, Jul 25, 2009 at 10:45 AM, Peter DeVries wrote:

> I was wondering what the current thinking is on ontologies that tie a
> concept or tag to a web page?


This sounds like MOAT / http://www.commontag.org/

What is the current thinking about how to tie a concept or "tag" to a webpage via LinkedData?

[Peter DeVries]

I was wondering what the current thinking is on ontologies that tie a
concept or tag to a web page?
I was thinking of creating links between species entities and webpages that
are about that species.

For instance the species entity *Puma concolor v6n7p *represented with this
uri*:*
*
*
*http://www.taxonconcept.org/ses/v6n7p*
*
*
and a web page
that is primarily about that species like this EOL page.
*
*
*http://www.eol.org/pages/311910*
*
*
In the RDF for the species entity I
describe it this way, since the page is primarily about this species.
*
*
http://www.eol.org/pages/311910"; />

But I was looking through various bookmarking ontologies and thought it
might be useful to create RDF
that ties the concept and a web page together. There seems to be two ways to
do this, one via something
like delicious (RDF representation)

Or via the Annotea ontology.

So I marked up this RDFa demo page.

http://www.taxonconcept.org/bookmarks/v6n7p_1000

I thought I should ask this list about the current best practices for
creating these links.

Thanks in Advance :-)

- Pete

---
Pete DeVries 
Department of Entomology
University of Wisconsin - Madison
445 Russell Laboratories
1630 Linden Drive
Madison, WI 53706
Email: pdevr...@wisc.edu
GeoSpecies Knowledge Base 
About the GeoSpecies Knowledge Base 

cool urls and redirects

[Eric Lease Morgan]

To what degree is it a best practice to implement "cool" URLs as  
redirects?


I manage a small database of electronic texts (approximately 20,000  
items). Because the content is in a database I can create reams of  
reports against it. Browsable lists by title, author, and keyword/ 
subject. I can index the lot with Solr/Lucene. I can create various  
versions of the content: 1) plain text, 2) simple HTML, 3) HTML  
complete with a handy-dandy floating palette supporting various  
services against the texts, 4) PDF. Etc. About 18 months ago I started  
creating RDF files representing the texts. For example, Thomas More's  
Utopia. [1]


My next self-assigned project is to present my small database as a set  
of linked data. To this end I have written a mod_perl module that  
dereferences a URI. For example [2], given a key, the module  
negotiates content, returns a 303, and a URL to RDF or HTML  
representations.


Now, my question is, should the URLs I return be the long ugly ones  
pointing to actual files on my file system, or can they be "cool" URLs  
that are actually redirects? In other words, instead of returning  
something like this:


http://infomotions.com/etexts/literature/english/1500-1599/more-utopia-221.rdf

is it acceptable to return something like this and have it redirected  
to the URL above:


http://infomotions.com/etexts/rdf/more-utopia-221

Similarly, when returning URLs pointing to an HTML representation,  
should I return A or something more like B:


A. 
http://infomotions.com/etexts/literature/english/1500-1599/more-utopia-221.htm
B. http://infomotions.com/etexts/html/more-utopia-221

Once I figure out the answers to these questions, then I can start  
cleaning up my RDF files and including the "best" URIs in them.



[1] Utopia - 
http://infomotions.com/etexts/literature/english/1500-1599/more-utopia-221.rdf
[2] dereference - http://infomotions.com/etexts/id/more-utopia-221


--
Eric Lease Morgan
Head, Digital Access and Information Architecture Department
Hesburgh Libraries, University of Notre Dame

(574) 631-8604

owl:sameAs

[Eric Lease Morgan]

I would like to make my Alex Catalogue more accessible as linked data,  
but I need some help in regards to the syntactical use of owl:sameAs.


I am well on my way to minting URIs and "cool" URLs, I think. For  
example:


 * negotiation - http://infomotions.com/etexts/id/more-utopia-221
 * RDF - http://infomotions.com/etexts/data/more-utopia-221
 * HTML - http://infomotions.com/etexts/page/more-utopia-221

More importantly, I need to figure out how to make my RDF richer. Here  
is what I have so far for my local copy of Thomas More's Utopia:


 
 http://www.w3.org/1999/02/22-rdf-syntax-ns#";
   xmlns:dcterms = "http://purl.org/dc/terms/";
   xmlns:owl = "http://www.w3.org/2002/07/owl# >

   http://infomotions.com/etexts/id/more-utopia-221 
">

 More, Thomas
 -00-00
 
 en
 Wiretap Electronic Text Archivedcterms:publisher>
 http://creativecommons.org/licenses/GPL/2.0/dcterms:rights>
 gopher://wiretap.spies.com:70/00/Library/Classic/utopia.txt 
" />

 man
 people
 utopia
 english
 literature
 Utopia
 text
 http://infomotions.com/etexts/literature/english/1500-1599/more-utopia-221.txt 
" />
 http://infomotions.com/etexts/concordance/more-utopia-221 
" />
 http://infomotions.com/etexts/page/more-utopia-221 
" />

   

 

Specifically, I need to know how to:

 * specify that the title is the same as 
http://dbpedia.org/resource/Utopia_(book)
 * specify the author is the same as http://dbpedia.org/resource/Thomas_More
 * point the subject words to things like a linked data version of  
WordNet


Is most of this done by simply adding an owl:sameAs attribute to the  
appropriate element(s), like this:


 http://infomotions.com/etexts/id/more-utopia-221";
 owl:sameAs="http://dbpedia.org/resource/Utopia_(book)">

or

 http://dbpedia.org/resource/ 
Thomas_More">More, Thomas


--
Eric Lease Morgan
Infomotions, Inc.

Re: Alternatives to OWL for linked data?

[Paul Houle]

On Fri, Jul 24, 2009 at 9:30 AM, Axel Rauschmayer  wrote:

>
> While it's not necessarily easier to understand for end users, I've always
> found Prolog easy to understand, where OWL is more of a challenge.
>
> So what solutions are out there? I would prefer description logic
> programming to OWL. Does Prolog-like backward-chaining make sense for RDF?
> If so, how would it be combined with SPARQL; or would it replace it? Or
> maybe something frame-based?
>
> Am I making sense? I would appreciate any pointers, hints and insights.



 I've got some projects in the pipe that are primarily based on Dbpedia
and Freebase,  but I'm incorporating data from other sources as well.  The
core of this is a system called Isidore which is a specialized system for
handling generic databases.
 My viewpoint is that there are certain kinds of reasoning that are best
done in a specialized way;  for instance,  the handling of identities,
 names and categories ("category" here includes the Dbpedia ontology and
Freebase types as well as internally generated.  For instance, a common task
is looking up an object by name.  Last time I looked,  there were about 10k
Wikipedia articles that had names that differed only by capitalization;
 most of the time you want name-lookups to be case-insensitive,  but you
still want addressability for the strange cases.

Wikipedia also has a treasure trove of information about disambiguation.
 The projects I do are about specific problem domains,  say animals,  cars,
 or video games:  I can easily qualify a search for "Jaguar" against a
problem domain and get the right dbpedia resource.

The core of identity,  naming and category information is small:  it's
easy to handle and easy to construct from Dbpedia and Freebase dumps.  From
the core it's possible to identify a problem domain and import data from
Dbpedia,  Freebase and other sources to construct a working database.

---

You might say that this is too specialized,  but this is the way the
brain works.  It's got specific modules for understanding particular problem
domains (faces,  people,  space,  etc.)  It's not so bad because the number
of modules that you need is finite.  Persons and Places represent a large
fraction of Dbpedia,  so reasoning about people and GIS can get you a lot of
mileage.  Freebase has particularly rich collection of data about musical
recordings and

I'm not sure if systems like OWL,  etc are really the answer -- we might
need something more like Cyc (or own brain) that has a lot of specialized
knowledge about the world embedded in it.



I see reification as an absolute requirement.  Underlying this is the
fact that generic databases are full of junk.  I'm attracted to Prolog-like
systems (Datalog?) but conventional logic systems are easily killed by
contradictory information.  This becomes a scalability limitation unless
you've got a system that is naturally robust to junk data.  You've also got
to be able to do conventional filtering:  you've got to be able to say
"Triple A is wrong",  "I don't trust triples from source B",  "Source C uses
predicate D incorrectly",  "Don't believe anything that E says about subject
F."  To deal with the (existing and emerging) semspam threat,  we'll also
need the same kind of probabilistic filtering that's used for e-mail and
blog comments.  (Take a look at the external links Dbpedia table if you
don't believe me)

The biggest challenge I see in generic databases is fiction.  Wikipedia
has a shocking amount of information about fiction:  this is a both an
opportunity and a danger.  For one thing,  people love fiction -- a G.P.A.I.
certainly needs to be able to appreciate fiction in order to appreciate the
human experience  On the other hand,  any system that does reasoning about
physics needs to tell the difference between

http://en.wikipedia.org/wiki/Minkowski_space

and

http://en.wikipedia.org/wiki/Minovsky_Physics#Minovsky_Physics

Also,  really it's all fiction when it comes down to it.  When a robocop
shows up at the scene of a fight,  it's going to hear contradictory stories
about who punched who first.  It's got to be able to listen to contradictory
stories and keep them apart,  and not fall apart like a computer from a bad
sci-fi movie.

---

Microtheories?  Nonmonotonic logic?

Perhaps.

You can go ahead and write standards and write papers about systems that
ignore the problems above,  but you're not going to make systems that work,
 on an engineering basis,  unless you confront them.

cool urls and redirects

[Eric Lease Morgan]

To what degree is it a best practice to implement "cool" URLs as  
redirects?


I manage a small database of electronic texts (approximately 20,000  
items). Because the content is in a database I can create reams of  
reports against it. Browsable lists by title, author, and keyword/ 
subject. I can index the lot with Solr/Lucene. I can create various  
versions of the content: 1) plain text, 2) simple HTML, 3) HTML  
complete with a handy-dandy floating palette supporting various  
services against the texts, 4) PDF. Etc. About 18 months ago I started  
creating RDF files representing the texts. For example, Thomas More's  
Utopia. [1]


My next self-assigned project is to present my small database as a set  
of linked data. To this end I have written a mod_perl module that  
dereferences a URI. For example [2], given a key, the module  
negotiates content, returns a 303, and a URL to RDF or HTML  
representations.


Now, my question is, should the URLs I return be the long ugly ones  
pointing to actual files on my file system, or can they be "cool" URLs  
that are actually redirects? In other words, instead of returning  
something like this:


 http://infomotions.com/etexts/literature/english/1500-1599/more-utopia-221.rdf

is it acceptable to return something like this and have it redirected  
to the URL above:


 http://infomotions.com/etexts/rdf/more-utopia-221

Similarly, when returning URLs pointing to an HTML representation,  
should I return A or something more like B:


 A. 
http://infomotions.com/etexts/literature/english/1500-1599/more-utopia-221.htm
 B. http://infomotions.com/etexts/html/more-utopia-221

Once I figure out the answers to these questions, then I can start  
cleaning up my RDF files and including the "best" URIs in them.



[1] Utopia - 
http://infomotions.com/etexts/literature/english/1500-1599/more-utopia-221.rdf
[2] dereference - http://infomotions.com/etexts/id/more-utopia-221

--
Eric Lease Morgan
Infomotions, Inc.

Re: Merging Databases

[Antoine Isaac]

Hello Pat,

A long and interesting answer. I've got no time to answer on all points (many 
of them making much sense, I have to acknowledge). I'll start focusing on the 
following paragraph...

Is it symmetric (A skos:exactMatch B  implies   B skos:exactMatch A) and 
reflexive (A skos:exactMatch A) ? Because if it is all three of 
symmetric, reflexive and transitive then it is an equivalence relation, 
and if it is also substitutive, then it IS equality (owl:sameAs), 
whether the "reference documentation" admits this or not.


Well, it is sym, refl and trans, but it is not "globally" substitutive (A skos:exactMacth B does not imply that A and B can be substituted for *all* RDF statements). 
The problem is that this is indeed not defined other than in prose. How to do it formally? We cannot even say that skos:exactMatch and owl:sameAs are disjoint properties, since they may very well share a part of their extensions.


The fact is that it may be substitutive for some properties (is such wording 
meaningful in formal terms? I hope so...), and in fact it is our hope. But we 
could not specify the axioms that specify such substitution rules, because we 
cannot anticipate all uses of SKOS concepts (in terms of properties that would 
have SKOS concepts as subjects or objects).
We could think of some axiom pattern, in the line of "there exists somewhere a 
property for which substitution shall be done". But would it have helped much, in 
terms of the RDF inferences you are calling for?

So, yes, this story is to some extent hot air. In fact exactMatch defines an 
equivalence relation, but beyond that nothing is known, because the 
substitution should be done on constructs that are not in the SKOS vocabulary.
To answer your question, shall you substitute A and B? Well, it's your pick: 
you have to decide for which properties they should be substituted. We could 
not invent them for you!
Actually there was one skos:subject having skos:Concept as range in the 
previous version of SKOS, which could have been ok for such substitution 
rules---if a document has subject A, and A is exactMacth of B, then the 
document has B as subject. But it was removed, as clearly less in SKOS' scope 
than in other vocabularies', such as Dublin Core.

About inconsistencies due to the use of exactMatch, they may mainly emerge when 
comparing with the extension of other semantic relations, as contributed in 
other mappings or concept schemes. For instance, skos:exactMatch is disjoint 
with skos:broadMatch and skos:relatedMatch

Finally, about skos:relatedMatch, I'm sorry for having been too blunt, it has indeed some semantics, in the form of domain and range: you could use relatedMatch with for all cases with seeAlso, but then a number of document resources would be classified as SKOS concepts. Which would raise some inconsistencies if appropriate disjointness axioms are captured. But again, we cannot ourselves list all the classes that are disjoint with SKOS concepts. And you may argue that this is still very basic semantics, that the normative side is paramount here. You're right, skos:related is supposed to be used for relationships in existing controlled vocabularies that are extremely diverse. 
Now, does that still make it meaningless to introduce it? Well, it does correspond to existing practices, and is used in a lot of data out there, which can be exploited in a large number of interesting scenarios...


Best,

Antoine



On Jul 23, 2009, at 4:24 AM, Antoine Isaac wrote:


Hello,

Trying to add some explanation wrt. the SKOS vocabulary, hoping not to 
conflict with Pat's clarifications ;-)


For skos:exactMatch, the SKOS reference says [1]:
The property skos:exactMatch is used to link two concepts, indicating 
a high degree of confidence that the concepts can be used 
interchangeably across a wide range of information retrieval 
applications


So there can be substitution. But, contrary to what happens with 
owl:sameAs, this substitution is not automatic for *all* RDF triples 
the concept would be involved in. Actually it is left to implementers 
or ontology provider to define in which "context" two exactly 
equivalent concepts may be substituted.


To me, that makes this almost completely useless, and actually harmful 
to interoperation: for I have (the code I write has) no way to know what 
"context' is intended when reading such an assertion. Here I am with 
some RDF, and I am told that A skos:exactMatch B. Can I substitute B for 
A in my content? Nobody knows. The SKOS documentation doesn't know. 
Nothing in my RDF tells me the answer. I have no way to know where to go 
to discover the answer. If I decide to go with my high degree of 
confidence and make the inference, and in fact it wasnt appropriate, how 
will I ever discover this? What kind of formally detectable 
inconsistency would lead me (my code) to conclude that a mistake had 
been made, and where? Without some answers to some of these (obvious) 
questions, skos:exa

Re: Merging Databases

[Pat Hayes]

On Jul 21, 2009, at 8:42 PM, Peter Ansell wrote:


2009/7/22 Pat Hayes :


On Jul 21, 2009, at 7:26 PM, Alan Ruttenberg wrote:


On Tue, Jul 21, 2009 at 1:23 PM, Toby Inkster wrote:


On Tue, 2009-07-21 at 19:52 +0300, Bernhard Schandl wrote:


I would say: Never assert sameAs. It's just too big a hammer.
Instead use a wider palette of relationships to connect entities
to other ones.


which ones would you recommend?


skos:exactMatch = asserts that the two resources represent the same
concept


Say, refer to the same thing.


, but does not assert that all triples containing the first
resource are necessarily true when the second resource is  
substituted

in.


I'm having trouble parsing this one. I don't know what concepts are,
but they are an odd sort of thing if they can be the same, but can't
be substituted.


This is exactly what is needed in many cases. Philosophical  
terminology is

that they have the same referent but not the same sense, and lack of
substitutability reflects the unfortunate but inevitable fact that  
the Web
as a whole is not referentially transparent (yet). More mundane  
example, the
same person might need to be referred to in one way in one context  
and

differently in another, just because the two social contexts require
different forms of address. (That example from Lynn Stein.)


The two things may also still be described using the same sense but
the representations could be structurally incompatible and the
substitution has risky effects even though one is sure that the two
representations mean the same thing in the same sense.


I was using 'sense' in Frege's, er, sense (in the original, Sinn vs.  
Bedeutung), so I don't believe that what you say can be correct. If  
two expressions have the same **sense** then they really are  
intersubstitutable in all contexts, I believe. But maybe you have a  
counterexample? (Lynn's 'social use' case might be one, in fact.)




To me it is partly an issue of data granularity, although it isn't
necessarily heirarchical, so can't be generally represented and
resolved using rules. Something like
myterms:alternateRepresentationUri might be what I would see it as, in
addition to the myterms:alternateSenseUri that you described. (The
could both be sub properties of rdfs:seeAlso and/or something like
myterms:alternateUri, without any harm as far as I can tell) The term
rdfs:seeAlso provides this in some way but going one step further
without implying any extra information inside of the system would be
nice as seeAlso has been used to point people to web page addresses
that wouldn't actually be substituted by people even if they wanted to
so its history is too broad for the purpose here.


Yes, seeAlso is really extremely weak and can mean anything.


Ideally one would never have these issues because people can now
communicate unambiguously and in realtime, but there are still people
that are needed to put the rules in and encode the information. They
may quite easily fundamentally disagree on a single representation and
its broader implications so there will be cases where you want to say
real world equivalence without implying any extra information that
will disturb the system in undesired ways. If people want to describe
without automatic implication they should be able to in my opinion.


Well, of course they can, its a free Web. But what does this mean? A  
description amounts to some kind of constraint, thought of  
semantically. When you describe the way things are, you rule out other  
ways they cannot be. And then that ruling out automatically supports  
certain kinds of entailment. Even if you decide not to draw those  
conclusions, they are still **valid**, which is all that the specs  
specify, in fact. So you can't describe without automatically  
entailing, even if you don't do anything operational with those  
entailments. You cannot describe without implying some other things,,  
by the very nature of describing.



If
you have the datasets locally stored you could always locally redefine
the term to be a sub property of owl:sameAs if you needed to see what
would happen if complete automatic implications were made based on
these statements.


True, and in fact you could do this many other ways, purely locally. I  
agree that local experiments are completely unconstrained by the Web  
specifications, which really only apply to **published** content.


Pat



Cheers,

Peter





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: Merging Databases

[Pat Hayes]

On Jul 23, 2009, at 4:24 AM, Antoine Isaac wrote:


Hello,

Trying to add some explanation wrt. the SKOS vocabulary, hoping not  
to conflict with Pat's clarifications ;-)


For skos:exactMatch, the SKOS reference says [1]:
The property skos:exactMatch is used to link two concepts,  
indicating a high degree of confidence that the concepts can be  
used interchangeably across a wide range of information retrieval  
applications


So there can be substitution. But, contrary to what happens with  
owl:sameAs, this substitution is not automatic for *all* RDF triples  
the concept would be involved in. Actually it is left to  
implementers or ontology provider to define in which "context" two  
exactly equivalent concepts may be substituted.


To me, that makes this almost completely useless, and actually harmful  
to interoperation: for I have (the code I write has) no way to know  
what "context' is intended when reading such an assertion. Here I am  
with some RDF, and I am told that A skos:exactMatch B. Can I  
substitute B for A in my content? Nobody knows. The SKOS documentation  
doesn't know. Nothing in my RDF tells me the answer. I have no way to  
know where to go to discover the answer. If I decide to go with my  
high degree of confidence and make the inference, and in fact it wasnt  
appropriate, how will I ever discover this? What kind of formally  
detectable inconsistency would lead me (my code) to conclude that a  
mistake had been made, and where? Without some answers to some of  
these (obvious) questions, skos:exact Match might as well be called  
skos:SpongeBobSquarePants.


As a (fictious!) result, one concept may be substituted by another  
if it is the object of a dc:subject statement, but not if it is the  
subject of a dc:creator statement.
The idea was really to be able to state some form of semantic  
equivalence that would be less committing than the RDF/OWL one.


And the problem, which this conspicuously fails to address, is how to  
make semantic sense of this idea of "semantic equivalence which is  
less committed". Until one does, calling it "semantic" is just hot  
air. Here's the central issue. The actual semantics of owl:sameAs is  
defined as co-reference. It does not mean that there are two things, A  
and B, which are equivalent in a strong sense (which can be weakened,  
no doubt, if we only think about it for a bit.)  A sameAs B means that  
the two names 'A' and 'B' denote the very same thing. So if A sameaAs  
B, there is ONE THING with two names. That is what the semantics  
specifies. But **being the very same thing as** is not something that  
admits of weakening or can be given degrees of commitment. Two very  
similar things can be more or less similar, but one thing cannot be  
slightly-not-the-same as itself. You can't be partially or  
approximately the same as yourself, because any relation other than  
identity requires the relationship to hold between TWO similar but non- 
identical things, and it is the very point of identity - sameAs -   
that when it holds, there is only ONE thing there. Now, turn this  
around. What other semantically defined circumstances would sanction  
substituting the name A for the name B in some assertion, **except**  
that A and B denote the same thing? Remember, to count as 'semantic',  
the criterion has to be stated in terms of what the names denote, not  
in terms of the names themselves. So 'A' denotes some thing, A, and  
'B' denotes B, and we want some conditions on A and B, not on 'A' and  
'B', that is enough to justify taking something said using the name  
'A' and treating it as being said using the name 'B' instead. If A and  
B are different, what would give anyone a licence to transfer truths  
asserted about one of them to similar-but-different truths asserted  
about the other? What kind of "context" would this be, that permits  
such blatantly invalid inferences?


Hopefully you can see that a genuinely semantic analysis of this  
situation is somewhat difficult. You don't get it by inventing  
plausible-sounding relationship names, providing no axioms for them,  
and then being deliberately vague about what they mean and calling  
this 'reference documentation'.




Now, skos:exactMatch is transitive, which means that if a concept X  
in one vocabulary has been mapped to Y in a second vocabulary, and Y  
is connected to Z in a third vocabulary, then X and Z can be  
substituted.


Is it symmetric (A skos:exactMatch B  implies   B skos:exactMatch A)  
and reflexive (A skos:exactMatch A) ? Because if it is all three of  
symmetric, reflexive and transitive then it is an equivalence  
relation, and if it is also substitutive, then it IS equality  
(owl:sameAs), whether the "reference documentation" admits this or not.


This can (and will) be useful, but may be also harmful if the two  
mappings were created with different application concerns in mind,


IF?? Of COURSE this will happen.

and that negligible sem

Re: Recipe for Shops: Showing up in Yahoo and in the Web of Data in One Turn

[Seth Russell]

Well actually, sorry to say, i couldn't get much out of pyRdfa even
for your own demo page.  What i want is a very simple feedback and
demo.  Paste the url and get back a web page of errors or the triples
already hyperlinked to what they refer to.   Instead i was presented
with a lot of choices that didn't mean anything to me, nor as far as i
could see did they apply to your demo page.

For the Semantic Web to be useful it needs to stop being so geeky.

-- 
Seth Russell
www.speaktomecatalog.com


On Wed, Jul 22, 2009 at 7:57 AM, Michael
Hausenblas wrote:
>
> Seth,
>
> Something like pyRDFa [1] ?
>
> Cheers,
>      Michael
>
> [1] http://www.w3.org/2007/08/pyRdfa/
>
> --
> 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: Seth Russell 
>> Date: Wed, 22 Jul 2009 07:35:28 -0800
>> To: 
>> Cc: semantic-web at W3C , Linked Data community
>> 
>> Subject: Re: Recipe for Shops: Showing up in Yahoo and in the Web of Data in
>> One Turn
>> Resent-From: Linked Data community 
>> Resent-Date: Wed, 22 Jul 2009 15:36:12 +
>>
>> Thanks for the example :)  It looks quite doable.
>>
>> Do you know if someone has written a validator page for this RDFa kind
>> of markup?  We need something like http://validator.w3.org/feed/ .
>> There is nothing like instant feedback ... a page that you can go to
>> and paste in your URL and get back a web version of the triples that
>> it creates as well as any errors.
>>
>> --
>> Seth Russell
>> www.speaktomecatalog.com
>>
>> On Tue, Jul 21, 2009 at 9:42 AM, Martin Hepp
>> (UniBW) wrote:
>>> Dear all:
>>>
>>> I just completed a recipe meant for larger audiences (Web developers,
>>> SEO companies) on how a business can enrich its pages using
>>> RDFa+GoodRelations so that the data
>>> - shows up in Yahoo AND
>>> - it at the same time useful for comprehensive RDF applications.
>>>
>>> The recipe is at
>>>
>>> http://tr.im/rAbN
>>>
>>> It tries to combine pure recipes from the RDF world with the "Web
>>> developer's" how-tos provided by Yahoo.
>>>
>>> Any feedback is very welcome.
>>>
>>> Best
>>>
>>> Martin Hepp
>>>
>>> --
>>> --
>>> martin hepp
>>> e-business & web science research group
>>> universitaet der bundeswehr muenchen
>>>
>>> e-mail:  mh...@computer.org
>>> phone:   +49-(0)89-6004-4217
>>> fax:     +49-(0)89-6004-4620
>>> www:     http://www.unibw.de/ebusiness/ (group)
>>>         http://www.heppnetz.de/ (personal)
>>> skype:   mfhepp
>>> twitter: mfhepp
>>>
>>> Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
>>> 
>>>
>>> Webcast:
>>> http://www.heppnetz.de/projects/goodrelations/webcast/
>>>
>>> Talk at the Semantic Technology Conference 2009:
>>> "Semantic Web-based E-Commerce: The GoodRelations Ontology"
>>> http://tinyurl.com/semtech-hepp
>>>
>>> Tool for registering your business:
>>> http://www.ebusiness-unibw.org/tools/goodrelations-annotator/
>>>
>>> Overview article on Semantic Universe:
>>> http://tinyurl.com/goodrelations-universe
>>>
>>> Project page and resources for developers:
>>> http://purl.org/goodrelations/
>>>
>>> Tutorial materials:
>>> Tutorial at ESWC 2009: The Web of Data for E-Commerce in One Day: A Hands-on
>>> Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey
>>>
>>> http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009
>>>
>>>
>>>
>>>
>>
>
>

Re: Merging Databases

[Hugh Glaser]

On 24/07/2009 16:28, "Alan Ruttenberg"  wrote:

> As a constructive suggestion, an incremental improvement to sameAs.org
> would be to systematically eradicate any references to dbpedia entries
> that are disambiguation pages on wikipedia.
> 
> -Alan
> 
Thanks Alan.
I'm not quite clear what you mean.
If I look at something like
http://dbpedia.org/resource/London_(disambiguation)
I don't get anything (or rather I get a singleton bundle, which is the
same).

In general for this sort of data, we simply reflect the decisions made by
the sources, such as dbpedia. Should we be rejecting some of their sameAs,
or is it something you think should be changed by them?

We do have a facility for "deprecating" URIs, which would mean they can be
looked up, but are never published in a bundle; that might be the sort of
thing you want?

Best
Hugh

Re: Merging Databases

[Pat Hayes]

On Jul 21, 2009, at 8:43 PM, Alan Ruttenberg wrote:


On Tue, Jul 21, 2009 at 9:22 PM, Pat Hayes wrote:
Heres another example. Cyc lists all the chemical elements, and  
cross-links

to other such lists in other ontologies using owl:sameAs. But the Cyc
ontology says that an element is the set (class) of all pieces of  
the pure
element, so that for example sodium in Cyc has a member which is  
the lump of
pure metallic sodium I keep safely under glycerin in a glass bottle  
on my
shelf. This is a clever ontological device which makes a bunch of  
inferences
very slick in Cyc, but I bet its not the same *idea* of sodium that  
most

ontologies would agree with. So that sameAs ought to be (and it is
understood as meaning) 'same chemical element', but it does not  
allow mutual
substitutivity, even if you were to translate those other  
ontologies into

CycL, which nobody is ever likely to do.


My gut reaction is that URIs ought to be names that refer, and that
sense ought to be conveyed more explicitly as statements.


That doesn't work. IF there really are opaque contexts out there, then  
making statements in a transparent language is never going to capture  
the full sense.



That seems
to be the basis of the model theory that underlies the semweb
languages


Indeed, the current model theory presumes, implicitly, a referentially  
transparent system. Obviously this would be great, but I think this  
isn't what we in fact have.



(yes, I realize that there's currently room for 2+ different
referencings using the same name). I realize that in natural language
name can carry both sense and reference (or let's just say "more than
reference" since there seem to be a number of theories of exactly what
goes on with words). But it seems that it's been at least a hundred
years that relatively modern philosophers have been hacking away at
trying to understand exactly what the phenomena are, and how to
understand them. Should we really try to adopt exactly the same model
as language, given that we don't really understand it?

In your sodium example, i don't really know what to do with the "idea
of sodium" being the same or different, but I *can* say that a
molecule of sodium is not the same sort of thing as a lump of sodium
metal. They have different physical properties and some things that
make sense to say about one don't make sense to say about the other
(like the melting point of xxx is 370.87 K).


Of course: they have different masses as well. But one thing they have  
in common is exactly that they are both pieces of sodium, in the exact  
sense of 'piece' required by mereology: a piece of sodium with no  
parts that are not also parts of sodium. The **concept** is perfectly  
clear and coherent, and extremely handy for inference-making. For  
example, an atom is a piece which has no smaller pieces.


So, what in your view should the name of the element, 'sodium', be  
taken to denote? One possible answer is, it denotes the class of all  
sodium molecules, or the class of all sodium atoms, or some such. This  
seems natural to a chemist, but it means that my lump of reactive  
metal isn't a piece of sodium: its a piece of stuff all of whose atoms  
are sodium atoms, which seems awkward and unnatural (for example,  
people know about sodium before the idea of atoms was universally  
accepted, so they seem to be conceptually distinguishable.) The Cyc  
technique is really only a small step from the class-of-all-atoms  
idea, but it has the merits that all pieces of sodium are, indeed,  
pieces of sodium. My point is only that this theory of what  
constitutes a chemical element is, while coherent, also idiosyncratic;  
so we seem to need a way to say "denotes same chemical element as"  
without also saying "is logically identical to" (sameAs), because we  
have to allow ontology A to have a somewhat different conception of,  
say, sodium than that used by ontology B, even though they are both  
ontologies about the same topic, and we want to be able to record this  
useful fact. OR else we need to face up to the possibility that  
because A is referntially opaque when seen from B, a bare statement of  
equality does *not* automatically give us a licence to substitute one  
name for another. That is an ugly but Im beginning to think inevitable  
truth.




Now you might say: Well, they are the same *concept*.


I'd prefer to avoid the c-word as long as possible. But in fact, I'd  
say that they aren't the same concept (of sodium) and that is  
precisely the issue here.



But what am I to
do with that? What can I conclude from that statement. Isn't it
throwing a whole lot under the rug to lump all these sorts of
relations into any single "same" bucket?


I entirely agree. What I want is to find a way to keep different  
senses of same-as distinct. But the puzzling thing is that in cases  
like sodium, here, this is **exactly** what sameAs is supposed to  
mean: both ontologies claim to be talking about the 

Re: Merging Databases

[David Baxter]

On Fri, Jul 24, 2009 at 10:26 AM, Alan Ruttenberg
wrote:

> On Fri, Jul 24, 2009 at 11:11 AM, David Baxter wrote:
> >
> >
> > On Tue, Jul 21, 2009 at 8:43 PM, Alan Ruttenberg <
> alanruttenb...@gmail.com>
> > wrote:
> >>
> >> On Tue, Jul 21, 2009 at 9:22 PM, Pat Hayes wrote:
> >> > Heres another example. Cyc lists all the chemical elements, and
> >> > cross-links
> >> > to other such lists in other ontologies using owl:sameAs. But the Cyc
> >> > ontology says that an element is the set (class) of all pieces of the
> >> > pure
> >> > element, so that for example sodium in Cyc has a member which is the
> >> > lump of
> >> > pure metallic sodium I keep safely under glycerin in a glass bottle on
> >> > my
> >> > shelf. This is a clever ontological device which makes a bunch of
> >> > inferences
> >> > very slick in Cyc, but I bet its not the same *idea* of sodium that
> most
> >> > ontologies would agree with. So that sameAs ought to be (and it is
> >> > understood as meaning) 'same chemical element', but it does not allow
> >> > mutual
> >> > substitutivity, even if you were to translate those other ontologies
> >> > into
> >> > CycL, which nobody is ever likely to do.
> >>
> >> My gut reaction is that URIs ought to be names that refer, and that
> >> sense ought to be conveyed more explicitly as statements. That seems
> >> to be the basis of the model theory that underlies the semweb
> >> languages (yes, I realize that there's currently room for 2+ different
> >> referencings using the same name). I realize that in natural language
> >> name can carry both sense and reference (or let's just say "more than
> >> reference" since there seem to be a number of theories of exactly what
> >> goes on with words). But it seems that it's been at least a hundred
> >> years that relatively modern philosophers have been hacking away at
> >> trying to understand exactly what the phenomena are, and how to
> >> understand them. Should we really try to adopt exactly the same model
> >> as language, given that we don't really understand it?
> >>
> >> In your sodium example, i don't really know what to do with the "idea
> >> of sodium" being the same or different, but I *can* say that a
> >> molecule of sodium is not the same sort of thing as a lump of sodium
> >> metal. They have different physical properties and some things that
> >> make sense to say about one don't make sense to say about the other
> >> (like the melting point of xxx is 370.87 K).
> >
> > For what it's worth, Cyc does not generally consider individual molecules
> of
> > a substance to be instances of that substance. For example, "iodine
> > molecule"
> > (
> http://sw.opencyc.org/concept/Mx8Ngh4rwPzt4pwpEbGdrcN5Y29ycB4rvVj8dJwpEbGdrcN5Y29ycA
> )
> > is not a subclass of "iodine"
> > (http://sw.opencyc.org/concept/Mx4rvVj8dJwpEbGdrcN5Y29ycA).
> >
> > David
>
> Thanks for pointing that out! Which one, if either, do you think is
> sameAs http://dbpedia.org/resource/Iodine (only one of them is
> according to sameAs.org.


The existing link looks good to me, i.e. "iodine" (
http://sw.opencyc.org/concept/Mx4rvVj8dJwpEbGdrcN5Y29ycA).
The DBpedia concept is pretty bare right now, but the Wikipedia entry (
http://en.wikipedia.org/wiki/Iodine) on which it is based seems to be
primarily describing the super-molecular substance.

David


>
>
> As an aside, another amusing sameAs in that family is
>
> http://dbpedia.org/resource/Iodine
>
> Iodine, is a chemical element that has the symbol I and atomic number
> 53. Naturally-occurring iodine is a single isotope with 74 neutrons...
>
> http://dbpedia.org/resource/Iodo
>
> Iodo may refer to; Socotra Rock Iodo (film), South Korean film
> directed by Kim Ki-young Iodine, chemical element...
>
> ref:
>
>
> http://sameas.org/html?uri=http%3A%2F%2Fdbpedia.org%2Fresource%2FIodine&x=0&y=0
>
> I mean no slight to the intentions of creating the sameAs resource
> but, realistically, pretty much anywhere you look there are
> substantive errors.
>
> -Alan
>
> >
> >>
> >> Now you might say: Well, they are the same *concept*. But what am I to
> >> do with that? What can I conclude from that statement. Isn't it
> >> throwing a whole lot under the rug to lump all these sorts of
> >> relations into any single "same" bucket? And for what good? Google is
> >> pretty good at bringing all these different sorts of things together
> >> already - shouldn't the semweb stuff be doing something different?
> >>
> >> -Alan
> >> (who's been reading and puzzling too many days in a row about how
> >> words relate to ... everything)
> >>
> >> > On Jul 21, 2009, at 7:58 PM, Pat Hayes wrote:
> >> >
> >> >>
> >> >> On Jul 21, 2009, at 7:26 PM, Alan Ruttenberg wrote:
> >> >>
> >> >>> On Tue, Jul 21, 2009 at 1:23 PM, Toby Inkster wrote:
> >> 
> >>  On Tue, 2009-07-21 at 19:52 +0300, Bernhard Schandl wrote:
> >> 
> >> >> I would say: Never assert sameAs. It's just too big a hammer.
> >> >> Instead use a wider palette of relationships to conn

Re: Merging Databases

[Alan Ruttenberg]

On Fri, Jul 24, 2009 at 11:11 AM, David Baxter wrote:
>
>
> On Tue, Jul 21, 2009 at 8:43 PM, Alan Ruttenberg 
> wrote:
>>
>> On Tue, Jul 21, 2009 at 9:22 PM, Pat Hayes wrote:
>> > Heres another example. Cyc lists all the chemical elements, and
>> > cross-links
>> > to other such lists in other ontologies using owl:sameAs. But the Cyc
>> > ontology says that an element is the set (class) of all pieces of the
>> > pure
>> > element, so that for example sodium in Cyc has a member which is the
>> > lump of
>> > pure metallic sodium I keep safely under glycerin in a glass bottle on
>> > my
>> > shelf. This is a clever ontological device which makes a bunch of
>> > inferences
>> > very slick in Cyc, but I bet its not the same *idea* of sodium that most
>> > ontologies would agree with. So that sameAs ought to be (and it is
>> > understood as meaning) 'same chemical element', but it does not allow
>> > mutual
>> > substitutivity, even if you were to translate those other ontologies
>> > into
>> > CycL, which nobody is ever likely to do.
>>
>> My gut reaction is that URIs ought to be names that refer, and that
>> sense ought to be conveyed more explicitly as statements. That seems
>> to be the basis of the model theory that underlies the semweb
>> languages (yes, I realize that there's currently room for 2+ different
>> referencings using the same name). I realize that in natural language
>> name can carry both sense and reference (or let's just say "more than
>> reference" since there seem to be a number of theories of exactly what
>> goes on with words). But it seems that it's been at least a hundred
>> years that relatively modern philosophers have been hacking away at
>> trying to understand exactly what the phenomena are, and how to
>> understand them. Should we really try to adopt exactly the same model
>> as language, given that we don't really understand it?
>>
>> In your sodium example, i don't really know what to do with the "idea
>> of sodium" being the same or different, but I *can* say that a
>> molecule of sodium is not the same sort of thing as a lump of sodium
>> metal. They have different physical properties and some things that
>> make sense to say about one don't make sense to say about the other
>> (like the melting point of xxx is 370.87 K).
>
> For what it's worth, Cyc does not generally consider individual molecules of
> a substance to be instances of that substance. For example, "iodine
> molecule"
> (http://sw.opencyc.org/concept/Mx8Ngh4rwPzt4pwpEbGdrcN5Y29ycB4rvVj8dJwpEbGdrcN5Y29ycA)
> is not a subclass of "iodine"
> (http://sw.opencyc.org/concept/Mx4rvVj8dJwpEbGdrcN5Y29ycA).
>
> David

Thanks for pointing that out! Which one, if either, do you think is
sameAs http://dbpedia.org/resource/Iodine (only one of them is
according to sameAs.org.

As an aside, another amusing sameAs in that family is

http://dbpedia.org/resource/Iodine

Iodine, is a chemical element that has the symbol I and atomic number
53. Naturally-occurring iodine is a single isotope with 74 neutrons...

http://dbpedia.org/resource/Iodo

Iodo may refer to; Socotra Rock Iodo (film), South Korean film
directed by Kim Ki-young Iodine, chemical element...

ref:

http://sameas.org/html?uri=http%3A%2F%2Fdbpedia.org%2Fresource%2FIodine&x=0&y=0

I mean no slight to the intentions of creating the sameAs resource
but, realistically, pretty much anywhere you look there are
substantive errors.

-Alan

>
>>
>> Now you might say: Well, they are the same *concept*. But what am I to
>> do with that? What can I conclude from that statement. Isn't it
>> throwing a whole lot under the rug to lump all these sorts of
>> relations into any single "same" bucket? And for what good? Google is
>> pretty good at bringing all these different sorts of things together
>> already - shouldn't the semweb stuff be doing something different?
>>
>> -Alan
>> (who's been reading and puzzling too many days in a row about how
>> words relate to ... everything)
>>
>> > On Jul 21, 2009, at 7:58 PM, Pat Hayes wrote:
>> >
>> >>
>> >> On Jul 21, 2009, at 7:26 PM, Alan Ruttenberg wrote:
>> >>
>> >>> On Tue, Jul 21, 2009 at 1:23 PM, Toby Inkster wrote:
>> 
>>  On Tue, 2009-07-21 at 19:52 +0300, Bernhard Schandl wrote:
>> 
>> >> I would say: Never assert sameAs. It's just too big a hammer.
>> >> Instead use a wider palette of relationships to connect entities
>> >> to other ones.
>> >
>> > which ones would you recommend?
>> 
>>  skos:exactMatch = asserts that the two resources represent the same
>>  concept
>> >>
>> >> Say, refer to the same thing.
>> >>
>>  , but does not assert that all triples containing the first
>>  resource are necessarily true when the second resource is substituted
>>  in.
>> >>>
>> >>> I'm having trouble parsing this one. I don't know what concepts are,
>> >>> but they are an odd sort of thing if they can be the same, but can't
>> >>> be substituted.
>> >>
>> >> This is exactly what is need

Re: Merging Databases

[Alan Ruttenberg]

As a constructive suggestion, an incremental improvement to sameAs.org
would be to systematically eradicate any references to dbpedia entries
that are disambiguation pages on wikipedia.

-Alan

On Fri, Jul 24, 2009 at 11:26 AM, Alan
Ruttenberg wrote:
> On Fri, Jul 24, 2009 at 11:11 AM, David Baxter wrote:
>>
>>
>> On Tue, Jul 21, 2009 at 8:43 PM, Alan Ruttenberg 
>> wrote:
>>>
>>> On Tue, Jul 21, 2009 at 9:22 PM, Pat Hayes wrote:
>>> > Heres another example. Cyc lists all the chemical elements, and
>>> > cross-links
>>> > to other such lists in other ontologies using owl:sameAs. But the Cyc
>>> > ontology says that an element is the set (class) of all pieces of the
>>> > pure
>>> > element, so that for example sodium in Cyc has a member which is the
>>> > lump of
>>> > pure metallic sodium I keep safely under glycerin in a glass bottle on
>>> > my
>>> > shelf. This is a clever ontological device which makes a bunch of
>>> > inferences
>>> > very slick in Cyc, but I bet its not the same *idea* of sodium that most
>>> > ontologies would agree with. So that sameAs ought to be (and it is
>>> > understood as meaning) 'same chemical element', but it does not allow
>>> > mutual
>>> > substitutivity, even if you were to translate those other ontologies
>>> > into
>>> > CycL, which nobody is ever likely to do.
>>>
>>> My gut reaction is that URIs ought to be names that refer, and that
>>> sense ought to be conveyed more explicitly as statements. That seems
>>> to be the basis of the model theory that underlies the semweb
>>> languages (yes, I realize that there's currently room for 2+ different
>>> referencings using the same name). I realize that in natural language
>>> name can carry both sense and reference (or let's just say "more than
>>> reference" since there seem to be a number of theories of exactly what
>>> goes on with words). But it seems that it's been at least a hundred
>>> years that relatively modern philosophers have been hacking away at
>>> trying to understand exactly what the phenomena are, and how to
>>> understand them. Should we really try to adopt exactly the same model
>>> as language, given that we don't really understand it?
>>>
>>> In your sodium example, i don't really know what to do with the "idea
>>> of sodium" being the same or different, but I *can* say that a
>>> molecule of sodium is not the same sort of thing as a lump of sodium
>>> metal. They have different physical properties and some things that
>>> make sense to say about one don't make sense to say about the other
>>> (like the melting point of xxx is 370.87 K).
>>
>> For what it's worth, Cyc does not generally consider individual molecules of
>> a substance to be instances of that substance. For example, "iodine
>> molecule"
>> (http://sw.opencyc.org/concept/Mx8Ngh4rwPzt4pwpEbGdrcN5Y29ycB4rvVj8dJwpEbGdrcN5Y29ycA)
>> is not a subclass of "iodine"
>> (http://sw.opencyc.org/concept/Mx4rvVj8dJwpEbGdrcN5Y29ycA).
>>
>> David
>
> Thanks for pointing that out! Which one, if either, do you think is
> sameAs http://dbpedia.org/resource/Iodine (only one of them is
> according to sameAs.org.
>
> As an aside, another amusing sameAs in that family is
>
> http://dbpedia.org/resource/Iodine
>
> Iodine, is a chemical element that has the symbol I and atomic number
> 53. Naturally-occurring iodine is a single isotope with 74 neutrons...
>
> http://dbpedia.org/resource/Iodo
>
> Iodo may refer to; Socotra Rock Iodo (film), South Korean film
> directed by Kim Ki-young Iodine, chemical element...
>
> ref:
>
> http://sameas.org/html?uri=http%3A%2F%2Fdbpedia.org%2Fresource%2FIodine&x=0&y=0
>
> I mean no slight to the intentions of creating the sameAs resource
> but, realistically, pretty much anywhere you look there are
> substantive errors.
>
> -Alan
>
>>
>>>
>>> Now you might say: Well, they are the same *concept*. But what am I to
>>> do with that? What can I conclude from that statement. Isn't it
>>> throwing a whole lot under the rug to lump all these sorts of
>>> relations into any single "same" bucket? And for what good? Google is
>>> pretty good at bringing all these different sorts of things together
>>> already - shouldn't the semweb stuff be doing something different?
>>>
>>> -Alan
>>> (who's been reading and puzzling too many days in a row about how
>>> words relate to ... everything)
>>>
>>> > On Jul 21, 2009, at 7:58 PM, Pat Hayes wrote:
>>> >
>>> >>
>>> >> On Jul 21, 2009, at 7:26 PM, Alan Ruttenberg wrote:
>>> >>
>>> >>> On Tue, Jul 21, 2009 at 1:23 PM, Toby Inkster wrote:
>>> 
>>>  On Tue, 2009-07-21 at 19:52 +0300, Bernhard Schandl wrote:
>>> 
>>> >> I would say: Never assert sameAs. It's just too big a hammer.
>>> >> Instead use a wider palette of relationships to connect entities
>>> >> to other ones.
>>> >
>>> > which ones would you recommend?
>>> 
>>>  skos:exactMatch = asserts that the two resources represent the same
>>>  concept
>>> >>
>>> >> Say, refer to the same thing.
>>> >

Re: Merging Databases

[David Baxter]

On Tue, Jul 21, 2009 at 8:43 PM, Alan Ruttenberg
wrote:

> On Tue, Jul 21, 2009 at 9:22 PM, Pat Hayes wrote:
> > Heres another example. Cyc lists all the chemical elements, and
> cross-links
> > to other such lists in other ontologies using owl:sameAs. But the Cyc
> > ontology says that an element is the set (class) of all pieces of the
> pure
> > element, so that for example sodium in Cyc has a member which is the lump
> of
> > pure metallic sodium I keep safely under glycerin in a glass bottle on my
> > shelf. This is a clever ontological device which makes a bunch of
> inferences
> > very slick in Cyc, but I bet its not the same *idea* of sodium that most
> > ontologies would agree with. So that sameAs ought to be (and it is
> > understood as meaning) 'same chemical element', but it does not allow
> mutual
> > substitutivity, even if you were to translate those other ontologies into
> > CycL, which nobody is ever likely to do.
>
> My gut reaction is that URIs ought to be names that refer, and that
> sense ought to be conveyed more explicitly as statements. That seems
> to be the basis of the model theory that underlies the semweb
> languages (yes, I realize that there's currently room for 2+ different
> referencings using the same name). I realize that in natural language
> name can carry both sense and reference (or let's just say "more than
> reference" since there seem to be a number of theories of exactly what
> goes on with words). But it seems that it's been at least a hundred
> years that relatively modern philosophers have been hacking away at
> trying to understand exactly what the phenomena are, and how to
> understand them. Should we really try to adopt exactly the same model
> as language, given that we don't really understand it?
>
> In your sodium example, i don't really know what to do with the "idea
> of sodium" being the same or different, but I *can* say that a
> molecule of sodium is not the same sort of thing as a lump of sodium
> metal. They have different physical properties and some things that
> make sense to say about one don't make sense to say about the other
> (like the melting point of xxx is 370.87 K).


For what it's worth, Cyc does not generally consider individual molecules of
a substance to be instances of that substance. For example, "iodine
molecule" (
http://sw.opencyc.org/concept/Mx8Ngh4rwPzt4pwpEbGdrcN5Y29ycB4rvVj8dJwpEbGdrcN5Y29ycA)
is not a subclass of "iodine" (
http://sw.opencyc.org/concept/Mx4rvVj8dJwpEbGdrcN5Y29ycA).

David


>
>
> Now you might say: Well, they are the same *concept*. But what am I to
> do with that? What can I conclude from that statement. Isn't it
> throwing a whole lot under the rug to lump all these sorts of
> relations into any single "same" bucket? And for what good? Google is
> pretty good at bringing all these different sorts of things together
> already - shouldn't the semweb stuff be doing something different?
>
> -Alan
> (who's been reading and puzzling too many days in a row about how
> words relate to ... everything)
>
> > On Jul 21, 2009, at 7:58 PM, Pat Hayes wrote:
> >
> >>
> >> On Jul 21, 2009, at 7:26 PM, Alan Ruttenberg wrote:
> >>
> >>> On Tue, Jul 21, 2009 at 1:23 PM, Toby Inkster wrote:
> 
>  On Tue, 2009-07-21 at 19:52 +0300, Bernhard Schandl wrote:
> 
> >> I would say: Never assert sameAs. It's just too big a hammer.
> >> Instead use a wider palette of relationships to connect entities
> >> to other ones.
> >
> > which ones would you recommend?
> 
>  skos:exactMatch = asserts that the two resources represent the same
>  concept
> >>
> >> Say, refer to the same thing.
> >>
>  , but does not assert that all triples containing the first
>  resource are necessarily true when the second resource is substituted
>  in.
> >>>
> >>> I'm having trouble parsing this one. I don't know what concepts are,
> >>> but they are an odd sort of thing if they can be the same, but can't
> >>> be substituted.
> >>
> >> This is exactly what is needed in many cases. Philosophical terminology
> is
> >> that they have the same referent but not the same sense, and lack of
> >> substitutability reflects the unfortunate but inevitable fact that the
> Web
> >> as a whole is not referentially transparent (yet). More mundane example,
> the
> >> same person might need to be referred to in one way in one context and
> >> differently in another, just because the two social contexts require
> >> different forms of address. (That example from Lynn Stein.)
> >>
> >>> In any case, this isn't much better when the issue I point out is that
> >>> there is a specific relation between e.g. the intervention and the
> >>> drug - that relation is no where near equivalence in any form.
> >>
> >> True, but in cases like this, it is simply a basic conceptual mistake to
> >> be using any kind of loose-sameAs property. rdf:seeAlso would be more
> like
> >> what is needed for linking a drug to an intervention. I agre

Re: Merging Databases

[David Baxter]

On Mon, Jul 20, 2009 at 3:31 PM, Kingsley Idehen wrote:

> Hugh Glaser wrote:
>
>> Excellent Alan, thank you for pointing this out, both as a general point
>> and the specific case.
>> I had puzzled over the equivalences, since they seemed implausible (just
>> given the number), but not worked out why (I guess the lack of the backlink
>> did not help).
>> However they, along with good stuff, came from a source I chose to trust,
>> and so I went with it.
>> The caveat is useful in general - I know of other sameas that I might
>> consider erroneous/dubious but are widely accepted.
>> Another example would be the sameas between the opencyc URIs and the
>> dbpedia ones, although things of different type, which was a topic of
>> discussion on this list a while ago.
>>
>>
> Hugh,
>
> Yes, the links between OpenCyc and DBpedia are an issue.
>
> Larry/David: did you receive the mail (private) that I sent a while back
> about this?


Yes, I sent you a reply, basically asking for clarification of the issue.

David



>
>
> [SNIP]
>
>
> --
>
>
> Regards,
>
> Kingsley Idehen   Weblog: 
> http://www.openlinksw.com/blog/~kidehen
> President & CEO OpenLink Software Web: http://www.openlinksw.com
>
>
>
>
>

Re: Alternatives to OWL for linked data?

[Axel Rauschmayer]

Thanks, looks interesting. I've also found related work:
https://www.uni-koblenz-landau.de/koblenz/fb4/institute/IFI/AGStaab/Research/systeme/NetworkedGraphs/

But there does not seem to be a library one can use with, say, Sesame.

On Jul 24, 2009, at 15:43 , Martin Hepp (UniBW) wrote:


Did you look at SPIN?

http://spinrdf.org/

That should allow you do do a lot with data without leaving the now  
mainstream Semantic Web technology stack (as long as a small  
fragment of OWL is sufficient for you).


Best
Martin


Axel Rauschmayer wrote:
I'm currently reading Hendler's brilliant book "Semantic Web for  
the Working Ontologist". It really drove home the point that OWL is  
not a good fit when using RDF for *data* (names are generally not  
unique, open world assumption, ...).


But what is the alternative? For my applications, I have the  
following requirements:


- Properties: transitivity, inverse, sub-properties.
- Resources, classes: equivalence. For my purposes, equivalence is  
a way of implementing the topic merging in topic maps [1].

- Constraints for integrity checking.
- Schema declaration: partially overlaps with constraints, serves  
for documentation and for providing default values for properties.
- Computed property values: for example, one property value being  
the concatenation of two other property values etc.


The difficulty seems to me to find something universal that  
fulfills these requirements and is still easy to understand.  
Inference, when used for transitivity and equivalence, is simple,  
but when it comes to editing RDF, they can confound the user: Why  
can some triples be replaced, others not? Why do I have to replace  
the triples of a different instance if I want to replace the  
triples in my instance?


While it's not necessarily easier to understand for end users, I've  
always found Prolog easy to understand, where OWL is more of a  
challenge.


So what solutions are out there? I would prefer description logic  
programming to OWL. Does Prolog-like backward-chaining make sense  
for RDF? If so, how would it be combined with SPARQL; or would it  
replace it? Or maybe something frame-based?


Am I making sense? I would appreciate any pointers, hints and  
insights.


Axel

[1] http://www.topicmaps.org/xtm/index.html#desc-merging



--
--
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  mh...@computer.org
phone:   +49-(0)89-6004-4217
fax: +49-(0)89-6004-4620
www: http://www.unibw.de/ebusiness/ (group)
   http://www.heppnetz.de/ (personal)
skype:   mfhepp twitter: mfhepp

Check out GoodRelations for E-Commerce on the Web of Linked Data!
=

Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/

Recipe for Yahoo SearcMonkey:
http://tr.im/rAbN

Talk at the Semantic Technology Conference 2009: "Semantic Web-based  
E-Commerce: The GoodRelations Ontology"

http://tinyurl.com/semtech-hepp

Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe

Project page:
http://purl.org/goodrelations/

Resources for developers:
http://www.ebusiness-unibw.org/wiki/GoodRelations

Tutorial materials:
CEC'09 2009 Tutorial: The Web of Data for E-Commerce: A Hands-on  
Introduction to the GoodRelations Ontology, RDFa, and Yahoo!  
SearchMonkey http://tr.im/grcec09





--
axel.rauschma...@ifi.lmu.de
http://www.pst.ifi.lmu.de/~rauschma/

Re: Alternatives to OWL for linked data?

[Adrian Walker]

Hi Axel --

I believe that the Executable English / Internet Business Logic system
covers most, and possibly all, of the requirements that you list.

There's an overview paper [1], and plenty of starter examples such as [2-4]
.

The system is online [5], can be used either from a browser or as part of an
SOA [6], and shared use is free.

Apologies to folks on the list who may have seen this before, and thanks for
comments.

   -- Adrian

[1]
www.reengineeringllc.com/A_Wiki_for_Business_Rules_in_Open_Vocabulary_Executable_English.pdf

[2] www.reengineeringllc.com/demo_agents/RDFQueryLangComparison1.agent

[3]www.reengineeringllc.com/demo_agents/OwlTest1.agent

[4]
www.reengineeringllc.com/EnergyIndependence1Video.htm  (Flash video with
audio)

[5] Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English over SQL and
RDF
Online at www.reengineeringllc.comShared use is free

[6]  www.reengineeringllc.com/iblClient1.java

Adrian Walker
Reengineering


On Fri, Jul 24, 2009 at 9:30 AM, Axel Rauschmayer  wrote:

> I'm currently reading Hendler's brilliant book "Semantic Web for the
> Working Ontologist". It really drove home the point that OWL is not a good
> fit when using RDF for *data* (names are generally not unique, open world
> assumption, ...).
>
> But what is the alternative? For my applications, I have the following
> requirements:
>
> - Properties: transitivity, inverse, sub-properties.
> - Resources, classes: equivalence. For my purposes, equivalence is a way of
> implementing the topic merging in topic maps [1].
> - Constraints for integrity checking.
> - Schema declaration: partially overlaps with constraints, serves for
> documentation and for providing default values for properties.
> - Computed property values: for example, one property value being the
> concatenation of two other property values etc.
>
> The difficulty seems to me to find something universal that fulfills these
> requirements and is still easy to understand. Inference, when used for
> transitivity and equivalence, is simple, but when it comes to editing RDF,
> they can confound the user: Why can some triples be replaced, others not?
> Why do I have to replace the triples of a different instance if I want to
> replace the triples in my instance?
>
> While it's not necessarily easier to understand for end users, I've always
> found Prolog easy to understand, where OWL is more of a challenge.
>
> So what solutions are out there? I would prefer description logic
> programming to OWL. Does Prolog-like backward-chaining make sense for RDF?
> If so, how would it be combined with SPARQL; or would it replace it? Or
> maybe something frame-based?
>
> Am I making sense? I would appreciate any pointers, hints and insights.
>
> Axel
>
> [1] http://www.topicmaps.org/xtm/index.html#desc-merging
>
> --
> axel.rauschma...@ifi.lmu.de
> http://www.pst.ifi.lmu.de/~rauschma/
>
>
>
>
>

Re: Alternatives to OWL for linked data?

[Martin Hepp (UniBW)]

Did you look at SPIN?

http://spinrdf.org/

That should allow you do do a lot with data without leaving the now 
mainstream Semantic Web technology stack (as long as a small fragment of 
OWL is sufficient for you).


Best
Martin


Axel Rauschmayer wrote:
I'm currently reading Hendler's brilliant book "Semantic Web for the 
Working Ontologist". It really drove home the point that OWL is not a 
good fit when using RDF for *data* (names are generally not unique, 
open world assumption, ...).


But what is the alternative? For my applications, I have the following 
requirements:


- Properties: transitivity, inverse, sub-properties.
- Resources, classes: equivalence. For my purposes, equivalence is a 
way of implementing the topic merging in topic maps [1].

- Constraints for integrity checking.
- Schema declaration: partially overlaps with constraints, serves for 
documentation and for providing default values for properties.
- Computed property values: for example, one property value being the 
concatenation of two other property values etc.


The difficulty seems to me to find something universal that fulfills 
these requirements and is still easy to understand. Inference, when 
used for transitivity and equivalence, is simple, but when it comes to 
editing RDF, they can confound the user: Why can some triples be 
replaced, others not? Why do I have to replace the triples of a 
different instance if I want to replace the triples in my instance?


While it's not necessarily easier to understand for end users, I've 
always found Prolog easy to understand, where OWL is more of a challenge.


So what solutions are out there? I would prefer description logic 
programming to OWL. Does Prolog-like backward-chaining make sense for 
RDF? If so, how would it be combined with SPARQL; or would it replace 
it? Or maybe something frame-based?


Am I making sense? I would appreciate any pointers, hints and insights.

Axel

[1] http://www.topicmaps.org/xtm/index.html#desc-merging



--
--
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  mh...@computer.org
phone:   +49-(0)89-6004-4217
fax: +49-(0)89-6004-4620
www: http://www.unibw.de/ebusiness/ (group)
http://www.heppnetz.de/ (personal)
skype:   mfhepp 
twitter: mfhepp


Check out GoodRelations for E-Commerce on the Web of Linked Data!
=

Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/

Recipe for Yahoo SearcMonkey:
http://tr.im/rAbN

Talk at the Semantic Technology Conference 2009: 
"Semantic Web-based E-Commerce: The GoodRelations Ontology"

http://tinyurl.com/semtech-hepp

Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe

Project page:
http://purl.org/goodrelations/

Resources for developers:
http://www.ebusiness-unibw.org/wiki/GoodRelations

Tutorial materials:
CEC'09 2009 Tutorial: The Web of Data for E-Commerce: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey 
http://tr.im/grcec09


begin:vcard
fn:Martin Hepp
n:Hepp;Martin
org:Bundeswehr University Munich;E-Business and Web Science Research Group
adr:;;Werner-Heisenberg-Web 39;Neubiberg;;D-85577;Germany
email;internet:mh...@computer.org
tel;work:+49 89 6004 4217
tel;pager:skype: mfhepp
url:http://www.heppnetz.de
version:2.1
end:vcard

Alternatives to OWL for linked data?

[Axel Rauschmayer]

I'm currently reading Hendler's brilliant book "Semantic Web for the  
Working Ontologist". It really drove home the point that OWL is not a  
good fit when using RDF for *data* (names are generally not unique,  
open world assumption, ...).


But what is the alternative? For my applications, I have the following  
requirements:


- Properties: transitivity, inverse, sub-properties.
- Resources, classes: equivalence. For my purposes, equivalence is a  
way of implementing the topic merging in topic maps [1].

- Constraints for integrity checking.
- Schema declaration: partially overlaps with constraints, serves for  
documentation and for providing default values for properties.
- Computed property values: for example, one property value being the  
concatenation of two other property values etc.


The difficulty seems to me to find something universal that fulfills  
these requirements and is still easy to understand. Inference, when  
used for transitivity and equivalence, is simple, but when it comes to  
editing RDF, they can confound the user: Why can some triples be  
replaced, others not? Why do I have to replace the triples of a  
different instance if I want to replace the triples in my instance?


While it's not necessarily easier to understand for end users, I've  
always found Prolog easy to understand, where OWL is more of a  
challenge.


So what solutions are out there? I would prefer description logic  
programming to OWL. Does Prolog-like backward-chaining make sense for  
RDF? If so, how would it be combined with SPARQL; or would it replace  
it? Or maybe something frame-based?


Am I making sense? I would appreciate any pointers, hints and insights.

Axel

[1] http://www.topicmaps.org/xtm/index.html#desc-merging

--
axel.rauschma...@ifi.lmu.de
http://www.pst.ifi.lmu.de/~rauschma/

Re: [Dbpedia-discussion] pagelinks not loaded @ dbpedia.org?

[Kingsley Idehen]

John Muth wrote:

Hi Kingsley,

That would be much appreciated.

Regards,
John
  

John,

DBpedia instance now has the PageLinks data loaded. The Graph IRI is: 



Sample HTML metadata explorer page (note: original de-referencable URIs 
is exposed via value of @href component of hyperlink re. "About: 
some-entity-in-this-data-space":

http://tr.im/tQeM

Sample SPARQL Query:
select * from  { 
 ?p ?o


Kingsley

On 14/7/09 21:56, "Kingsley Idehen"  wrote:

  

John Muth wrote:


Greetings DBpedia people,

Is it true that the pagelinks dataset is not currently loaded into the
Virtuoso instance at http://dbpedia.org/sparql?

If so, is there any reason for that?  If it's just because nobody has asked
for it, can I ask for it?

I'm assuming it isn't loaded because I get nothing for this (for example):

select * WHERE {
  
?wikilink .
}

Thanks,
John





  

->>
-
  

Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
___
Dbpedia-discussion mailing list
dbpedia-discuss...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion

  
  

John,

To reduce the impact on others we can put this in a separate graph using
IRI: , thus you will have to explicity
reference this named graph in conjunction with  when
seeking the aforementioned data via SPARQL.




  



--


Regards,

Kingsley Idehen   Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software Web: http://www.openlinksw.com

Re: [Ann] LinkedGeoData.org

[Kingsley Idehen]

Sören Auer wrote:

Ian Davis wrote:

Very nice. How long do you think it will take for the entire dataset
to be available?


The complete OSM dataset amounting roughly 3B triples is now available 
from:


http://linkedgeodata.org/Datasets

As already noted earlier, however, for most use cases the LGD Elements 
dataset might be the more interesting and manageable one.


--Sören



Soren,

LGD crosslinks to DBpedia have now been added to the DBpedia 3.3 
instance. Re. SPARQL endpoint the Graph IRI: 


The complete LGD dump is currently being loading into the LOD Cloud 
Cache instance at: http://lod.openlinksw.com. The graph IRI will be the 
same as above. This instance is where you get the richest experience 
since all the data will be locally accessible while exposing a URI to 
original source via the value of @href associated with text pattern 
"xx"  in "About: xxx" re. our HTML based metadata explorer pages.


Example Metadata Explorer page; http://tr.im/tQcM

Example Query:

select * from  { 
 ?p ?o }


--


Regards,

Kingsley Idehen   Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software Web: http://www.openlinksw.com