On 8/15/14 9:31 PM, Ruben Verborgh wrote:
Hi Kingsley,

>I passed<http://data.mmlab.be/people/Anastasia+Dimou>  through our edition of 
Vapour [1]
Thanks for checking this. Below is what happens on HTTP level.
Looks fine to me. Do you spot an issue here?

$ curl -H "Accept: text/turtle" -Lhttp://data.mmlab.be/people/Anastasia+Dimou  
-i
HTTP/1.1 303 See Other
Server: nginx/1.1.19
Date: Fri, 15 Aug 2014 20:25:52 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: public, max-age=3600
Vary: Accept
Access-Control-Allow-Origin: *
X-Powered-By: Linked Data Fragments Server
Location:http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou

HTTP/1.1 200 OK
Server: nginx/1.1.19
Date: Fri, 15 Aug 2014 20:25:52 GMT
Content-Type: text/turtle;charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: public, max-age=3600
Vary: Accept
Access-Control-Allow-Origin: *
X-Powered-By: Linked Data Fragments Server

>  and it produced an unexpected result [2]
The result seems fine to me:

Dereferencing Entity URI (requesting (X)HTML)   3/3
Dereferencing Entity URI (requesting JSON-LD)   5/5
Dereferencing Entity URI (requesting RDF/XML)   2/3
Dereferencing Entity URI (requesting TURTLE)    5/5
Dereferencing Entity URI (without content negotiation)  2/2


All test that should pass, pass. (We don't offer XML.)

>i.e., unambiguous names resolve to description documents i.e., as exemplified 
by terms [3] in natural language, an identifier resolves to the description of its 
referent.
That's what we do, right?
-http://data.mmlab.be/people/Anastasia+Dimou  is the term
-http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou
  is the document about that term

>In the worst case, we'll fix any anomalies in our Vapour implementation.
Looks fine to me. Did something change in the meantime?

The issues arise from the conclusions. Basically, the denotation (name) aspect of the term isn't associated with its connotation (description document), via a discernible RDF relation. Hence output such as:

<http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou> denotes a Web document bearing JSON-LD content.

You can fix this by adding a relation that associate <http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou> with <http://data.mmlab.be/people/Anastasia+Dimou> .

Suggestions:

## Assuming the document describes a single term

<http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou>
foaf:primaryTopic <http://data.mmlab.be/people/Anastasia+Dimou> .


## Assuming the document describes a variety of termss

<http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou>
foaf:topic <http://data.mmlab.be/people/Anastasia+Dimou> .

## More IANA friendly

<http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou>
xhv:describes <http://data.mmlab.be/people/Anastasia+Dimou> .

## Powder exploitation

<http://data.mmlab.be/people/Anastasia+Dimou>
wdrs:described by
<http://data.mmlab.be/mmlab?subject=http%3A%2F%2Fdata.mmlab.be%2Fpeople%2FAnastasia%2BDimou>.

Via URIBurner [1][2] what you have works, due to the fact that we post process the description document and then inject missing relations to alleviate the issue highlighted in this thread.

Hope this clarifies matters.

Links:

[1] http://linkeddata.uriburner.com/c/9DQZ6O3L -- document description (note: Anastasia Dimou is denoted by a URI [confined to @href attribute of <a/>] that's used as the object of the foaf:topic relation)

[2] http://linkeddata.uriburner.com/c/9DQHQJ4L - actual description of Anastasia Dimou

[3] http://linkeddata.uriburner.com/c/9BQOSMMQ -- reified statement representing familyName relation .

--
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to