date:20110612

OK, I am now completely and utterly lost. I have no idea what you are saying or 
how any of it is relevant to the http-range-14 issue. Want to try running it 
past me again? Bear in mind that I do not accept your claim that a description 
of something is in any useful sense isomorphic to the thing it describes. As 
in, some RDF describing, say, the Eiffel tower is not in any way isomorphic to 
the actual tower. (I also do not understand why you think this claim matters, 
by the way.) 

Perhaps we are understanding the meaning of http-range-14 differently. My 
understanding of it is as follows: if an HTTP GET applied to a bare URI http:x 
returns a 200 response, then http:x is understood to refer to (to be a name 
for, to denote) the resource that emitted the response. Hence, it follows that 
if a URI is intended to refer to something else, it has to emit a different 
response, and a 303 redirect is appropriate. It also follows that in the 200 
case, the thing denoted has to be the kind of thing that can possibly emit an 
HTTP response, thereby excluding a whole lot of things, such as dogs, from 
being the referent in such cases.

Pat

On Jun 12, 2011, at 6:46 PM, Danny Ayers wrote:

> On 13 June 2011 02:28, Pat Hayes  wrote:
> 
>> Next point: there can indeed be correspondences between the syntactic 
>> structure of a description and the aspects of reality it describes.
> 
> That is what I was calling isomorphism (which I still don't think was
> inaccurate). But ok, say there are correspondences instead. I would
> suggest that those correspondences are enough to allow the description
> to take the place of a representation under HTTP definitions.
> 
>> But I don't think all this is really germane to the http-range-14 issue. The 
>> point there is, does the URI refer to something like a representation 
>> (information resource, website, document, RDF graph, whatever) or something 
>> which definitely canNOT be sent over a wire?
> 
> I'm saying conceptually it doesn't matter if you can put it over the
> wire or not.
> 
>>> But replace "a novel written by a dog" for "dog" in the above. Why
>>> should the concept of a document be fundamentally any different from
>>> the concept of a dog, hence representations of a document and
>>> representations of a dog?
>> 
>> I dont follow your point here. If you mean, a document is just as real as a 
>> dog, I agree. So?  But if you mean, there is no basic difference between a 
>> document and a dog, I disagree. And so does my cat.
> 
> Difference sure, but not necessarily relevant.
> 
>>> Ok, you can squeeze something over the wire
>>> that represents  "a novel written by a dog" but you (probably) can't
>>> squeeze a "dog" over, but that's just a limitation of the protocol.
>> 
>> So improved software engineering will enable us to teleport dogs over the 
>> internet? Come on, you don't actually believe this.
> 
> It would save a lot of effort sometimes (walkies!) but all I'm
> suggesting is that if, hypothetically, you could teleport matter over
> the internet, all you'd be looking at as far as http-range-14 is
> concerned is another media type. Working back from there, and given
> correspondences as above, a descriptive document can be a valid
> representation of the identified resource even if it happens to be an
> actual thing, given that there isn't necessary any "one true"
> representation. We don't need the Information Resource distinction
> here (useful elsewhere maybe).
> 
> Cheers,
> Danny.
> 
> -- 
> http://danny.ayers.name
> 

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: Using Facebook Data Objects to illuminate Linked Data add-on re. structured data

2011-06-12 Thread glenn mcdonald

>
> {
>   "id": "605980750",
>   "name": "Kingsley Uyi Idehen",
>   "first_name": "Kingsley",
>   "middle_name": "Uyi",
>   "last_name": "Idehen",
>   "link": "https://www.facebook.com/kidehen";,
>   "username": "kidehen",
>   "gender": "male",
>   "locale": "en_US"
> }
>
> Some observations:
>
> "id" attribute has value "605980750", this value means little on its own
> outside Facebook's data space.
>

But add an @base and it would be totally fine. It's a relative ID. And it's
better, I contend, than your proposed https://www.facebook.com/kidehen#this,
because it doesn't rely on your username staying the same, or http/https, or
this hash/slash/query minutia or even facebook.com remaining the domain
name!

Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]

On 13 June 2011 02:28, Pat Hayes  wrote:

> Next point: there can indeed be correspondences between the syntactic 
> structure of a description and the aspects of reality it describes.

That is what I was calling isomorphism (which I still don't think was
inaccurate). But ok, say there are correspondences instead. I would
suggest that those correspondences are enough to allow the description
to take the place of a representation under HTTP definitions.

> But I don't think all this is really germane to the http-range-14 issue. The 
> point there is, does the URI refer to something like a representation 
> (information resource, website, document, RDF graph, whatever) or something 
> which definitely canNOT be sent over a wire?

I'm saying conceptually it doesn't matter if you can put it over the
wire or not.

>> But replace "a novel written by a dog" for "dog" in the above. Why
>> should the concept of a document be fundamentally any different from
>> the concept of a dog, hence representations of a document and
>> representations of a dog?
>
> I dont follow your point here. If you mean, a document is just as real as a 
> dog, I agree. So?  But if you mean, there is no basic difference between a 
> document and a dog, I disagree. And so does my cat.

Difference sure, but not necessarily relevant.

>> Ok, you can squeeze something over the wire
>> that represents  "a novel written by a dog" but you (probably) can't
>> squeeze a "dog" over, but that's just a limitation of the protocol.
>
> So improved software engineering will enable us to teleport dogs over the 
> internet? Come on, you don't actually believe this.

It would save a lot of effort sometimes (walkies!) but all I'm
suggesting is that if, hypothetically, you could teleport matter over
the internet, all you'd be looking at as far as http-range-14 is
concerned is another media type. Working back from there, and given
correspondences as above, a descriptive document can be a valid
representation of the identified resource even if it happens to be an
actual thing, given that there isn't necessary any "one true"
representation. We don't need the Information Resource distinction
here (useful elsewhere maybe).

Cheers,
Danny.

-- 
http://danny.ayers.name

Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]

On Jun 12, 2011, at 4:13 PM, Danny Ayers wrote:

