Update: OpenLink Suggestion re. SIOC
All,
This is a second attempt at uploading this post.
Class sioc:Service:
in-range-of : has_service, has_host
in-domain-of : service_of, host_of
Generic Services (Site-wide):
if service is site-wide, then "has_service" and "has_host" may be
associated
with every existing forum or not at all (to be discussed further).
Forum Services (Forum-specific):
When a given service is associated specifically with a given forum then
the
"has_sevice" and "has_host" predicates will be used to express such a
relationship.
Literal properties :
dc:title - human readable name of the service
sioc:endpointURL - service endpoint
sioc:serviceScope - generic (or site-wide), forum-specific
sioc:serviceProtocol - SOAP/REST/SPARQL-QUERY/GData/OpenSearch
sioc:resultsFormat - result format
sioc:maxResults - maximum number of results returned
Integration Notes:
rdfs:seeAlso can be used to associate sioc:Service with an RDF Data Set
representing the details of a given sioc:Service should such exist.
Example usage re. SAWSDL integration:
sioc:Service rdfs:seeAlso sawsdl:uri_of_wsdl_profile
Kingsley
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---
- Login to post comments
This resource is supported by Science Foundation Ireland under grant number SFI/02/CE1/I131 (Líon) and SFI/08/CE/I1380 (Líon 2) at the Digital Enterprise Research Institute, National University of Ireland, Galway.
Syndicate
Update: OpenLink Suggestion re. SIOC
Cleaner version of SIOC Enhancements for incorporation into Spec
Update:
Class: sioc:Service
Service - A Service is web service associated with a sioc:Site,
sioc:Forum, or sioc:Post.
in-range-of: sioc:has_service
in-domain-of: sioc:max_results sioc:results_format sioc:service_of
sioc:service_definition sioc:service_endpoint
sioc:service_default_endpoint sioc:service_protocol sioc:service_type
dc:description sioc_service_mode
A Service provides a programmatic means of interacting with Sites,
Forums, and Posts via Service Endpoints. A Service may be SOAP or REST
oriented with regards to implementation style. Examples of typical
Service based interactions include: Search and Content Management.
Property: sioc:has_service
has_service - Associates a sioc:Site, sioc:Forum, or sioc:Post with a
Web Service.
Inverse: sioc:service_of
OWL Type: ObjectProperty
Range: sioc:Service
Domain: sioc:Site sioc:Forum sioc:Post
Property: dc:description
dc:description - Blurb describing a Service.
OWL Type: ObjectProperty
Domain: sioc:Service
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Property: sioc:service_definition
service_definition - Associates a web service definition (e.g. a WSDL
URL) with a sioc:Service.
OWL Type: ObjectProperty
Domain: sioc:Service
Range: http://www.w3.org/2005/10/wsdl-rdf#Description
Links a Service to a wsdl-rdf:Description that describes its usage
signature formally.
Property: sioc:service_protocol
service_protocol - Associates a Application Protocol with a
sioc:Service.
OWL Type: ObjectProperty
Domain: sioc:Service
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Acceptable values include: SPARQL, GData, OpenSearch, and Other.
Property: sioc:service_type
service_type - Identifies the type (or style) of Web Service.
OWL Type: ObjectProperty
Domain: sioc:Service
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Acceptable values include: SOAP, XML-RPC, REST.
Property: sioc:service_default_endpoint
service_default_endpoint - Associates a WSDL endpoint a sioc:Service.
OWL Type: ObjectProperty
Domain: sioc:Service
Range: xmlns:wsdl="http://www.w3.org/2005/10/wsdl-rdf#Endpoint
Links a WSDL based Service to wsdl-rdf:Endpoint which is the preferred
(default) approach for this type of Service.
service_endpoint - Associates a non WSDL based sioc:Service with an
endpoint.
OWL Type: ObjectProperty
Domain: sioc:Service
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Links non WSDL based Service with a literal endpoint.
Property: sioc:service_of
service_of - Associates a sioc:Service with sioc:Site, sioc:Forum, or
sioc:Post
Inverse: sioc:has_service
OWL Type: ObjectProperty
Domain: sioc:Service
Range: sioc:Site sioc:Forum sioc:Post
Property: sioc:results_format
results_format - Format of data returned by a web service.
OWL Type: ObjectProperty
Domain: sioc:Service
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Acceptable values (MIME Types): text/rdf+n3, application/rdf+xml,
application/sparql-results+json, application/sparql-results+xml,
text/xml
Property: sioc:max_results
max_results - A numberic value used for restricting the number of
distinct items in a web service response (result).
OWL Type: DatatypeProperty
Domain: sioc:Service
Range: http://www.w3.org/2001/XMLSchema#integer
Property: sioc:access_mode
access_mode - Operational mode of sioc:access_mode
OWL Type: ObjectProperty
Domain: sioc:Service
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Acceptable values include: READ, WRITE, DELETE, ALL (meaning all modes).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
Sounds good, I made a suggestion on IRC that service_default_endpoint
and service_endpoint could just be done using a rdf:Alt sequence...
We need an IRC bot :)
So we could just have the one term service_endpoint instead...
J.
--
kidehen wrote:
> Cleaner version of SIOC Enhancements for incorporation into Spec
> Update:
>
> Class: sioc:Service
>
> Service - A Service is web service associated with a sioc:Site,
> sioc:Forum, or sioc:Post.
> in-range-of: sioc:has_service
> in-domain-of: sioc:max_results sioc:results_format sioc:service_of
> sioc:service_definition sioc:service_endpoint
> sioc:service_default_endpoint sioc:service_protocol sioc:service_type
> dc:description sioc_service_mode
>
> A Service provides a programmatic means of interacting with Sites,
>
...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
On 14/11/06, John Breslin wrote:
>
> Sounds good, I made a suggestion on IRC that service_default_endpoint
> and service_endpoint could just be done using a rdf:Alt sequence...
rdf:Alt is terribly unfashionable these days. And can be annoying to
query or access via API. I'd recommend using named properties
instead...
cheers,
Dan
> We need an IRC bot :)
>
> So we could just have the one term service_endpoint instead...
>
> J.
> --
> kidehen wrote:
> > Cleaner version of SIOC Enhancements for incorporation into Spec
> > Update:
> >
> > Class: sioc:Service
> >
> > Service - A Service is web service associated with a sioc:Site,
> > sioc:Forum, or sioc:Post.
> > in-range-of: sioc:has_service
> > in-domain-of: sioc:max_results sioc:results_format sioc:service_of
> > sioc:service_definition sioc:service_endpoint
> > sioc:service_default_endpoint sioc:service_protocol sioc:service_type
> > dc:description sioc_service_mode
> >
> > A Service provides a programmatic means of interacting with Sites,
> >
>
> ...
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
On 11/1/06, kidehen wrote:
>
> Literal properties :
>
> dc:title - human readable name of the service
> sioc:endpointURL - service endpoint
> sioc:serviceScope - generic (or site-wide), forum-specific
> sioc:serviceProtocol - SOAP/REST/SPARQL-QUERY/GData/OpenSearch
John and me discussed the addition of sioc:Service and here is a
proposal with some more details and refinements. Among other things we
put property names in sync with naming conventions used in SIOC.
Class: sioc:Service
Properties linking to other SIOC concepts:
- sioc:has_service ( range = sioc:Service )
- sioc:service_of ( inverse of has_service )
Other properties of sioc:Service:
- dc:title - human readable name of the service
- sioc:service_protocol - SOAP/REST/SPARQL-QUERY/GData/OpenSearch/...
- sioc:results_format - result format
- sioc:service_endpoint - service endpoint URL
- sioc:max_results - max number of results returned
This includes all of properties proposed except for sioc:serviceScope.
It seems redundant because there are already properties (has_service /
service_of) that link sioc:Site and other SIOC concepts to
sioc:Service and thus define their scope. Unless there is a strong use
case where it is needed let's drop it.
How has_service defines scope: if a service is a site-wide then [
sioc:Site sioc:has_service sioc:Service ]; if a service is specific to
a particular forum or other object then define has_service
relationships between all these objects and a service.
> Integration Notes:
> rdfs:seeAlso can be used to associate sioc:Service with an RDF Data Set
> representing the details of a given sioc:Service should such exist.
To integrate sioc:Service with its web service description we need a
stronger property than just rdfs:seeAlso - something that tells "look
for web service description there".
Integration property:
- sioc:service_description ( domain = sioc:Service; range can be left
open - usually it will be a WSDL description, but let's not restrict
w/o necessity )
That concludes the list of proposed additions. If that is OK, here are
the tasks that need to be done now:
1) add them to the ontology
2) describe them in the specification - * for this we need a short
text description for sioc:Service and each of the properties.
3) * define a list of potential values of sioc:protocol and add them
to the SIOC Types module.
Also, relations between sioc:Service and its potential use with WSDL,
SAWSDL and other ontologies needs to be described in the
http://esw.w3.org/topic/SIOC/RelatedOntologies.
I'll add the changes to the ontology and generate the specification.
Who can take the tasks of describing terms for the specification,
defining list of values (and their descriptions) for sioc:protocol and
add descriptions to RelatedOntologies document?
Uldis
[ http://captsolo.net/info/ ]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
Does sioc:service_description not imply a Literal Object that provides
blurb describing the service? This is why I never took this route in
the first place. I think sioc:service_definition is more specific to
the purpose at hand: defining the Web Service.
To conclude, we should have sioc:service_description for actual blurb
about service, and then use sioc:service_definition for the service
definition :-)
Kingsley
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
Yes it seems to be confusing alright; coincidentally I was thinking
about this this morning and thought that maybe "specification" or
"specifics" might be better... But "definition" would do too...
Funnily enough, the page here (and many others) -
http://www.w3.org/TR/wsdl - says Web Service Definition Language in the
header :)
Would anyone object to sioc:Webservice to separate this from wsdl:Service?
> Properties linking to other SIOC concepts:
>
> - sioc:has_service ( range = sioc:Service )
> - sioc:service_of ( inverse of has_service )
> Other properties of sioc:Service:
> - dc:title - human readable name of the service
> - sioc:service_protocol - SOAP/REST/SPARQL-QUERY/GData/OpenSearch/...
> - sioc:results_format - result format
> - sioc:service_endpoint - service endpoint URL
> - sioc:max_results - max number of results returned
In summary, I therefore propose these modifications / additions...
Change name to sioc:Webservice
+ dc:description - blurb about service
+ sioc:service_definition - link to more specifications (e.g. in WSDL)
J.
--
kidehen wrote:
> Does sioc:service_description not imply a Literal Object that provides
> blurb describing the service? This is why I never took this route in
> the first place. I think sioc:service_definition is more specific to
> the purpose at hand: defining the Web Service.
>
> To conclude, we should have sioc:service_description for actual blurb
> about service, and then use sioc:service_definition for the service
> definition :-)
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
On 11/9/06, John Breslin wrote:
>
> In summary, I therefore propose these modifications / additions...
>
> Change name to sioc:Webservice
sioc:Service sounds better to me. I do not think 'name clash' with
WSDL is an issue here because classes and properties are identified by
URIs, not by what's at the end of it. But any name is fine. What do
authors of the original proposal think?
> + dc:description - blurb about service
> + sioc:service_definition - link to more specifications (e.g. in WSDL)
+1
Uldis
[ http://captsolo.net/info/ ]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
REST should be removed from the sioc:protocol list of literal values
since it isn't a protocol :-) Thus the Literal values for this Property
would be:
XML-RPC
SOAP
SPARQL
GData
OpenSearch
Re. sioc:results_format we should use MIME types.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
On 11/9/06, kidehen wrote:
>
> REST should be removed from the sioc:protocol list of literal values
> since it isn't a protocol :-) Thus the Literal values for this Property
> would be:
>
> XML-RPC
> SOAP
> SPARQL
> GData
> OpenSearch
We need to come up with URIs for them (having literal values is not
great). Though that's the easy part, first we need to improve the list
of values a bit.
Query protocol and transport protocol are orthogonal. There can be
many combinations of both, e.g., SPARQL over HTTP and SPARQL over
SOAP. This means we can't simply throw values "SPARQL" and "SOAP"
together.
Two potential solutions:
a) "multiply" all the combinations of transport and query protocol,
resulting in different URIs for "SPARQL over HTTP" and "SPARQL over
SOAP";
b) split this property into two - transport and query.
The second option seems to be more universal and allows easier
querying for, say, all SPARQL endpoints.
What would be the potential list of values for each of the properties
if the 2nd options is chosen?
- transport: SOAP, HTTP [though technically SOAP also uses or can use
HTTP], XML-RPC [again, it uses HTTP]
- query: SPARQL, GData, OpenSearch, ... (are there more values we need to add?)
The SPARQL Protocol [ http://www.w3.org/TR/rdf-sparql-protocol/ ] also
has WSDL definitions for its SOAP and HTTP bindings.
If we define protocol types (SPARQL over HTTP / over SOAP) is there a
way we can link these URIs to their WSDL definitions already in the
types module? One issue I see is that the same WSDL definition
contains both binding for HTTP and SOAP - so just linking to the WSDL
file will not specify which protocol binding do we mean.
Maybe have different protocol types link directly to the binding they
implement, e.g. sparql_wsdl:queryHttpPost, :queryHttpGet or :querySoap
?
This is an interesting area - how to keep a simple web service
description in SIOC and at the same time properly link it to a
detailed definition in WSDL. Well worth exploring.
Uldis
[ http://captsolo.net/info/ ]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
Hi,
On 11/10/06, Uldis Bojars wrote:
> >
> Query protocol and transport protocol are orthogonal. There can be
> many combinations of both, e.g., SPARQL over HTTP and SPARQL over
> SOAP. This means we can't simply throw values "SPARQL" and "SOAP"
> together.
>
> Two potential solutions:
> a) "multiply" all the combinations of transport and query protocol,
> resulting in different URIs for "SPARQL over HTTP" and "SPARQL over
> SOAP";
> b) split this property into two - transport and query.
>
> The second option seems to be more universal and allows easier
> querying for, say, all SPARQL endpoints.
>
> What would be the potential list of values for each of the properties
> if the 2nd options is chosen?
I think the second choice is better, especially as we won't have to
redefine new combinations when adding new transport / query values.
BTW, I was also thinking in differenciating "type" of service (eg
query vs insert/update). So we might add another property for this (or
subclass Service but I think it will lead to something too complex at
the end)
So what about using the "type" property for this, "transport" for
SOAP, HTTP ... and "protocol" for SPARQL, GData ... ?
I also don't think we should provide too much information (as
max_results) in sioc:Service definition. The goal is simply to let
agents know where the endpoint is, and how to access it. So maybe
getting results type (mime ?) is also too much precise for our needs ?
Best,
Alex.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
Alex,
What about:
sioc:service_type - READONLY, READ-WRITE
sioc:service_transport - SOAP, XML-RPC, HTTP
sioc:service_protocol - SPARQL, GData, OpenSearch, Basic (basic Free
Text over HTTP)
Kingsley
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
How about service_access or access_level or access_mode instead of
service_type?
J.
--
kidehen wrote:
> Alex,
>
> What about:
>
> sioc:service_type - READONLY, READ-WRITE
> sioc:service_transport - SOAP, XML-RPC, HTTP
> sioc:service_protocol - SPARQL, GData, OpenSearch, Basic (basic Free
> Text over HTTP)
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
Hi,
On 11/10/06, John Breslin wrote:
>
> How about service_access or access_level or access_mode instead of
> service_type?
Indeed, it might be better to keep the type for what I call "protocol"
i.e. SPARQL Query, GData, plain text, as Kingsley suggested; and use
another property for the access type as access_mode (BTW, re. READONLY
/ READ-WRITE, maybe we have better to use READ / WRITE / DEL and allow
multiple properties for a single service)
Alex.
>
> J.
> --
> kidehen wrote:
> > Alex,
> >
> > What about:
> >
> > sioc:service_type - READONLY, READ-WRITE
> > sioc:service_transport - SOAP, XML-RPC, HTTP
> > sioc:service_protocol - SPARQL, GData, OpenSearch, Basic (basic Free
> > Text over HTTP)
> >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
Uldis Bojars wrote: wrote:
> On 11/1/06, kidehen
> >
> > Literal properties :
> >
> > dc:title - human readable name of the service
> > sioc:endpointURL - service endpoint
> > sioc:serviceScope - generic (or site-wide), forum-specific
> > sioc:serviceProtocol - SOAP/REST/SPARQL-QUERY/GData/OpenSearch
>
> John and me discussed the addition of sioc:Service and here is a
> proposal with some more details and refinements. Among other things we
> put property names in sync with naming conventions used in SIOC.
>
> Class: sioc:Service
>
> Properties linking to other SIOC concepts:
> - sioc:has_service ( range = sioc:Service )
> - sioc:service_of ( inverse of has_service )
>
> Other properties of sioc:Service:
> - dc:title - human readable name of the service
> - sioc:service_protocol - SOAP/REST/SPARQL-QUERY/GData/OpenSearch/...
> - sioc:results_format - result format
> - sioc:service_endpoint - service endpoint URL
> - sioc:max_results - max number of results returned
>
> This includes all of properties proposed except for sioc:serviceScope.
> It seems redundant because there are already properties (has_service /
> service_of) that link sioc:Site and other SIOC concepts to
> sioc:Service and thus define their scope. Unless there is a strong use
> case where it is needed let's drop it.
>
> How has_service defines scope: if a service is a site-wide then [
> sioc:Site sioc:has_service sioc:Service ]; if a service is specific to
> a particular forum or other object then define has_service
> relationships between all these objects and a service.
>
> > Integration Notes:
> > rdfs:seeAlso can be used to associate sioc:Service with an RDF Data Set
> > representing the details of a given sioc:Service should such exist.
>
> To integrate sioc:Service with its web service description we need a
> stronger property than just rdfs:seeAlso - something that tells "look
> for web service description there".
>
> Integration property:
> - sioc:service_description ( domain = sioc:Service; range can be left
> open - usually it will be a WSDL description, but let's not restrict
> w/o necessity )
>
> That concludes the list of proposed additions. If that is OK, here are
> the tasks that need to be done now:
>
> 1) add them to the ontology
> 2) describe them in the specification - * for this we need a short
> text description for sioc:Service and each of the properties.
> 3) * define a list of potential values of sioc:protocol and add them
> to the SIOC Types module.
>
> Also, relations between sioc:Service and its potential use with WSDL,
> SAWSDL and other ontologies needs to be described in the
> http://esw.w3.org/topic/SIOC/RelatedOntologies.
>
> I'll add the changes to the ontology and generate the specification.
>
> Who can take the tasks of describing terms for the specification,
> defining list of values (and their descriptions) for sioc:protocol and
> add descriptions to RelatedOntologies document?
>
> Uldis
>
> [ http://captsolo.net/info/ ]
We will provide the descriptions requested re. items 2&3.
I agree with the redundancy conclusions re. sioc:scope.
Kingsley
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
On 11/9/06, kidehen wrote:
>
> We will provide the descriptions requested re. items 2&3.
> I agree with the redundancy conclusions re. sioc:scope.
Here is a draft of the SIOC Specification (v1.11) that includes
sioc:Service and its properties:
http://sparql.captsolo.net/spec/
The ontology draft (which the specification is based on) can be found in SVN:
http://sw.deri.org/svn/sw/2005/08/sioc/ontology/ns.rdf
To make things easier I have added some initial descriptions. Please
look at new term definitions (taken from rdfs:comment properties in
the ontology) and descriptions (it comes after information about range
and domain) and send your suggestions.
Source for term descriptions:
http://sw.deri.org/svn/sw/2005/08/sioc/ontology/spec/doc/
Also added datatype definitions (xsd:integer) for properties that take
integer values. If you have experience with datatypes in RDF please
check if those are defined OK. I could have also chosen
xsd:positiveInteger, but the OWL guide says xsd:integer must be
supported by all reasoner yet does not say that about the positive
integer datatype.
More questions + things to do:
- is sioc:max_results really needed?
It goes deeper into specifying a web service than other properties and
seems to more belong in the web service definition than in
sioc:Service. Mainly I do not see how it can be useful w/o also
defining how the web service works, e.g., how to get the next result
set.
- what is the range of sioc:results_format?
Can we use MIME types for it?
- TODO - if needed, revise the section "External Classes and
Ontologies" ( http://sparql.captsolo.net/spec/#sec-external ). E.g.,
add dc:description and maybe change description of dc:title.
Uldis
[ http://captsolo.net/info/ ]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
Quoting Uldis Bojars:
> Here is a draft of the SIOC Specification (v1.11) that includes
> sioc:Service and its properties:
> http://sparql.captsolo.net/spec/
Looks good - if people don't agree with my proposal for
sioc:Webservice, we can instead use has_webservice and webservice_of
as the connecting properties? I'd like one or the other (not both)...
I understand that URIs can be used to uniquely identify sioc:Service
from wsdl:Service, that's fine, but I'd like the property name to be
slightly different (as with the other SIOC properties linking concepts).
Thanks,
John.
--
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
On 11/9/06, john.breslin@deri.org wrote::
>
> Quoting Uldis Bojars
>
> > Here is a draft of the SIOC Specification (v1.11) that includes
> > sioc:Service and its properties:
> > http://sparql.captsolo.net/spec/
>
> Looks good - if people don't agree with my proposal for
> sioc:Webservice, we can instead use has_webservice and webservice_of
> as the connecting properties? I'd like one or the other (not both)...
In order to have a property name that is more specific we may choose
sioc:WebService or sioc:Webservice.
> I understand that URIs can be used to uniquely identify sioc:Service
> from wsdl:Service, that's fine, but I'd like the property name to be
> slightly different (as with the other SIOC properties linking concepts).
If the aim is to try to avoid confusion then it does not really work.
Reason: according to Swoogle there are enough classes named
"Webservice" and "WebService" as well. It also makes sense - people
are choosing names that best describe what they have in mind. If we
will try to find a name that's not been used before we will probably
end up with a name that is hard to remember or has only a vague
association with what we want to describe.
The aim to make the name more specific though makes perfect sense.
Uldis
[ http://captsolo.net/info/ ]
>
> Thanks,
>
> John.
> --
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Update: OpenLink Suggestion re. SIOC
On 11/9/06, Uldis Bojars wrote:
> - what is the range of sioc:results_format?
> Can we use MIME types for it?
Related: about URIs for MIME types
http://groups-beta.google.com/group/atom-owl/browse_frm/thread/468e48b8aba9771d/2f19faa1e2866e8d?lnk=gst&q=iana+mime-type+&rnum=1#2f19faa1e2866e8d
Short URL: http://tinyurl.com/txxxj
Uldis
[ http://captsolo.net/info/ ]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---