[esip-semantictech] Interoperability and Semantic Tech recommended practices

[soren scott]

Apologies, I didn't quite provide enough context for the list.


   1. Provides a data dictionary in the documentation
   2. Provides payload in standard format (RDF, JSON-LD, etc)
   3. Provides codelist/controlled vocabulary as a service
   4. Provides ontology/vocabulary service


1: you are describing the fields/parameters of the data being served or the
service response keys in the documentation, ie "at least we don't have to
guess". Data dictionary might be a domain-specific term?

2: using JSON-LD with your CSV (or CSV-LD or Tables for The Web) or service
response to describe the structure in a machine friendly way. The
data/service is not, itself, using a standard/specification, though. This
is a lower barrier to entry for web reuse.

3: using a formal structure for a standard/specification, should it have
one, as a machine-readable service. Specific to vocabularies (often).

4: a full-blown ontology or vocabulary service.

2-4 aren't linear and don't entirely reflect the same concepts but it's a
starting point for people to yell at.

Please do yell away,
Soren

On Tue, Jun 7, 2016 at 2:10 PM, soren scott <sorenscott at gmail.com> wrote:

> Afternoon,
>
> For those that might not know, Products & Services is revising and
> expanding our software assessment guidelines this year. We started
> developing an outline of what a set of guidelines might include for
> interoperability last week and it includes a couple of semantic
> tech-specific areas, specifically related to web services/applications.
> We'd like to expand the guidelines to include interoperability and, in
> that, semantic tech specific information.
>
> If we start from a very basic "progression":
>
>    1. Provides a data dictionary in the documentation
>    2. Provides payload in standard format (RDF, JSON-LD, etc)
>    3. Provides codelist/controlled vocabulary as a service
>    4. Provides ontology/vocabulary service
>
> What characteristics do you look for in a "good" or "mature" service,
> particularly for #3 and 4? What is implementable now and what is an ideal?
> What we're looking for are things like you have to have persistent
> dereferencable URIs (implementable now) or you have a notification system
> (mailing list, etc) and you've committed to a deaccession plan in your
> documentation somewhere (an ideal but something we'd like to encourage).
> And any references related, absolutely fantastic.
>
> So actionable, not prescriptive (examples are great, though), from a
> server or client app. Also if there's anything particular to semtech
> services not captured in the above, that would also be much appreciated.
>
> Basically, what you tell someone standing up solid semweb services?
>
> Thanks,
> Soren
>
> --
>
> Soren Scott
> Research Coder
> The Ronin Institute for Independent Scholarship
> soren.scott at ronininstitute.org
>
> just a head's up - taking a bit of a sabbatical so if i don't
> get back to you right away, no worries.
>



-- 

Soren Scott
Research Coder
The Ronin Institute for Independent Scholarship
soren.scott at ronininstitute.org

just a head's up - taking a bit of a sabbatical so if i don't
get back to you right away, no worries.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.deltaforce.net/pipermail/esip-semanticweb/attachments/20160608/ec872b10/attachment.html>