>>> (there will be some isomorphism between a thing and a description of a
>>> thing, right?
>> 
>> Absolutely not. Descriptions are not in any way isomorphic to the things 
>> they describe. (OK, some 'diagrammatic' representations can be claimed to 
>> be, eg in cartography, but even those cases don't stand up to careful 
>> analysis. in fact.)
> 
> Beh! Some isomorphism is all I ask for. Take your height and shoe size
> - those numeric descriptions will correspond 1:1 with aspects of the
> reality. Keep going to a waxwork model of you, the path you walked in
> the park this afternoon - are you suggesting there's no isomorphism?

Yes, in fact I am *denying* there is *any* isomorphism. What structures are you 
intending to appeal to when you say 'isomorphic'? Do you see reality as being 
some kind of giant category? Or what?  

Lets suppose that the interpretation/denotation/semantic/reference mapping goes 
from the representation to the reality. (Since its an isomorphism, it should be 
invertible, so this is an arbitrary choice, right?) Call this mapping ref, so X 
ref Y means that Y is one way reality might be assuming X is true, when X is 
used as a representation. First point: for descriptions, ref is a Galois 
mapping, which means that when X gets larger - when the representation says 
more about the reality - then Y, the number of ways that the reality can be, 
gets smaller. The more you say, the more tightly you constrain the ways the 
world can be. This is exactly the opposite from how an isomorphism would 
behave. 

Next point: there can indeed be correspondences between the syntactic structure 
of a description and the aspects of reality it describes. Your example of the 
path I walked would be one, if you were to draw the path on an accurate map. 
But this is completely hostage to the map being **accurate**. If I used a 
not-to-scale sketch map, then no, you don't get isomorphism. Yet it seems to me 
that these two cases, the real map and a sketch map, both seem to work in the 
same kind of semantic way. So this explanation of how they work cannot depend 
on there being an isomorphism. Maybe there is a kind of homomorphism, but even 
that is kind of hard to make work. What it seems to be is more like, the map 
projection function is a homomorphism of the entire mapped terrain, and then 
marks or symbols on the map indicate terrain location by inverting this 
projection morphism and asserting an existential to the effect that the thing 
described is contained in that back-projected space in the terrain from space 
occupied by the mark or symbol in the map space. 

But I don't think all this is really germane to the http-range-14 issue. The 
point there is, does the URI refer to something like a representation 
(information resource, website, document, RDF graph, whatever) or something 
which definitely canNOT be sent over a wire? 

> 
>> ** To illustrate. Someone goes to a website about dogs, likes one of the 
>> dogs, and buys it on-line. He goes to collect the dog, the shopkeeper gives 
>> him a photograph of the dog. Um, Where is the dog? Right there, says the 
>> seller, pointing to the photograph. That isn't good enough. The seller 
>> mutters a bit, goes into the back room, comes back with a much larger, 
>> crisper, glossier picture, says, is that enough of the dog for you? But the 
>> customer still isn't satisfied. The seller finds a flash card with an 
>> hour-long HD movie of the dog, and even offers, if the customer is willing 
>> to wait a week or two, to have a short novel written by a well-known author 
>> entirely about the dog. But the customer still isn't happy. The seller is at 
>> his wits end, because he just doesn't know how to satisfy this customer. 
>> What else can I do? He asks. I don't have any better representations of the 
>> dog than these. So the customer says, look, I want the *actual dog*, not a 
>> representation of a dog. Its not a matter of getting me more information 
>> about the dog; I want the actual, smelly animal. And the seller says, what 
>> do you mean,  an "actual dog"? We just deal in **representations** of dogs. 
>> There's no such thing as an actual dog. Surely you knew that when you looked 
>> at our website?
> 
> Lovely imagery, thanks Pat.
> 
> But replace "a novel written by a dog" for "dog" in the above. Why
> should the concept of a document be fundamentally any different from
> the concept of a dog, hence representations of a document and
> representations of a dog?

I dont follow your point here. If you mean, a document is just as real as a 
dog, I agree. So?  But if you mean, there is no basic difference between a 
document and a dog, I disagree. And so does my cat. 

> Ok, you can squeeze something over the wire
> that represents  "a novel written by a dog" but you (probably) can't
> squeeze a "dog" over, but that's just a limitation of the protocol.

So improved software engineering will

Re: Schema.org in RDF ...

2011-06-12 Thread Jiří Procházka

On 06/12/2011 08:19 PM, Richard Cyganiak wrote:
> Hi Danny,
> 
> On 12 Jun 2011, at 17:57, Danny Ayers wrote:
>>> We explicitly know the “expected types” of properties, and I'd like to keep 
>>> that information in a structured form rather than burying it in prose. As 
>>> far as I can see, rdfs:range is the closest available term in W3C's data 
>>> modeling toolkit, and it *is* correct as long as data publishers use the 
>>> terms with the “expected type.”
>>
>> I don't think it is that close to "expected type"
> 
> I didn't say it's close to “expected type”. I said that we want to keep the 
> information in a structured form, and that rdfs:range is the closest 
> construct available in the W3C toolkit.

Hi,
Why not make a new property for such loose semantics (and make
rdfs:range subproperty of it)?
Surely we didn't go out of way to have great flexibility, compared to
controlled vocabularies, for nothing...

>> <#something> :hasColour <#wet> .
>>
>> then we get
>>
>> <#wet> a :Colour .
> 
> If you apply RDFS/OWL reasoning to broken data, you get more broken data. I 
> don't understand why anyone would be surprised by that.

I am surprised someone wants to publish broken data.

Best,
Jiri



signature.asc
Description: OpenPGP digital signature

Re: Schema.org in RDF ...


On Jun 12, 2011, at 11:12 AM, Richard Cyganiak wrote:

> On 12 Jun 2011, at 18:34, Pat Hayes wrote:
 What do we say when the range of a property is supposed to be, say, 
 people, but its considered OK to insert a string to stand in place of the 
 person?
>>> 
>>> Well, I can define a class that contains both people (in the foaf:Person 
>>> sense) and names of people (that is, string literals).
>> 
>> Of course. But you didn't, did you? You (that is, Schema.org) said that the 
>> range of the property was one of these and NOT the other. Which is what I 
>> was complaining about.
> 
> Where is it said that the range is one and not the other?

Well, if you say the range is xsd:string, then anything which is a value has to 
be a string, right? As for example (taken at random)

schema:cookingMethod a rdf:Property;
rdfs:label "Cooking Method"@en;
rdfs:comment "The method of cooking, such as Frying, Steaming, ..."@en;
rdfs:domain schema:Recipe;
rdfs:range xsd:string;
rdfs:isDefinedBy ;

This says that the range is xsd:string, so nothing other than an xsd string 
will be acceptable here.

Am I missing something? 

Pat

> 
> Citing from the schema.rdfs.org FAQ [1], which has the same answer I gave 
> earlier here in the thread:
> 
>>> Q: Schema.org documentation explicitly say that you can use a text instead 
>>> of a Thing/Person/other type, why is this not reflected in the RDFS?
> 
>>> A: That's ok—we didn't say that schema:Thing is disjoint from literals, so 
>>> you can use a string when the declared range is schema:Person. (We were 
>>> tempted to add “xsd:string rdfs:subClassOf schema:Thing.” to capture this 
>>> bit of the schema.org documentation, but narrowly decided against it.)
> 
> So I think it's all ok.

> 
> Best,
> Richard
> 
> [1] http://schema.rdfs.org/faq.html


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: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]

>> (there will be some isomorphism between a thing and a description of a
>> thing, right?
>
> Absolutely not. Descriptions are not in any way isomorphic to the things they 
> describe. (OK, some 'diagrammatic' representations can be claimed to be, eg 
> in cartography, but even those cases don't stand up to careful analysis. in 
> fact.)

Beh! Some isomorphism is all I ask for. Take your height and shoe size
- those numeric descriptions will correspond 1:1 with aspects of the
reality. Keep going to a waxwork model of you, the path you walked in
the park this afternoon - are you suggesting there's no isomorphism?

> ** To illustrate. Someone goes to a website about dogs, likes one of the 
> dogs, and buys it on-line. He goes to collect the dog, the shopkeeper gives 
> him a photograph of the dog. Um, Where is the dog? Right there, says the 
> seller, pointing to the photograph. That isn't good enough. The seller 
> mutters a bit, goes into the back room, comes back with a much larger, 
> crisper, glossier picture, says, is that enough of the dog for you? But the 
> customer still isn't satisfied. The seller finds a flash card with an 
> hour-long HD movie of the dog, and even offers, if the customer is willing to 
> wait a week or two, to have a short novel written by a well-known author 
> entirely about the dog. But the customer still isn't happy. The seller is at 
> his wits end, because he just doesn't know how to satisfy this customer. What 
> else can I do? He asks. I don't have any better representations of the dog 
> than these. So the customer says, look, I want the *actual dog*, not a 
> representation of a dog. Its not a matter of getting me more information 
> about the dog; I want the actual, smelly animal. And the seller says, what do 
> you mean,  an "actual dog"? We just deal in **representations** of dogs. 
> There's no such thing as an actual dog. Surely you knew that when you looked 
> at our website?

Lovely imagery, thanks Pat.

But replace "a novel written by a dog" for "dog" in the above. Why
should the concept of a document be fundamentally any different from
the concept of a dog, hence representations of a document and
representations of a dog? Ok, you can squeeze something over the wire
that represents  "a novel written by a dog" but you (probably) can't
squeeze a "dog" over, but that's just a limitation of the protocol.
There's equally an *actual* document (as a bunch of bits) and an
*actual* dog (as a bunch of cells).

Cheers,
Danny.

-- 
http://danny.ayers.name

Using Facebook Data Objects to illuminate Linked Data add-on re. structured data

All,

Facebook offers a data space (of the silo variety). Every Object has an
Address (URL) from which you can access its actual Representation in
JSON format.

Example using the URL: http://graph.facebook.com/kidehen:

{
"id": "605980750",
"name": "Kingsley Uyi Idehen",
"first_name": "Kingsley",
"middle_name": "Uyi",
"last_name": "Idehen",
"link": "https://www.facebook.com/kidehen";,
"username": "kidehen",
"gender": "male",
"locale": "en_US"
}

Some observations:

"id" attribute has value "605980750", this value means little on its own
outside Facebook's data space.

Now imagine we tweaked this graph like so:

{
"id": "https://www.facebook.com/kidehen#this";
"name": "Kingsley Uyi Idehen",
"first_name": "Kingsley",
"middle_name": "Uyi",
"last_name": "Idehen",
"link": "https://www.facebook.com/kidehen";,
"username": "kidehen",
"gender": "male",
"locale": "en_US"
}

All of a sudden, I've used a HTTP scheme based hyperlink to introduce a
tiny degree of introspection.

I repeat this exercise for the attributes i.e., Name then using HTTP
scheme URIs, and likewise for values best served by HTTP scheme URIs for
boundlessly extending the object above, courtesy of the InterWeb.

Even if Facebook doesn't buy into my world view re. data objects, my
worldview remains satisfied since I can ingest the FB data objects and
then endow them with the fidelity I via use of URI based Names.

Example Linked Data Resource URL:
http://linkeddata.uriburner.com/about/html/http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen
.

Example Object Name from My Data Space:
http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen
.

A little structured data goes a long way to making what we all seek
happen. Facebook, Google, Microsoft, Yahoo! etc.. have committed to
producing structured data. This commitment is massive and it should be
celebrated since it makes life much easier for everyone that's
interested in Linked Data or the broader Semantic Web vision. They
aren't claiming to deliver anything more than structured data. At this
time, their fundamental goal is to leave Semantic Fidelity matters to
those who are interested in such pursuits, appropriately skilled, and so
motivated.

Regards,

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

Re: Schema.org in RDF ...


On 6/12/11 8:10 PM, Pat Hayes wrote:

Kingsley, Im not exactly sure what you are saying in all this, but... (read on)

On Jun 12, 2011, at 9:49 AM, Kingsley Idehen wrote:


On 6/12/11 3:42 PM, Richard Cyganiak wrote:

On 12 Jun 2011, at 11:12, Alan Ruttenberg wrote:

I've yet to encounter a person who didn't understand the difference between a 
book about Obama and Obama.

This has nothing to do with books about Obama.

It's about the difference between an URI-named resource which can return, say, 
a JSON representation of Obama; and a URI-named resource that *is* Obama. 
Explaining why using the same URI for both of those supposedly breaks the Web 
isn't *quite* that easy.

Best,
Richard


Richard,

It isn't about braking the Web or its AWWW, really. It's about how its always 
been when dealing with data via programs. An Object has:

1. Name
2. Representation Address
3. Actual Representation.

It also has 4. Its actual self, ie the object. In the example above, Obama, the 
living breathing President of the USA. Not a representation or an address of 
any kind, not accessible by HTML in any way, not a piece of information. Still, 
can be referred to by a name, and described by a representation. And this is 
what the whole discussion is about.


Yes it does. I was commenting on the Web Resource specifically, and it 
use as a mechanism for agency via observation subject representation.


As per your comment about self, the whole picture goes something like this:

1. Actual Observation Subject
2. Subject Identifier operating as a Name
3. Medium specific Representation Location (Address)
4. Actual Medium specific Representation.

2-4 collectively deliver observation subject agency in a given context 
e.g., WWW .


In the example above, Obama, the living breathing President of the 
USA. Not a representation or an address of any kind, not accessible by 
HTML in any way, not a piece of information. Still, can be referred to 
by a name, and described by a representation. And this is what the 
whole discussion is about.
Typo redo, I am in constant motion right now, physical location wise 
right now. This is an important conversation, so I don't want typo 
confusion :-)


