- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 11 May 2015 17:45:51 -0400
- To: public-lod@w3.org
- Message-ID: <5551230F.9080309@openlinksw.com>
On 5/11/15 4:22 PM, Paul Houle wrote:
> I think there's the issue of the data format but also the problem that
>
> <http://someorganization.org/namespace/something>
>
> might represent someorganization.org <http://someorganization.org>'s
> viewpoint about :something if you are lucky. On the other hand you
> might want to know what somebody else thinks about that "thing" --
> i.e. you might want to follow a dbpedia identifier to get schema.org
> <http://schema.org> information on it that somebodyelse.net
> <http://somebodyelse.net> has compiled on the dbpedia universe.
>
> I.e. fundamentally dereferencing has to be extended to support the
> idea of "what does source X think about resource Y?"
That's what you get via a SPARQL Query Results URL. At the end of the
day, the aforementioned URL identifies a document comprised of content
that's dynamically generated from relational variables in the query body
combined with solution output directives associated with select,
construct, or describe query types.
> There is also the need to recognize that dereferencing has created a
> lot of confusion.
Yes, there is still mass confusion about HTTP URI based Names :(
As you know, Names have denotation and connotation duality i.e., a Name
by definition has interpretation that describes its referent. Thus,
Identifying anything with an HTTP URI based name implies it is
interpretable on an HTTP Network.
> I suspect some people have been intimidated from using RDF because
> they think that having names based on URLs means that they *have* to
> publish everything on the web.
Yes.
As to the scope of HTTP Name interpretation (public or private), that
should really boil down to resource access controls [1] that are also
driven by entity relationship type semantics.
Links:
[1] http://www.w3.org/wiki/WebAccessControl -- Web Access Controls
related Wiki
[2]
http://www.slideshare.net/kidehen/how-virtuoso-enables-attributed-based-access-controls
-- How fine-grained ACLs are implemented (using RDF) in Virtuoso .
Kingsley
>
> On Mon, May 11, 2015 at 3:14 PM, Kingsley Idehen
> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>
> On 5/11/15 11:54 AM, Svensson, Lars wrote:
>
> Kingsley,
>
> On Saturday, May 09, 2015 12:07 AM, Kingsley Idehen wrote:
> [...]
>
> So to repeat my question in another mail: I have an
> entity described by a
> (generic) URI.
>
> You have an entity identified by a IRI in RDF. If you are
> adhering to Linked Open
> Data principles, said IRI would take the form of an HTTP URI.
>
>
> Then I have three groups of documents describing
> that entity, the first uses
> schema.org <http://schema.org>, the second group uses
> org ontology and the third uses foaf.
>
> You have an entity identified by an HTTP URI. The dual
> nature of this kind of
> URI enables it function as a Name. The fundamental quality
> (attribute,
> property, feature) of a Name is that its interpretable to
> meaning ie., a Name
> also has a dual (denotation and connotation feature) which
> is what an HTTP URI
> is all about, the only different is that
> denotation->connotation (i.e. name
> interpretation) occurs in the hypermedia medium provided
> by an HTTP network
> (e.g. World Wide Web). Net effect, the HTTP URI resolves
> to and document at a
> location on the Web (i.e, a document at a location, which
> is the URL aspect of
> this duality).
>
> OK. I have an http URI that denotes an entity. Depending on
> the server configuration and what accept-headers I provide,
> the http dereferencing function returns a document at a location.
>
> All documents are available as RDF/XML, Turtle and
> xhtml+RDFa. How does a
> client that knows only the generic URI for the
> resource tell the server that it
> prefers foaf in turtle and what does the server answer?
>
> It can do stuff like this:
>
> curl -L -H "Accept:
> text/xml;q=0.3,text/html;q=1.0,text/turtle;q=0.5,*/*;q=0.3" -
> H "Negotiate: *" -I http://dbpedia.org/resource/Analytics
>
> OK, I can see how setting the Accept-header negotiates the
> media type. If I understand correctly, the Negotiate-header
> gives the server and intermediate proxies a carte blanche to
> negotiate things any way they prefer. I don't see any header
> that tells the server what profile/shape/vocabulary the client
> prefers.
>
>
> That's about a client negotiating different types of document
> content using a preference algorithm which in integral to
> Transparent Content Negotiation. It has nothing to do with a
> preferred vocabulary of terms e.g., dcterms vs schema.org
> <http://schema.org> in regards to terms used to describe something
> using RDF Language bases sentences/statements.
>
> If you want an RDF based entity description, where the terms used
> come from a specific vocabulary, that's where you could leverage a
> query language e.g., SPARQL. Of course, there are those that don't
> want to use SPARQL which could then lead to yet another kind of
> "profile" relation object, but ultimately such use will only be
> the equivalent of ignoring the existence of "multiplication" and
> "division" in regards to arithmetic operations.
>
> Conclusion: if folks want to build "profile" relations for
> selecting RDF content constructed using terms from a specific
> vocabulary, that's fine too, even though its utility would simply
> boil down to navigating politics.
>
>
> HTTP/1.1 303 See Other
> Date: Tue, 05 May 2015 16:01:06 GMT
> Content-Type: text/turtle; qs=0.35
> Content-Length: 0
> Connection: keep-alive
> Server: Virtuoso/07.20.3213 (Linux)
> i686-generic-linux-glibc212-64 VDB
> TCN: choice
> Vary: negotiate,accept
> Alternates: {"/data/Analytics.atom" 0.500000 {type
> application/atom+xml}},
> {"/data/Analytics.jrdf" 0.600000 {type application/rdf+json}},
> {"/data/Analytics.jsod" 0.500000 {type
> application/odata+json}},
> {"/data/Analytics.json" 0.600000 {type application/json}},
> {"/data/Analytics.jsonld" 0.500000 {type
> application/ld+json}},
> {"/data/Analytics.n3" 0.800000 {type text/n3}},
> {"/data/Analytics.nt" 0.800000
> {type text/rdf+n3}}, {"/data/Analytics.ttl" 0.700000 {type
> text/turtle}},
> {"/data/Analytics.xml" 0.950000 {type application/rdf+xml}}
>
> Given this Alternates-header: how can a client figure out
> what those representations look like (except for their media
> type)?
>
>
> Your Web Browser (a client) understands text/html. A Browser and
> other HTTP clients apply the same content handling rules to other
> content types (e.g., those related to images, sound, and video
> etc..) .
>
>
>
> Link:
> <http://mementoarchive.lanl.gov/dbpedia/timegate/http://dbpedia.org/resour
> ce/Analytics>; rel="timegate"
> Location: http://dbpedia.org/data/Analytics.ttl
> Expires: Tue, 12 May 2015 16:01:06 GMT
> Cache-Control: max-age=604800
>
> Best,
>
> Lars
>
>
>
> --
> 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
> <http://www.openlinksw.com/blog/%7Ekidehen>
> 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
>
>
>
>
>
> --
> Paul Houle
>
> *Applying Schemas for Natural Language Processing, Distributed
> Systems, Classification and Text Mining and Data Lakes*
>
> (607) 539 6254 paul.houle on Skype ontology2@gmail.com
> <mailto:ontology2@gmail.com>
> https://legalentityidentifier.info/lei/lookup
> <http://legalentityidentifier.info/lei/lookup>
--
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Monday, 11 May 2015 21:46:15 UTC