** apologies for cross-posting **
ESWC 2015 Programme and 2nd Call for Participation
http://2015.eswc-conferences.org
CFP: 12th European Semantic Web Conference (ESWC) 2015
Dates: May 30th – June 4th, 2015
Venue: Portoroz, Slovenia
Hashtag: #eswc2015
Feed: @eswc_conf
Site:
Kingsley,
To flesh out what you are seeking here, could you also include expected
(or suggested) HTTP server responses to requests that include this
profile relation?
Sure. Only headers resulting from the profile negotiation are included...
1) Using the Link-Header to specify a profile
On Thu, May 7, 2015 at 9:13 AM, Svensson, Lars l.svens...@dnb.de wrote:
Mark,
On Thu, May 7, 2015 at 7:05 AM, Martynas Jusevičius
marty...@graphity.org wrote:
On the other hand, it seems like you want different descriptions of a
resource -- so it seems to me that these should in fact be
Position: 1 PhD position
Duration: 3 years
Close Date: May 27 2015.
Formal application at:
http://ict.unitn.it/application/project_specific_grants#D3
A PhD position is open at the Fondazione Bruno Kessler, Trento Italy on
“combining planning and machine learning techniques for the re-planning of
So why don't you include both DCAT and PREMIS in the description and
let the client figure it out?
I haven't yet encountered a use case where profiles would be necessary.
WebArch only talks about representations (descriptions) that differ in
terms of media type:
Lars,
you could define a default profile using Graphity. It would be an
OWL class with annotations, e.g.:
#SomeResource a owl:Classs ;
gp:uriTemplate /some/resource ;
gp:query #ConstructDCAT .
#ConstructDCAT a sp:Construct ;
sp:text CONSTRUCT ... . # uses DCAT
You could implement a
As you wrote, media type is orthogonal to profiles. To retrieve
RDF/XML, you would use content negotiation (Accept header).
You would need to run the Graphity processor that would match URI
templates and execute SPARQL queries from the sitemap ontology.
Sure, instead of query strings you could
Martynas,
As you wrote, media type is orthogonal to profiles. To retrieve
RDF/XML, you would use content negotiation (Accept header).
You would need to run the Graphity processor that would match URI
templates and execute SPARQL queries from the sitemap ontology.
Sure, instead of query
(sorry for cross-posting, I think this is needed in this case)
Dear all:
I am happy to announce the start of the new W3C Automotive Ontology Community
Group.
Please join us at
https://www.w3.org/community/gao/
In this group, we want to advance the use of shared conceptual structures in
Mark,
On Thu, May 7, 2015 at 7:05 AM, Martynas Jusevičius
marty...@graphity.org wrote:
On the other hand, it seems like you want different descriptions of a
resource -- so it seems to me that these should in fact be different
resources? That could be split into
So why don't you include both DCAT and PREMIS in the description and
let the client figure it out?
Because that would mean that my payload would be at least twice as large (or
more, depending on how many profiles I want to support). Further, a client that
actually wants json but asks for
On 5/7/15 5:08 AM, Svensson, Lars wrote:
Kingsley,
To flesh out what you are seeking here, could you also include expected
(or suggested) HTTP server responses to requests that include this
profile relation?
Sure. Only headers resulting from the profile negotiation are included...
1) Using
Sorry if you receive this call several times.
We extended the deadline for application: now *30th of May*.
==
PhD studentship on French national project OpenSensingCity
==
École
On Thursday, May 07, 2015 4:16 PM, Kingsley Idehen wrote:
On 5/7/15 5:08 AM, Svensson, Lars wrote:
What behavior characteristics are being signaled by the profile relation
embedded in HTTP response metadata? Here's what I suspect you are
implying:
Request:
GET /resource/Linked_data
To my understanding, in a resource-centric model resources have a
description containing statements available about them.
When you try split it into parts, then you involve documents or graphs
and go beyond the resource-centric model.
On Thu, May 7, 2015 at 5:25 PM, Svensson, Lars
Lars,
I am not convinced your use case requires a whole new concept (and
following implementations) of Linked Data profiles.
I have outlined practical solutions you already can use now:
1. use a single description including all vocabularies
2. make separate resources with separate descriptions
Martynas,
I am not convinced your use case requires a whole new concept (and
following implementations) of Linked Data profiles.
I have outlined practical solutions you already can use now:
1. use a single description including all vocabularies
I have real customers that say already now
Call for Papers
5th Workshop on Linked Science 2015 — Best Practices and the Road Ahead
Workshop location: Bethlehem, PA, USA (co-located with the 14th
International Semantic Web Conference)
Workshop date: October 11 or 12, 2015
Submission Deadline: 7 July 2015, 23:59 Hawaii time
Notification
Martynas,
you could define a default profile using Graphity. It would be an
OWL class with annotations, e.g.:
#SomeResource a owl:Classs ;
gp:uriTemplate /some/resource ;
gp:query #ConstructDCAT .
#ConstructDCAT a sp:Construct ;
sp:text CONSTRUCT ... . # uses DCAT
You could
19 matches
Mail list logo