1. Obama - the human observation subject that doesn't exist on the Web 
in physical form

2. http://dbpedia.org/resource/Barack_Obama -- his Name
3. http://dbpedia.org/page/Barack_Obama -- the Address of an HTML based 
resource that describes him; you can also GET (access) this description 
in alternative formats via the following Addresses :

-- http://dbpedia.org/data/Barack_Obama.json
-- http://dbpedia.org/data/Barack_Obama.ntriples
-- etc..

4. Byte stream I receive when I de-reference the Name (via indirection): 
http://dbpedia.org/resource/Obama or access directly via Address -- 
actual representation .


It isn't as complex as we are making it seem, really.

Non Web Programmers have worked with de-reference (indirection) and 
address-of operations via operators for a long time en route to crafting 
very sophisticated Linked Data Structures. Courtesy, of TimBL's Linked 
Data meme, we can use Links to craft graphs that serve observation 
subject representations. Basically,  these graphs are Linked Data 
Structures but via hyperlinks unleashed at InterWeb scales. Using 
de-referencable URIs (in the generic sense) with HTTP scheme URIs as a 
cheap albeit unintuitive option, remains the point of confusion re. 
clearer narrative.


As you know, Object Identity is an old matter.
Object Identity distinct from Object Representation, ditto.
Representation exists somewhere.
Identifiers always have Referents.
Identifiers can Name Referents e.g. real-world entities.
Identifiers can also Name Locations i.e., specific Name for a specific 
type of Thing with specific characteristics e.g. Address (the place 
where you access stuff from)
URI abstraction encompasses generic Naming (de-reference / indirection) 
and Access (Address-of).


When we oscillate from URI to URL re., conversation marquee we 
repeatedly obscure the deeper issue of the URI abstraction itself (as 
expressed in the last item above). A URI is Cool not because "it doesn't 
change" but because it delivers a vehicle for de-reference (indirection) 
and address-of, and in so doing you end up with an abstraction where an 
Object Name is truly distinct from its Representation albeit explicitly 
connected, and as a result the Name becomes immortal (it doesn't change) 
while the understanding of the Name's Referent evolves ad infinitum.


When all is said and done we have our Names and the Deeds associated 
with those Names. Representations may vary, they just come and go :-)


Via Linked Data graphs (borne or carried via Resources) the WWW is a 
viable medium for effecting what I describe above.



Kingsley



Pat


I can even articulate this using the much overloaded "Resource" term by saying: 
courtesy of Linked Data tweak (or evolution) Web Resources now has a:

1. Name
2. Representa

Re: Schema.org in RDF ...


On 6/12/11 8:10 PM, Pat Hayes wrote:

Kingsley, Im not exactly sure what you are saying in all this, but... (read on)

On Jun 12, 2011, at 9:49 AM, Kingsley Idehen wrote:


On 6/12/11 3:42 PM, Richard Cyganiak wrote:

On 12 Jun 2011, at 11:12, Alan Ruttenberg wrote:

I've yet to encounter a person who didn't understand the difference between a 
book about Obama and Obama.

This has nothing to do with books about Obama.

It's about the difference between an URI-named resource which can return, say, 
a JSON representation of Obama; and a URI-named resource that *is* Obama. 
Explaining why using the same URI for both of those supposedly breaks the Web 
isn't *quite* that easy.

Best,
Richard


Richard,

It isn't about braking the Web or its AWWW, really. It's about how its always 
been when dealing with data via programs. An Object has:

1. Name
2. Representation Address
3. Actual Representation.

It also has 4. Its actual self, ie the object.


Yes it does. I was commenting on the Web Resource specifically, and it 
use as a mechanism for agency via observation subject representation.


As per your comment about self, the whole picture goes something like this:

1. Actual Observation Subject
2. Subject Identifier operating as a Name
3. Medium specific Representation Location (Address)
4. Actual Medium specific Representation.

2-4 collectively deliver agents and agency in a given context such as 
e.g. WWW .



In the example above, Obama, the living breathing President of the USA. Not a 
representation or an address of any kind, not accessible by HTML in any way, 
not a piece of information. Still, can be referred to by a name, and described 
by a representation. And this is what the whole discussion is about.


And that's what I am responding to:

1. Obama - The human that doesn't exist on the Web in physical form
2. http://dbpedia.org/resource/Barack_Obama -- Name
3. http://dbpedia.org/page/Barack_Obama -- Address of an HTML based 
resource that describes him; you can also get this description in 
alternative formats via:

-- http://dbpedia.org/data/Barack_Obama.json
-- http://dbpedia.org/data/Barack_Obama.ntriples
-- etc..

4. Byte stream I receive when I de-reference the Name: 
http://dbpedia.org/resource/Obama -- actual representation delivered via 
indirection operation .


It isn't as complex and we are making it seem, really. Non Web 
Programmers have worked with de-reference (indirection) and address-of 
operations via operators for a long time en route to crafting very 
sophisticated Linked Data Structures. Courtesy, of TimBL's Linked Data 
meme, graph based Linked Data Structures can now be crafted using 
de-referencable URIs (in the generic sense) with HTTP scheme URIs as a 
cheap albeit unintuitive option.



Kingsley


Pat


I can even articulate this using the much overloaded "Resource" term by saying: 
courtesy of Linked Data tweak (or evolution) Web Resources now has a:

1. Name
2. Representation Address
3. Actual Representation.

Prior to the use of Links for structured data representation a Resource had a:

1. Representation Address
2. Actual Representation.


It really is as simple as outlined above.

HTTP explicitly includes the ability to negotiate Actual Representation via 
mime types.


--

Regards,

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









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









--

Regards,

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

Re: Schema.org in RDF ...

Kingsley, Im not exactly sure what you are saying in all this, but... (read on)

On Jun 12, 2011, at 9:49 AM, Kingsley Idehen wrote:

> On 6/12/11 3:42 PM, Richard Cyganiak wrote:
>> On 12 Jun 2011, at 11:12, Alan Ruttenberg wrote:
>>> I've yet to encounter a person who didn't understand the difference between 
>>> a book about Obama and Obama.
>> This has nothing to do with books about Obama.
>> 
>> It's about the difference between an URI-named resource which can return, 
>> say, a JSON representation of Obama; and a URI-named resource that *is* 
>> Obama. Explaining why using the same URI for both of those supposedly breaks 
>> the Web isn't *quite* that easy.
>> 
>> Best,
>> Richard
>> 
> Richard,
> 
> It isn't about braking the Web or its AWWW, really. It's about how its always 
> been when dealing with data via programs. An Object has:
> 
> 1. Name
> 2. Representation Address
> 3. Actual Representation.

