OpenLink Suggestions for SIOC Enhancements addendum

[Mitko Iliev]

Hi All,

The sites typically publish web services interfaces for programmatic Search
and Content Management services (typically SOAP and/or RESTian). These
services may be generic in nature (standardized signatures covering input
and output message formats) or service specific (where signatures are unique
to specific offering a 'la current Web 2.0 API usage patterns.

It is against this backdrop that we would like to suggest the following
enhancements to SIOC:

Class sioc:Service:

in-range-of : has_sevice, has_host
in-domain-of : service_of, host_of

Generic Services (Site-wide):
if service is site-wide, then "has_sevice" 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:type - generic (or site-wide), forum-specific
sioc:protocol - SOAP/REST/SPARQL-QUERY/GData/OpenSearch
dc:format - result format
sioc:maxresults - maximum number of results returned

Best Regards,

--
Mitko Iliev
Developer Virtuoso Team
OpenLink Software
http://www.openlinksw.com/virtuoso
Cross Platform Web Services Middleware

[John Breslin]

Hi Mitko -

Better late than never! I like the idea of a sioc:Service, with the
properties you outlined below (sioc:endpoint_url, type, protocol,
maximum_results etc.).

Maybe the linking properties could be something like:

Site / Forum -> has_interface -> Service
Service -> interface_of -> Site / Forum

(This'd reduce any problems with has_host being already used for linking
Forums to Sites.)

Uldis, any opinions?

The other subclass ideas (Weblog, Newsgroup etc.) could be part of the
sioc type module (which just has one entry so far, Comment)...

J.
--

--
Dr. John Breslin
DERI, NUI Galway
http://sw.deri.org/~jbreslin/
john.b...@deri.org

[Axel Polleres]

If we spin that further... shouldn't we also consider a connection with
SAWSDL then to describe the services?

http://www.w3.org/2002/ws/sawsdl/

Sounds like a paragraph to add in the Rel. Ontologies document.

just my 2 cents,
axel

--
Dr. Axel Polleres
email: ax...@polleres.net url: http://www.polleres.net/

[Uldis Bojars]

On 9/28/06, Mitko Iliev <imi...@openlinksw.co.uk> wrote:
>
> The sites typically publish web services interfaces for programmatic Search
> and Content Management services (typically SOAP and/or RESTian). These
> services may be generic in nature (standardized signatures covering input
> and output message formats) or service specific (where signatures are unique
> to specific offering a 'la current Web 2.0 API usage patterns.
>
> It is against this backdrop that we would like to suggest the following
> enhancements to SIOC:
>
> Class sioc:Service:
>
> in-range-of : has_sevice, has_host
> in-domain-of : service_of, host_of

Web service interfaces are an important topic. SIOC-enabled websites
(and not only them) already offer some kind of web service interface.
Further, we need to explore and develop this field more as currently
such web services like WordPress SIOC export just exist, but are not
formally described in SIOC or any other way.

But the fact that describing web service interfaces is an important
task makes one ask:
- is this task SIOC-specific? why?
- can existing and emerging web service standards be more appropriate?

We may need to add a simple service description to SIOC like Mitko
describes, but at the same time leave the specific details to
ontologies that are made for this purpose. This is a good place where
to reuse existing work.

Could you tell what parts of this proposal are really needed in SIOC
(maybe all) and how can we connect sioc:Service to ontologies /
formats that describe web service interfaces in detail? + What are
these ontologies / formats that we should consider.

In either case this relation (of SIOC sites and web service
descriptions) is something we may or even should cover in the
RelatedOntologies document.

Best,
Uldis

[ http://captsolo.net/info/ ]

[Alexandre Passant]

Hi All,

On 9/28/06, Mitko Iliev <imi...@openlinksw.co.uk> wrote:
>
>

> dc:title - human readable name of the service
> sioc:endpointURL - service endpoint
> sioc:type - generic (or site-wide), forum-specific
> sioc:protocol - SOAP/REST/SPARQL-QUERY/GData/OpenSearch
> dc:format - result format
> sioc:maxresults - maximum number of results returned
>

I'm currently working with WSDL [1], and its RDF mappings [2], and I'm
wondering if sioc:Service can be a subclass of wsdl:Service.
Indeed, a wsdl:Service is associated with an interface (eg: SPARQL
query) and got an endpoint, with a URL and some bindings (SOAP, HTTP).
So I think it's good to add the has_service / has_host and inverse to
link online services and associated webservices, but let most of the
service properties managed with wsdl RDF mappings.

Best,

Alex.

[1] http://www.w3.org/TR/wsdl20-primer/
[2] http://www.w3.org/TR/wsdl20-rdf/

[Kingsley Idehen]

Alexandre Passant wrote:
> Hi All,
>
> On 9/28/06, Mitko Iliev <imi...@openlinksw.co.uk> wrote:
>>
>>
>> dc:title - human readable name of the service
>> sioc:endpointURL - service endpoint
>> sioc:type - generic (or site-wide), forum-specific
>> sioc:protocol - SOAP/REST/SPARQL-QUERY/GData/OpenSearch
>> dc:format - result format
>> sioc:maxresults - maximum number of results returned
>>
>
> I'm currently working with WSDL [1], and its RDF mappings [2], and I'm
> wondering if sioc:Service can be a subclass of wsdl:Service.
> Indeed, a wsdl:Service is associated with an interface (eg: SPARQL
> query) and got an endpoint, with a URL and some bindings (SOAP, HTTP).
> So I think it's good to add the has_service / has_host and inverse to
> link online services and associated webservices, but let most of the
> service properties managed with wsdl RDF mappings.

Alex this would all be fine if all Web Services were SOAP based, but
unfortunately they aren't :-) This is why I suggested the rdfs:seeAlso
property of sioc:Service as the mechanism for referencing a Class in an
Ontology that specifically deals with Web Services Descriptions. The
existing definition of the sioc:Service class enables support for SOAP
and REST styles of services (i.e. exposing endpoints and metadata common
to both).

Let's not have SOAP vs REST obscure the rest of SIOC :-) If anything,
wsdl:Service should be a subclass of sioc:Service (at least in the SIOC
ontology), which makes rest:Service or basic:Service subclasses feasible
if need be.

Kingsley

>
> Best,
>
> Alex.
>
> [1] http://www.w3.org/TR/wsdl20-primer/
> [2] http://www.w3.org/TR/wsdl20-rdf/
>
>
>> Best Regards,
>>
>> --
>> Mitko Iliev
>> Developer Virtuoso Team
>> OpenLink Software
>> http://www.openlinksw.com/virtuoso
>> Cross Platform Web Services Middleware
>>
>>
>> >>
>>

--

Regards,

Kingsley Idehen Personal Blog: http://www.openlinksw.com/blog/~kidehen
President & CEO
OpenLink Software Web: http://www.openlinksw.com

[Alexandre Passant]

Hi,

Actually, there's nothing - or maybe I missed something ? - in WSDL
that says that services are SOAP only. The bindings property is there
to mention how to access the service, as in the wsdl definition of
SPARQL protocol [1]

Alex.

NB: I didn't mention it, but I'm referring to WSDL 2.0

[1] http://www.w3.org/TR/rdf-sparql-protocol/sparql-protocol-query.wsdl

[Kingsley Idehen]

That is true, but it isn't the problem :-) The problem is the
perception, many people simply "switch off" once they encounter "WSDL",
this is what I want us to factor into our decision. I have no issue with
WSDL (since we have supported it since inception), but there are broader
misconceptions that end up inadvertently hurting sioc:Service (IMHO).
Put differently, the issue isn't the WSDL itself, but the generation of
WSDL (which is basically generation of Service Metadata) that is a
problem for non SOAP and WSDL types.

Kingsley

[Uldis Bojars]

> >
> > I'm currently working with WSDL [1], and its RDF mappings [2], and I'm
> > wondering if sioc:Service can be a subclass of wsdl:Service.
> > Indeed, a wsdl:Service is associated with an interface (eg: SPARQL
> > query) and got an endpoint, with a URL and some bindings (SOAP, HTTP).
> > So I think it's good to add the has_service / has_host and inverse to
> > link online services and associated webservices, but let most of the
> > service properties managed with wsdl RDF mappings.
>
> Alex this would all be fine if all Web Services were SOAP based, but
> unfortunately they aren't :-) This is why I suggested the rdfs:seeAlso
> property of sioc:Service as the mechanism for referencing a Class in an
> Ontology that specifically deals with Web Services Descriptions. The
> existing definition of the sioc:Service class enables support for SOAP
> and REST styles of services (i.e. exposing endpoints and metadata common
> to both).
>
> Let's not have SOAP vs REST obscure the rest of SIOC :-) If anything,
> wsdl:Service should be a subclass of sioc:Service (at least in the SIOC
> ontology), which makes rest:Service or basic:Service subclasses feasible
> if need be.

I support Kingsley's arguments for not sublcassing sioc:Service or
making it dependent on WSDL. It (WSDL) is complex enough and WSDL RDF
2.0 is still a draft so making SIOC dependant on changes that are
later made to it will not be very wise. Besides, the argument that
complexity of WSDL can discourage use of sioc:Service can also be
true.

Therefore let's make sioc:Service a concept of its own and keep it
simple. It's purpose is to indicate presence of a service on a site.
And let's have a property that links this 'indication of presence'
(sioc:Service) to a detailed web service description.

This way we have a clear separation of tasks:
- sioc:Service - a concept in SIOC that says there is a service. (simple)
- web service description (e.g., in WSDL) that has detailed metadata
about a service (more complex).

Uldis

[ http://captsolo.net/info/ ]