Re: Encourage use of public vocabs, discourage use of private vocabs in Hydra

Am 07.09.2014 23:34, schrieb Markus Lanthaler:
> On 7 Sep 2014 at 15:52, Dietrich Schulten wrote:

>> Normally api authors SHOULD express the meaning of their 
>> responses in terms of schema.org or other public vocabs. If I 
>> have a special need, I SHOULD use a common extension mechanism, 
>> e.g. by deriving from existing enumerations or types. If in fact 
>> I am doing something unprecedented and want people to use it on 
>> the web, I SHOULD establish a vocabulary. (BTW if there is no 
>> vocab registry yet in IANA, Hydra could as well define one and 
>> name the ones that are currently out there :) )
>> 
>> I would love to hear your point of view about this.
> 
> I fully agree with what you wrote above. Are those capitalized 
> SHOULDs are intended to be RFC2119 keywords in the spec? I don't 
> think we should go down that path. It's enough to explain the 
> pros/cons and let people decide on their own. This is not
> something that affects Hydra conformance IMO.
> 

You are right. Probably it is enough to point out that for
interoperability it is best to use a well-established vocab.

Finding one is a not an easy task at all, and usually you quickly
reach the point that the vocabs do not express exactly what you need.
It will be interesting how that can be resolved, see below.

> 
>> For starters, there is quite a rich http://schema.org/Comment. I 
>> would find it most interesting to describe an issue system using 
>> Comment and see how its potentialAction property fits in with 
>> Hydra's operations.
> 
> That would be interesting, yes.

I tried to design an issue system and quickly found that Schema.org
has no Issue description. There are several vocabs for that, e.g.
[baetle], [evoont] and [helios_bt]. That is a typical experience. Some
research showed that baetle has adopted evoont [1], and Helios_bt
finally attempts to fulfill the goals of baetle [2]. The Helios draft
is at least in overall good shape, so one could at least use it, for
the moment.

Next typical experience: the urls in helios to evoont and oslc-cm do
not resolve anymore (It is uncredible how unstable urls are in the
Semantic Web. Those people or their webmasters should know better than
rearranging url spaces without proper redirects. Not even
http://www.w3.org/2001/XMLSchema#integer resolves anymore, it is now
at http://www.w3.org/TR/xmlschema-2/#integer)

Another typical experience is that even domain-specific vocabs are
usually lacking in some respect. In this case, I wanted something to
distinguish epic, story, task, bug, i.e. a qualified hierarchic
relationship. Helios has at least helios_bt:hasSubIssue, but there is
no property like an enumeration for type of issue which could be used
to express "Epic" vs. "Story" vs. "Task"

What is a good way to handle this situation, as an API designer? Fix
helios_bt on sourceforge or use it to create a schema.org adoption
proposal[3] for helios with IssueType enumeration?

That is going to be the difficult part, if we want to convince people
not to put up their own isolated vocabs quickly. Is this mailing list
the right place to discuss such issues for api-designers (which vocab
should I use for X and what do I do if there is no description of my
needed property Y)? Is there a suitable discussion forum for this sort
of question somewhere?

I'll look into the event api. That should be helpful to learn the
concepts.

Best regards,
Dietrich


[baetle] https://code.google.com/p/baetle/,
https://code.google.com/p/baetle/source/browse/ns/Baetle.n3
[evoont]
https://files.ifi.uzh.ch/ddis/oldweb/ddis/research/evoont/index.html
[helios_bt]
http://heliosplatform.sourceforge.net/ontologies/2010/05/helios_bt.html
[1]
https://code.google.com/p/baetle/source/browse/evoont/trunk/bom/README.txt
[2]
http://heliosplatform.sourceforge.net/ontologies/2010/05/helios_bt.html#s33
[3] http://www.w3.org/wiki/WebSchemas/SchemaDotOrgProposals



-- 
Dietrich Schulten
Escalon System-Entwicklung
Bubenhalde 10
74199 Untergruppenbach

Received on Thursday, 11 September 2014 09:09:40 UTC