It also has 4. Its actual self, ie the object. In the example above, Obama, the 
living breathing President of the USA. Not a representation or an address of 
any kind, not accessible by HTML in any way, not a piece of information. Still, 
can be referred to by a name, and described by a representation. And this is 
what the whole discussion is about.

Pat

> 
> I can even articulate this using the much overloaded "Resource" term by 
> saying: courtesy of Linked Data tweak (or evolution) Web Resources now has a:
> 
> 1. Name
> 2. Representation Address
> 3. Actual Representation.
> 
> Prior to the use of Links for structured data representation a Resource had a:
> 
> 1. Representation Address
> 2. Actual Representation.
> 
> 
> It really is as simple as outlined above.
> 
> HTTP explicitly includes the ability to negotiate Actual Representation via 
> mime types.
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen   
> President&  CEO
> OpenLink Software
> Web: http://www.openlinksw.com
> Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca: kidehen
> 
> 
> 
> 
> 
> 
> 


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

Re: Schema.org in RDF ...

Hi Danny,

On 12 Jun 2011, at 17:57, Danny Ayers wrote:
>> We explicitly know the “expected types” of properties, and I'd like to keep 
>> that information in a structured form rather than burying it in prose. As 
>> far as I can see, rdfs:range is the closest available term in W3C's data 
>> modeling toolkit, and it *is* correct as long as data publishers use the 
>> terms with the “expected type.”
> 
> I don't think it is that close to "expected type"

I didn't say it's close to “expected type”. I said that we want to keep the 
information in a structured form, and that rdfs:range is the closest construct 
available in the W3C toolkit.

> <#something> :hasColour <#wet> .
> 
> then we get
> 
> <#wet> a :Colour .

If you apply RDFS/OWL reasoning to broken data, you get more broken data. I 
don't understand why anyone would be surprised by that.

Best,
Richard

Re: Schema.org in RDF ...

On 12 Jun 2011, at 18:34, Pat Hayes wrote:
>>> What do we say when the range of a property is supposed to be, say, people, 
>>> but its considered OK to insert a string to stand in place of the person?
>> 
>> Well, I can define a class that contains both people (in the foaf:Person 
>> sense) and names of people (that is, string literals).
> 
> Of course. But you didn't, did you? You (that is, Schema.org) said that the 
> range of the property was one of these and NOT the other. Which is what I was 
> complaining about.

Where is it said that the range is one and not the other?

Citing from the schema.rdfs.org FAQ [1], which has the same answer I gave 
earlier here in the thread:

>> Q: Schema.org documentation explicitly say that you can use a text instead 
>> of a Thing/Person/other type, why is this not reflected in the RDFS?

>> A: That's ok—we didn't say that schema:Thing is disjoint from literals, so 
>> you can use a string when the declared range is schema:Person. (We were 
>> tempted to add “xsd:string rdfs:subClassOf schema:Thing.” to capture this 
>> bit of the schema.org documentation, but narrowly decided against it.)

So I think it's all ok.

Best,
Richard

[1] http://schema.rdfs.org/faq.html

Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]

2011-06-12 Thread Alan Ruttenberg

On Sun, Jun 12, 2011 at 6:19 PM, Pat Hayes  wrote:
> but the serious problem with this idea is, that it makes it impossible to 
> simply refer to these information resources themselves. So we would be unable 
> to talk about Web pages using the Web description language RDF.

That seems too strong.

Just thinking about this alternative - that 200 responders (for the
purposes of linked data) are not considered IRs.
Instead 200 implies an assertion (for, say, http://www.ihmc.us/users/phayes/)

_:foo a :information-thing
_:foo :at "http://www.ihmc.us/users/phayes/"^^xsd:anyURI

(there exists an information resource accessible at
http://www.ihmc.us/users/phayes/)

to which could then be asserted in your favored syntax:

_:page a :web-page
_:page :at "http://www.ihmc.us/users/phayes/"^^xsd:anyURI
_:page dc:creator 

This effectively flips what is now the default (you would use, e.g.
foaf:primaryTopic to go in the opposite direction)

Not that I'm advocating this. For one thing there are many information
thinks that couldn't possibly be understood as designators. (well,
shouldn't ;-)

-Alan

Re: Schema.org in RDF ...


On Jun 12, 2011, at 7:36 AM, Richard Cyganiak wrote:

> On 12 Jun 2011, at 00:51, Pat Hayes wrote:
>> Well, I am sympathetic to not defending HTTP-range-14 and nobody ever, ever 
>> again even mentioning "information resource", but I don't think we can just 
>> make this go away by ignoring it. What do we say when a URI is used both to 
>> retrieve, um sorry, identify, a Web page but is also used to refer to 
>> something which is quite definitely not a web page?
> 
> Then we study the specific data provider to figure out if the published 
> assertions are about the web page or the topic of the web page, or apply 
> various kinds of heuristics to figure it out.
> 
> If we are logicians, then we say: “Oh, how clever, they are punning.”

:-)  I wish I knew how to build reasoners that could be this clever.

> 
>> What do we say when the range of a property is supposed to be, say, people, 
>> but its considered OK to insert a string to stand in place of the person?
> 
> Well, I can define a class that contains both people (in the foaf:Person 
> sense) and names of people (that is, string literals).

Of course. But you didn't, did you? You (that is, Schema.org) said that the 
range of the property was one of these and NOT the other. Which is what I was 
complaining about.

Pat

> This is not pretty, but it is pragmatic. A data consumer can use rules or 
> SPARQL CONSTRUCT to make the shape of the data more uniform.
> 
> Best,
> Richard
> 
> 
> 
>> In the first case we can just say that identifying and reference are 
>> distinct, and that one expects the web page to provide information about the 
>> referent, which is a nice comfortable doctrine but has some holes in it. 
>> (Chiefly, how then do we actually refer to a web page?) But the second is 
>> more serious, seems to me, as it violates the basic semantic model 
>> underlying all of RDF through OWL and beyond. Maybe we need to re-think this 
>> model, but if so then we really ought to be doing that re-thinking in the 
>> RDF WG right now, surely? Just declaring an impatient agnosticism and 
>> refusing to discuss these issues does not get things actually fixed here.
>> 
>> Pat
>> 
>> 
>> IHMC (850)434 8903 or (650)494 3973   
>> 40 South Alcaniz St.   (850)202 4416   office
>> Pensacola(850)202 4440   fax
>> FL 32502  (850)291 0667   mobile
>> phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> 


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: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]


On Jun 12, 2011, at 5:40 AM, Danny Ayers wrote:

> On 12 June 2011 01:51, Pat Hayes  wrote:
>> 
>> On Jun 11, 2011, at 12:20 PM, Richard Cyganiak wrote:
>> 
>>> ...
> It's just that the schema.org designers don't seem to care much about the 
> distinction between information resources and angels and pinheads. This 
> is the prevalent attitude outside of this mailing list and we should come 
> to terms with this.
 
 I think we should foster a greater level of respect for representation
 choices here. Your dismissal of the distinction between information
 resources and what they are about insults the efforts of many
 researchers and practitioners and their efforts in domains where such
 a distinction in quite important. Let's try not to alienate part of
 this community in order to interoperate with another.
>>> 
>>> Look, Alan. I've wasted eight years arguing about that shit and defending 
>>> httpRange-14, and I'm sick and tired of it. Google, Yahoo, Bing, Facebook, 
>>> Freebase and the New York Times are violating httpRange-14. I consider that 
>>> battle lost. I recanted. I've come to embrace agnosticism and I am not 
>>> planning to waste any more time discussing these issues.
>> 
>> 
>> Well, I am sympathetic to not defending HTTP-range-14 and nobody ever, ever 
>> again even mentioning "information resource", but I don't think we can just 
>> make this go away by ignoring it. What do we say when a URI is used both to 
>> retrieve, um sorry, identify, a Web page but is also used to refer to 
>> something which is quite definitely not a web page? What do we say when the 
>> range of a property is supposed to be, say, people, but its considered OK to 
>> insert a string to stand in place of the person? In the first case we can 
>> just say that identifying and reference are distinct, and that one expects 
>> the web page to provide information about the referent, which is a nice 
>> comfortable doctrine but has some holes in it. (Chiefly, how then do we 
>> actually refer to a web page?) But the second is more serious, seems to me, 
>> as it violates the basic semantic model underlying all of RDF through OWL 
>> and beyond. Maybe we need to re-think this model, but if so then we really 
>> ought to be doing that re-thinking in the RDF WG right now, surely? Just 
>> declaring an impatient agnosticism and refusing to discuss these issues does 
>> not get things actually fixed here.
> 
> For pragmatic reasons I'm inclined towards Richard's pov

