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

On 11 Sep 2014 at 11:08, Dietrich Schulten wrote:
> 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.

Sad but true, yeah.


[...]
> 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)

I think it actually never did as it wasn't built with RDF/Linked Data in
mind. You should probably raise than on the semantic-web or public-lod
mailing lists?


> 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?

Probably issue tracking isn't popular enough to be included into Schema.org
but it would be worth to find that out (simply send a mail to
public-vocabs@w3.org).



> 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'm certainly fine with such discussions as probably we all suffer from this
problem. The other lists you might wanna use for this is semantic-web or
public-lod@w3.org


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

Let me know how you find it.


Thanks,
Markus



> [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.tx
> t [2]
> http://heliosplatform.sourceforge.net/ontologies/2010/05/helios_bt.html#s
> 33 [3] http://www.w3.org/wiki/WebSchemas/SchemaDotOrgProposals


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 16 September 2014 19:17:34 UTC