Well, I am too. That is, I would love for this whole issue/problem to just go 
away. But I don't think ignoring it will make it go away. 

> , but it would
> be nice for the model to make sense.
> 
> Pat, how does this sound:
> 
> From HTTP we get the notions of resources and representations. The
> resource is the conceptual entity, the representations are concrete
> expressions of the resource. So take a photo of my dog -
> 
>  foaf:depicts  .
> 
> If we deref http://example.org/sasha-photo then we would expect to get
> a bunch of bits that can be displayed as an image.
> 
> But that bunch of bits may be returned with HTTP header -
> 
> Content-Type: image/jpeg
> 
> or
> 
> Content-Type: image/gif
> 
> Which, for convenience, lets say correspond to files on the server
> called sasha-photo.jpg and sasha-photo.gif
> 
> Aside from containing a different bunch of bits because of the
> encoding, sasha-photo.jpg could be a lossy-compressed version of
> sasha-photo.gif, containing less pixel information yet sharing many
> characteristics.
> 
> All ok so far..?
> 
> If so, from this we can determine that a representation of a resource
> need not be "complete" in terms of the information it contains to
> fulfill the RDF statement and the HTTP contract.

OK, so far. I would just note that (coming from a different, non-HTTP, 
tradition) I would never have even dreamt of any representation being 
"complete" in what I think is the sense you mean. So your care and emphasis 
here seem odd. But OK, I am following you...

> 
> Now turning to http://example.org/Sasha, what happens if we deref that?
> 
> Sasha isn't an information resource, so following HTTP-range-14 we
> would expect a redirect to (say) a text/html description of Sasha.

Really? I thought that HTTP-range-14 just said that if we get redirected, all 
bets are off, and the URI might denote anything at all, so the thing that gets 
returned might have nothing to do with the referent. 

> 
> But what if we just got a 200 OK and some bits Content-Type: text/html ?

Then (again, according to doctrine) the URI denotes the information resource 
which this is the HTTP-representation of. Which evidently is not Sasha.

> 
> We are told by this that we have a representation of my dog, but from
> the above, is there any reason to assume it's a complete
> representation?

No, but what has that got to do with anything? The key issue

Re: Schema.org in RDF ...

On 12 June 2011 16:26, Richard Cyganiak  wrote:
> Hi Pat,
>
> On 12 Jun 2011, at 00:33, Pat Hayes wrote:
 Nothing is gained from the range assertions. They should be dropped.
>>>
>>> They capture a part of the schema.org documentation: the “expected type” of 
>>> each property. That part of the documentation would be lost. Conversely, 
>>> nothing is gained by dropping them.
>>
>> Let me respectfully disagree. Range assertions (in RDFS or OWL) do *not* 
>> capture the notion of "expected type". They state a strict actual type, and 
>> cannot be consistently be "over-ridden" by some other information. Which has 
>> the consequence that these are liable to be, quite often, plain flat wrong. 
>> Which in turn has the consequence that there is something to be gained by 
>> dropping them, to wit, internal consistency. They are not mere 
>> documentation; they have strictly entailed consequences which many actual 
>> reasoners can and will generate, and which to deny would be to violate the 
>> RDFS specs. If you don't want these conclusions to be generated, don't make 
>> the assertions that would sanction them.
>
> Data on the Web is messy. You cannot reason over it without filtering it 
> first. I think it is useful to document how data publishers are *expected* to 
> use these terms, even if we know that many will -- for good or bad reasons -- 
> use them in *unexpected* ways.
>
>> For documentation, use the structures provided in RDFS for documentation, 
>> such as rdfs:comment.
>
> rdfs:comment is for prose. We explicitly know the “expected types” of 
> properties, and I'd like to keep that information in a structured form rather 
> than burying it in prose. As far as I can see, rdfs:range is the closest 
> available term in W3C's data modeling toolkit, and it *is* correct as long as 
> data publishers use the terms with the “expected type.”

I don't think it is that close to "expected type", or at least it's
kinda back to front. If we have -

:Colour a rdfs:Class .
:hasColour a rdf:Property .
:hasColour rdfs:range :Colour .

- and someone makes a statement

<#something> :hasColour <#wet> .

then we get

<#wet> a :Colour .

no?

so it's not an expectation thing, it's an inference that comes after
the fact...if you see what I mean.

As Pat suggested, I think this could easily lead to unintended conclusions.

Cheers,
Danny.







-- 
http://danny.ayers.name

Re: Schema.org in RDF ...


On 6/12/11 3:42 PM, Richard Cyganiak wrote:

On 12 Jun 2011, at 11:12, Alan Ruttenberg wrote:

I've yet to encounter a person who didn't understand the difference between a 
book about Obama and Obama.

This has nothing to do with books about Obama.

It's about the difference between an URI-named resource which can return, say, 
a JSON representation of Obama; and a URI-named resource that *is* Obama. 
Explaining why using the same URI for both of those supposedly breaks the Web 
isn't *quite* that easy.

Best,
Richard


Richard,

It isn't about braking the Web or its AWWW, really. It's about how its 
always been when dealing with data via programs. An Object has:


1. Name
2. Representation Address
3. Actual Representation.

I can even articulate this using the much overloaded "Resource" term by 
saying: courtesy of Linked Data tweak (or evolution) Web Resources now 
has a:


1. Name
2. Representation Address
3. Actual Representation.

Prior to the use of Links for structured data representation a Resource 
had a:


1. Representation Address
2. Actual Representation.


It really is as simple as outlined above.

HTTP explicitly includes the ability to negotiate Actual Representation 
via mime types.



--

Regards,

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

Re: Schema.org in RDF ...

On 11 Jun 2011, at 21:21, Giovanni Tummarello wrote:
> will you be posting this as a FAQ i think its definitely worth it.

Good idea, thanks. Some of the answers are now here:
http://schema.rdfs.org/faq.html

Richard



> 
> Gio
> 
> On Sat, Jun 11, 2011 at 6:55 PM, Richard Cyganiak  wrote:
>> All,
>> 
>> Thanks for the thoughtful feedback regarding schema.rdfs.org, both here and 
>> off-list.
>> 
>> This is a collective response to various arguments brought up. I'll 
>> paraphrase the arguments.
>> 
>>> Limiting ranges of properties to strings is bad because we LD people might 
>>> want to use URIs or blank nodes there.
>> 
>> Schema.org says the range is a string, and the RDFS translation reflects 
>> this. We tried to formally describe schema.org in RDFS. We did not try to 
>> make a fork that improves upon their modelling. That might be a worthwhile 
>> project too, but a different project.
>> 
>>> Schema.org documentation explicitly say that you can use a text instead of 
>>> a Thing/Person/other type.
>> 
>> This is the opposite case from the one above: They say that in place of a 
>> resource, you can always use a text. That's ok—we didn't say that 
>> schema:Thing is disjoint from literals. (I'm tempted to add “xsd:string 
>> rdfs:subClassOf schema:Thing.” to capture this bit of the schema.org 
>> documentation.)
>> 
>>> The range should use rdfs:Literal instead of xsd:string to allow language 
>>> tags.
>> 
>> That's a good point. The problem is that xsd:string is too narrow and 
>> rdfs:Literal is too broad. RDF 1.1 is likely to define a class of all string 
>> literals (tagged and untagged), we'll use that when its name has been 
>> settled, and perhaps just leave the inaccurate xsd:string in place for now.
>> 
>>> You should use owl:allValuesFrom instead of the union domains/ranges.
>> 
>> Probably correct in terms of good OWL modelling. But the current modelling 
>> is not wrong AFAICT, and it's nicer to use the same construct for single- 
>> and multi-type domains and ranges.
>> 
>>> Nothing is gained from the range assertions. They should be dropped.
>> 
>> They capture a part of the schema.org documentation: the “expected type” of 
>> each property. That part of the documentation would be lost. Conversely, 
>> nothing is gained by dropping them.
>> 
>>> You should jiggle where rdfs:isDefinedBy points to, or use wdrs:describedby.
>> 
>> 
>> This could probably be done better, but the way we currently do it is 
>> simple, and not wrong, so we're a bit reluctant to change it.
>> 
>>> You're missing an owl:Class type on the anonymous union classes.
>> 
>> Good catch, fixed. Thanks Holger!
>> 
>>> You should add owl:FunctionalProperty for all single-valued properties.
>> 
>> The schema.org documentation unfortunately doesn't talk about the 
>> cardinality of properties. Using heuristics to determine which properties 
>> could be functional seems a bit risky, given that it's easy to shoot oneself 
>> in the foot with owl:FunctionalProperty.
>> 
>>> There are UTF-8 encoding problems in comments.
>> 
>> Fixed. Thanks Aidan!
>> 
>>> You should mint new URIs and use http://schema.rdfs.org/Thing instead of 
>>> http://schema.org/Thing.
>> 
>> 
>> Schema.org defines URIs for a set of useful vocabulary terms. The nice thing 
>> about it is that the URIs have Google backing. The Google backing would be 
>> lost by forking with a different set of URIs.
>> 
>>> You should mint new URIs because the schema.org URIs don't resolve to RDF.
>> 
>> 
>> Dereferenceability is only a means to an end: establishing identifiers that 
>> are widely understood as denoting a particular thing. Let's acknowledge 
>> reality: Google-backed URIs with HTML-only documentation achieve this better 
>> than researcher-backed URIs which follow best practices to a tee with a 
>> cherry on top.
>> 
>>> You are violating httpRange-14 because you say that http://schema.org/Thing 
>>> is a class, while it clearly is an information resource.
>> 
>> Schema.org documentation uses these URIs as classes and properties in RDFa. 
>> They also return 200 from those URIs. So it's them who are violating 
>> httpRange-14, not us. Draw your own conclusion about the viability of 
>> httpRange-14.
>> 
>>> You should use http://schema.org/Thing#this.
>> 
>> 
>> Schema.org is using http://schema.org/Thing as a class in their RDFa 
>> documentation. I don't think we should mint different URIs in their 
>> namespace.
>> 
>>> http://schema.org/Person is not the same as foaf:Person; one is a class of 
>>> documents, the other the class of people.
>> 
>> I don't think that's correct at all. http://schema.org/Person is the class 
>> of people and is equivalent to foaf:Person. It's just that the schema.org 
>> designers don't seem to care much about the distinction between information 
>> resources and angels and pinheads. This is the prevalent attitude outside of 
>> this mailing list and we should come to terms with this.
>> 
>> Best,
>> Richard
>> 
>

Re: Schema.org in RDF ...

On 12 Jun 2011, at 11:12, Alan Ruttenberg wrote:
> I've yet to encounter a person who didn't understand the difference between a 
> book about Obama and Obama.

This has nothing to do with books about Obama.

It's about the difference between an URI-named resource which can return, say, 
a JSON representation of Obama; and a URI-named resource that *is* Obama. 
Explaining why using the same URI for both of those supposedly breaks the Web 
isn't *quite* that easy.

Best,
Richard

Re: Schema.org in RDF ...


On 6/12/11 2:26 PM, Lin Clark wrote:



Again, this strikes me as speaking from very little experience. I
spend a good deal of my time collaboratively developing ontologies and
working with users of them. I've yet to encounter a person who didn't
understand the difference between a book about Obama and Obama.


My experience is with an extensible system which powers about 2% of 
the Web, which has over 10,000 contributed modules and 1,000 
developers working on the core platform—Drupal.


100% of the Web and Internet is powered by "data access by reference" . 
It the most basic building block of computing, even pre silicon.


I have been one of the two primary people developing and educating 
users about the use of Linked Data technology in Drupal 7. This may be 
different than your experience, but it certainly isn't negligible 
experience when talking about the successful adoption of these 
technologies.


You are looking from Semantic Web narrative outwards instead of looking 
from the outside in. Do that and you'll grok Alan's point.



It depends on the manner in which the system is made extensible.
Architecture and good design matters. However, It is this attitude
that has led, in part, to the prulgation of schema.org
 as a closed
architecture.


The system is extensible via the hook system, which basically follows 
the aspect oriented paradigm. It also uses what can be considered a 
Presentation Abstraction Control architecture (also called 
Hierarchical MVC), where the different agents at different levels of 
the hierarchy can come from different modules designed by different 
developers. This extensibility means developers with a very wide range 
of knowledge and experience can contribute parts of the functionality. 
I think this is a good thing, as do many others who attribute Drupal's 
success to these architectural features.


Because different parts of the EAV relationship are extensible and can 
be developed by different developers in Drupal, it requires that all 
parties understand the distinction between info resource and thing 
resource and how to put that in practice.


"Information Resource" is a poor invented replacement due to overloaded 
use of "Resource".


A chunk of data at a location is a Resource. It can bear representation 
of a Document or be more granular by bearing data objects (via EAV/SPO 
3-tuples using links).


We used have a Web of Document Addresses (URLs) and now via Name 
indirection (i.e., de-referencable Names) we have a new layer of 
abstraction. Imagine if you used DNS as your annecdote re. evolution of 
the Web. Once we had NIC addresses and then we had Names, courtesy of 
DNS. Imagine an InterWeb of NIC addresses vs one driven by Names. Even 
simpler example, imagine a Spreadsheet without Cell Naming capability? 
Most people start their Spreadsheet experience with Cell Addresses and 
then evolve to using Cell Names. As I keep on saying, the pattern is 
old, the use of Hyperlinks and ubiquity of WWW combine to deliver new 
context for old concepts.



This means teaching them to/sometimes/ use hash URIs when content is 
entered (which overloads the hash URI with different meanings, as it 
is already used for another purpose in HTML) or to use 303's with 
content negotiation (which even some vocabulary publishers deeply 
embedded in the SemWeb world don't seem to understand how to do).


Good design does matter, but we have to define what we are optimizing 
for when we say good design:


* If you are optimizing for correctness, then good design means
  making everyone understand and use this new distinction and
  changing the workflow.
* If you are optimizing for large scale participation, then good
  design means you work with the workflows that users are already
  familiar with and just supplement those workflows with SemWeb
  technology where the technology has the chance of making
  something easier.


I do believe that if someone steps back and thinks about it, making 
the distinction between a Web page about a person and the person 
themselves does make sense. But most people aren't stepping back and 
thinking about it, they are doing... and we aren't there in the room 
with them to tell them to take a step back and think. We can wag 
fingers all we want at these people, but really the most successful 
Web designs Don't Make Me Think.


I think we also have to understand what is the best solution for 
now—when people don't yet understand these technologies and we need 
adoption—and what is the best solution for 10 years from now—when, if 
we have been successful at getting the tech adopted, people will 
understand the fundamentals of this technology and can be taken a step 
further.


Not understanding can be a function of chosen anecdote. This is the case 
most of the time re. Linked Data, RDF, and Semantic Web.


Best,
Lin



--

Regards,

Kingsley Idehen 
President&  C

Re: Schema.org in RDF ...

On 12 Jun 2011, at 00:51, Pat Hayes wrote:
> Well, I am sympathetic to not defending HTTP-range-14 and nobody ever, ever 
> again even mentioning "information resource", but I don't think we can just 
> make this go away by ignoring it. What do we say when a URI is used both to 
> retrieve, um sorry, identify, a Web page but is also used to refer to 
> something which is quite definitely not a web page?

Then we study the specific data provider to figure out if the published 
assertions are about the web page or the topic of the web page, or apply 
various kinds of heuristics to figure it out.

If we are logicians, then we say: “Oh, how clever, they are punning.”

> What do we say when the range of a property is supposed to be, say, people, 
> but its considered OK to insert a string to stand in place of the person?

Well, I can define a class that contains both people (in the foaf:Person sense) 
and names of people (that is, string literals). This is not pretty, but it is 
pragmatic. A data consumer can use rules or SPARQL CONSTRUCT to make the shape 
of the data more uniform.

Best,
Richard



> In the first case we can just say that identifying and reference are 
> distinct, and that one expects the web page to provide information about the 
> referent, which is a nice comfortable doctrine but has some holes in it. 
> (Chiefly, how then do we actually refer to a web page?) But the second is 
> more serious, seems to me, as it violates the basic semantic model underlying 
> all of RDF through OWL and beyond. Maybe we need to re-think this model, but 
> if so then we really ought to be doing that re-thinking in the RDF WG right 
> now, surely? Just declaring an impatient agnosticism and refusing to discuss 
> these issues does not get things actually fixed here.
> 
> Pat
> 
> 
> IHMC (850)434 8903 or (650)494 3973   
> 40 South Alcaniz St.   (850)202 4416   office
> Pensacola(850)202 4440   fax
> FL 32502  (850)291 0667   mobile
> phayesAT-SIGNihmc.us   http://www.ihmc.us/users/phayes
> 
> 
> 
> 
> 
>

Re: Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]


On 6/12/11 1:40 PM, Danny Ayers wrote:

On 12 June 2011 01:51, Pat Hayes  wrote:

On Jun 11, 2011, at 12:20 PM, Richard Cyganiak wrote:


...

It's just that the schema.org designers don't seem to care much about the 
distinction between information resources and angels and pinheads. This is the 
prevalent attitude outside of this mailing list and we should come to terms 
with this.

I think we should foster a greater level of respect for representation
choices here. Your dismissal of the distinction between information
resources and what they are about insults the efforts of many
researchers and practitioners and their efforts in domains where such
a distinction in quite important. Let's try not to alienate part of
this community in order to interoperate with another.

Look, Alan. I've wasted eight years arguing about that shit and defending 
httpRange-14, and I'm sick and tired of it. Google, Yahoo, Bing, Facebook, 
Freebase and the New York Times are violating httpRange-14. I consider that 
battle lost. I recanted. I've come to embrace agnosticism and I am not planning 
to waste any more time discussing these issues.


Well, I am sympathetic to not defending HTTP-range-14 and nobody ever, ever again even 
mentioning "information resource", but I don't think we can just make this go 
away by ignoring it. What do we say when a URI is used both to retrieve, um sorry, 
identify, a Web page but is also used to refer to something which is quite definitely not 
a web page? What do we say when the range of a property is supposed to be, say, people, 
but its considered OK to insert a string to stand in place of the person? In the first 
case we can just say that identifying and reference are distinct, and that one expects 
the web page to provide information about the referent, which is a nice comfortable 
doctrine but has some holes in it. (Chiefly, how then do we actually refer to a web 
page?) But the second is more serious, seems to me, as it violates the basic semantic 
model underlying all of RDF through OWL and beyond. Maybe we need to re-think this model, 
but if so then we really ought to be doing that re-thinking in the RDF WG right now, 
surely? Just declaring an impatient agnosticism and refusing to discuss these issues does 
not get things actually fixed here.

For pragmatic reasons I'm inclined towards Richard's pov, but it would
be nice for the model to make sense.

Pat, how does this sound:

> From HTTP we get the notions of resources and representations. The
resource is the conceptual entity, the representations are concrete
expressions of the resource. So take a photo of my dog -

  foaf:depicts  .

If we deref http://example.org/sasha-photo then we would expect to get
a bunch of bits that can be displayed as an image.

But that bunch of bits may be returned with HTTP header -

Content-Type: image/jpeg

or

Content-Type: image/gif

Which, for convenience, lets say correspond to files on the server
called sasha-photo.jpg and sasha-photo.gif

Aside from containing a different bunch of bits because of the
encoding, sasha-photo.jpg could be a lossy-compressed version of
sasha-photo.gif, containing less pixel information yet sharing many
characteristics.

All ok so far..?

If so, from this we can determine that a representation of a resource
need not be "complete" in terms of the information it contains to
fulfill the RDF statement and the HTTP contract.

Now turning to http://example.org/Sasha, what happens if we deref that?

Sasha isn't an information resource, so following HTTP-range-14 we
would expect a redirect to (say) a text/html description of Sasha.

But what if we just got a 200 OK and some bits Content-Type: text/html ?

We are told by this that we have a representation of my dog, but from
the above, is there any reason to assume it's a complete
representation?

The information would presumably be a description, but is it such a
leap to say that because this shares many characteristics with my dog
(there will be some isomorphism between a thing and a description of a
thing, right?) that this is a legitimate, however partial,
representation?

In other words, what we are seeing of my dog with -

Content-Type: text/html.

is just a very lossy version of her representation as -

Content-Type: physical-matter/dog

Does that make (enough) sense?

Cheers,
Danny.





Danny,

Quite a long route to saying:

You can use a hyperlinks to Name Observation Subjects.

Observation Subject have Representations at an Address.

Actual format of Observation Subject Representation is negotiable.

The brevity challenge is a function of using hyperlinks as Names since 
WWW users are only accustomed to their use as Resource Locators or 
Addresses (URLs).


Graph Models for describing Observation Subjects has made sense for a 
long time, pre WWW. It only when we try to state or infer that this is 
an RDF (syntax for expressing semantics) invention that al

Re: Schema.org in RDF ...

Hi Pat,

On 12 Jun 2011, at 00:33, Pat Hayes wrote:
>>> Nothing is gained from the range assertions. They should be dropped.
>> 
>> They capture a part of the schema.org documentation: the “expected type” of 
>> each property. That part of the documentation would be lost. Conversely, 
>> nothing is gained by dropping them.
> 
> Let me respectfully disagree. Range assertions (in RDFS or OWL) do *not* 
> capture the notion of "expected type". They state a strict actual type, and 
> cannot be consistently be "over-ridden" by some other information. Which has 
> the consequence that these are liable to be, quite often, plain flat wrong. 
> Which in turn has the consequence that there is something to be gained by 
> dropping them, to wit, internal consistency. They are not mere documentation; 
> they have strictly entailed consequences which many actual reasoners can and 
> will generate, and which to deny would be to violate the RDFS specs. If you 
> don't want these conclusions to be generated, don't make the assertions that 
> would sanction them.

Data on the Web is messy. You cannot reason over it without filtering it first. 
I think it is useful to document how data publishers are *expected* to use 
these terms, even if we know that many will -- for good or bad reasons -- use 
them in *unexpected* ways.

> For documentation, use the structures provided in RDFS for documentation, 
> such as rdfs:comment.

rdfs:comment is for prose. We explicitly know the “expected types” of 
properties, and I'd like to keep that information in a structured form rather 
than burying it in prose. As far as I can see, rdfs:range is the closest 
available term in W3C's data modeling toolkit, and it *is* correct as long as 
data publishers use the terms with the “expected type.”

Best,
Richard

Re: ANN: alpha version of Schema.org terms-to-RDF translator 'omnidator' available


On 6/12/11 1:38 PM, Michael Hausenblas wrote:



Great job!



Thanks. Not a real competitor to URIBurner, though ;)


No worried about competition though, always want as much clarity as 
possible, the cake is simply too large for any of us to be preoccupied 
with competition, that's what makes this whole Linked Data thing so 
different :-)





Little note, please tweak your Microdata tools description of the 
Virtuoso Sponger since URIBurner.com [1] delivers the same 
functionality of omnidator across the formats you mention + OData 
etc.. Alternatively, you can add URIBurner to the Microdata tools 
list [2].



Done, see http://schema.rdfs.org/tools.html


Thanks!!

Kingsley


Cheers,
Michael
--
Dr. Michael Hausenblas, Research Fellow
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

On 11 Jun 2011, at 23:35, Kingsley Idehen wrote:


On 6/11/11 6:08 PM, Michael Hausenblas wrote:


All,


The alpha version of omnidator [1] (omnipotent data translator), an 
online tool and (CORS-enabled) API to translate formats that use 
Schema.org terms into RDF is now available.


Currently only microdata and CSV as input formats are supported, but 
others (such as OData) are in the queue. Let us know what other 
formats you want omnidator to support, or, if you fancy chiming in, 
clone the repo [2] and send us a pull request.


Great job!

Little note, please tweak your Microdata tools description of the 
Virtuoso Sponger since URIBurner.com [1] delivers the same 
functionality of omnidator across the formats you mention + OData 
etc.. Alternatively, you can add URIBurner to the Microdata tools 
list [2].


Links:

1. http://uriburner.com -- note the URL input field (this has always 
been a translation service i.e., Virtuoso Sponger behind a domain) 
and the fact that it returns a URL for a Linked Data resource


2. http://schema.rdfs.org/tools.html -- Microdata tools page .

Kingsley



Cheers,
   Michael

[1] http://omnidator.appspot.com/

[2] https://github.com/mhausenblas/omnidator

--
Dr. Michael Hausenblas, Research Fellow
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






--

Regards,

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













--

Regards,

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

Re: Schema.org in RDF ...

2011-06-12 Thread Lin Clark

>
>
> Again, this strikes me as speaking from very little experience. I
> spend a good deal of my time collaboratively developing ontologies and
> working with users of them. I've yet to encounter a person who didn't
> understand the difference between a book about Obama and Obama.
>

My experience is with an extensible system which powers about 2% of the Web,
which has over 10,000 contributed modules and 1,000 developers working on
the core platform—Drupal. I have been one of the two primary people
developing and educating users about the use of Linked Data technology in
Drupal 7. This may be different than your experience, but it certainly isn't
negligible experience when talking about the successful adoption of these
technologies.


> It depends on the manner in which the system is made extensible.
> Architecture and good design matters. However, It is this attitude
> that has led, in part, to the prulgation of schema.org as a closed
> architecture.
>

The system is extensible via the hook system, which basically follows the
aspect oriented paradigm. It also uses what can be considered a Presentation
Abstraction Control architecture (also called Hierarchical MVC), where the
different agents at different levels of the hierarchy can come from
different modules designed by different developers. This extensibility means
developers with a very wide range of knowledge and experience can contribute
parts of the functionality. I think this is a good thing, as do many others
who attribute Drupal's success to these architectural features.

Because different parts of the EAV relationship are extensible and can be
developed by different developers in Drupal, it requires that all parties
understand the distinction between info resource and thing resource and how
to put that in practice. This means teaching them to* sometimes* use hash
URIs when content is entered (which overloads the hash URI with different
meanings, as it is already used for another purpose in HTML) or to use 303's
with content negotiation (which even some vocabulary publishers deeply
embedded in the SemWeb world don't seem to understand how to do).

Good design does matter, but we have to define what we are optimizing for
when we say good design:

   - If you are optimizing for correctness, then good design means making
   everyone understand and use this new distinction and changing the workflow.
   - If you are optimizing for large scale participation, then good design
   means you work with the workflows that users are already familiar with and
   just supplement those workflows with SemWeb technology where the technology
   has the chance of making something easier.


I do believe that if someone steps back and thinks about it, making the
distinction between a Web page about a person and the person themselves does
make sense. But most people aren't stepping back and thinking about it, they
are doing... and we aren't there in the room with them to tell them to take
a step back and think. We can wag fingers all we want at these people, but
really the most successful Web designs Don't Make Me Think.

I think we also have to understand what is the best solution for now—when
people don't yet understand these technologies and we need adoption—and what
is the best solution for 10 years from now—when, if we have
been successful at getting the tech adopted, people will understand the
fundamentals of this technology and can be taken a step further.

Best,
Lin

Squaring the HTTP-range-14 circle [was Re: Schema.org in RDF ...]

On 12 June 2011 01:51, Pat Hayes  wrote:
>
> On Jun 11, 2011, at 12:20 PM, Richard Cyganiak wrote:
>
>> ...
 It's just that the schema.org designers don't seem to care much about the 
 distinction between information resources and angels and pinheads. This is 
 the prevalent attitude outside of this mailing list and we should come to 
 terms with this.
>>>
>>> I think we should foster a greater level of respect for representation
>>> choices here. Your dismissal of the distinction between information
>>> resources and what they are about insults the efforts of many
>>> researchers and practitioners and their efforts in domains where such
>>> a distinction in quite important. Let's try not to alienate part of
>>> this community in order to interoperate with another.
>>
>> Look, Alan. I've wasted eight years arguing about that shit and defending 
>> httpRange-14, and I'm sick and tired of it. Google, Yahoo, Bing, Facebook, 
>> Freebase and the New York Times are violating httpRange-14. I consider that 
>> battle lost. I recanted. I've come to embrace agnosticism and I am not 
>> planning to waste any more time discussing these issues.
>
>
> Well, I am sympathetic to not defending HTTP-range-14 and nobody ever, ever 
> again even mentioning "information resource", but I don't think we can just 
> make this go away by ignoring it. What do we say when a URI is used both to 
> retrieve, um sorry, identify, a Web page but is also used to refer to 
> something which is quite definitely not a web page? What do we say when the 
> range of a property is supposed to be, say, people, but its considered OK to 
> insert a string to stand in place of the person? In the first case we can 
> just say that identifying and reference are distinct, and that one expects 
> the web page to provide information about the referent, which is a nice 
> comfortable doctrine but has some holes in it. (Chiefly, how then do we 
> actually refer to a web page?) But the second is more serious, seems to me, 
> as it violates the basic semantic model underlying all of RDF through OWL and 
> beyond. Maybe we need to re-think this model, but if so then we really ought 
> to be doing that re-thinking in the RDF WG right now, surely? Just declaring 
> an impatient agnosticism and refusing to discuss these issues does not get 
> things actually fixed here.

For pragmatic reasons I'm inclined towards Richard's pov, but it would
be nice for the model to make sense.

Pat, how does this sound:

>From HTTP we get the notions of resources and representations. The
resource is the conceptual entity, the representations are concrete
expressions of the resource. So take a photo of my dog -

 foaf:depicts  .

If we deref http://example.org/sasha-photo then we would expect to get
a bunch of bits that can be displayed as an image.

But that bunch of bits may be returned with HTTP header -

Content-Type: image/jpeg

or

Content-Type: image/gif

Which, for convenience, lets say correspond to files on the server
called sasha-photo.jpg and sasha-photo.gif

Aside from containing a different bunch of bits because of the
encoding, sasha-photo.jpg could be a lossy-compressed version of
sasha-photo.gif, containing less pixel information yet sharing many
characteristics.

All ok so far..?

If so, from this we can determine that a representation of a resource
need not be "complete" in terms of the information it contains to
fulfill the RDF statement and the HTTP contract.

Now turning to http://example.org/Sasha, what happens if we deref that?

Sasha isn't an information resource, so following HTTP-range-14 we
would expect a redirect to (say) a text/html description of Sasha.

But what if we just got a 200 OK and some bits Content-Type: text/html ?

We are told by this that we have a representation of my dog, but from
the above, is there any reason to assume it's a complete
representation?

The information would presumably be a description, but is it such a
leap to say that because this shares many characteristics with my dog
(there will be some isomorphism between a thing and a description of a
thing, right?) that this is a legitimate, however partial,
representation?

In other words, what we are seeing of my dog with -

Content-Type: text/html.

is just a very lossy version of her representation as -

Content-Type: physical-matter/dog

Does that make (enough) sense?

Cheers,
Danny.

-- 
http://danny.ayers.name

Re: ANN: alpha version of Schema.org terms-to-RDF translator 'omnidator' available

2011-06-12 Thread Michael Hausenblas




Great job!



Thanks. Not a real competitor to URIBurner, though ;)


Little note, please tweak your Microdata tools description of the  
Virtuoso Sponger since URIBurner.com [1] delivers the same  
functionality of omnidator across the formats you mention + OData  
etc.. Alternatively, you can add URIBurner to the Microdata tools  
list [2].



Done, see http://schema.rdfs.org/tools.html

Cheers,
Michael
--
Dr. Michael Hausenblas, Research Fellow
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

On 11 Jun 2011, at 23:35, Kingsley Idehen wrote:


On 6/11/11 6:08 PM, Michael Hausenblas wrote:


All,


The alpha version of omnidator [1] (omnipotent data translator), an  
online tool and (CORS-enabled) API to translate formats that use  
Schema.org terms into RDF is now available.


Currently only microdata and CSV as input formats are supported,  
but others (such as OData) are in the queue. Let us know what other  
formats you want omnidator to support, or, if you fancy chiming in,  
clone the repo [2] and send us a pull request.


Great job!

Little note, please tweak your Microdata tools description of the  
Virtuoso Sponger since URIBurner.com [1] delivers the same  
functionality of omnidator across the formats you mention + OData  
etc.. Alternatively, you can add URIBurner to the Microdata tools  
list [2].


Links:

1. http://uriburner.com -- note the URL input field (this has always  
been a translation service i.e., Virtuoso Sponger behind a domain)  
and the fact that it returns a URL for a Linked Data resource


2. http://schema.rdfs.org/tools.html -- Microdata tools page .

Kingsley



Cheers,
   Michael

[1] http://omnidator.appspot.com/

[2] https://github.com/mhausenblas/omnidator

--
Dr. Michael Hausenblas, Research Fellow
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






--

Regards,

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

Re: Schema.org in RDF ...


On 6/12/11 1:00 PM, Kingsley Idehen wrote:


Here is the problem, as I know it. We are using hyperlinks as a 
mechanism for data representation via HTTP URI based Names. The URI 
abstraction caters for two things: Names and Addresses. When trying to 
untangle the unintuitive nature of HTTP URIs as a Naming mechanism for 
Things (e.g., real world entities or objects), a narrative have 
emerged aimed at tacking the "hyperlink usage ambiguity problem" and 
its emerged in a manner expands the ambiguity to generality whereas 
this is just a function of Name mechanism choice.

Meant to say:


Here is the problem, as I know it. We are using hyperlinks as a 
mechanism for data representation via HTTP URI based Names. The URI 
abstraction caters for two things via *Schemes*: Names and Addresses. 
When trying to untangle the unintuitive nature of HTTP URIs, as a Naming 
mechanism for Things (e.g., real world entities or objects), a narrative 
have emerged aimed at *tackling* the "hyperlink usage ambiguity problem" 
and its emerged in a manner expands the aforementioned ambiguity to 
generality whereas this is just a function of HTTP scheme based Names.


--

Regards,

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

Re: Schema.org in RDF ...