Re: plural properties should become singular

On Feb 3, 2014, at 10:12 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Thursday, January 30, 2014 10:40 PM, Kingsley Idehen wrote:
>> On 1/30/14 1:28 PM, Ruben Verborgh wrote:
>>>> Why not?
>>>> 
>>>> OWL isn't a bad thing, so please use it where appropriate i.e., in
>>>> situations where indicating the cardinality of a property actually
>>>> value :-)
>>> So that's essentially the question I'm asking: does it add value?
>> 
>> Yes it does. But best to use it in situations where utility is utterly
>> obvious, as opposed to adding this kind of relation to every property
>> description. Thus, it should be used sparingly.
> 
> I quite like how GoodRelations is using it:
> 
>  http://www.heppnetz.de/ontologies/goodrelations/v1.html#conventions
> 
> but that might indeed be overkill for Hydra. In other words, I don't have a
> strong opinion about this.

Ultimately, if Hydra is intended to become a W3C Recommendation, working nicely with other specs, such as OWL may be an important factor. However, if the real world is geared towards influencing schema.org, then some alternative is probably necessary, as schema.org is already inconsistent with OWL (e.g., rangeIncludes/domainIncludes).

For my projects, i've often use OWL Restrictions to impose cardinality and range constraints, but with my web-developer hat on, this is really difficult to understand, so having an alternative notation would be useful, as long as we can give it some formal semantics which may tie it back to OWL.

Regarding the property pathing within the Gmail use case (review.reviewRating.ratingValue) is is overly tied to both a JSON/JavaScript interpretation of the nested structures, and is inconsistent with a multi-vocabulary use-case, or where properties are expressed as IRIs, where a '.' is a legitimate component of an IRI. We might look to an equivalent mechanism from SPARQL property paths, where this could be described as review/reviewRating/ratingValue (presuming a default vocabulary). This would also allow relative pathing and other useful features. I think it's important that Hydra not be exclusively bound to a JSON representation.

Gregg

>>> Earlier on this list, it has been emphasized that Hydra (also)
>>> focuses on non-RDF-minded developers.
>>> However, if this group of people is the largest, then OWL might not
>>> make much sense.
>> 
>> The issue isn't "OWL" the issue is having the semantics in the data so
>> that said semantics are comprehensible to agents (humans and bots). The
>> beauty of RDF is that it lets us have lots of SHOULDs and very few
>> MUSTs.
>> 
>>> But as I wrote before, interesting inferences could be made for Hydra
>>> with OWL [1].
>> 
>> Yes, and that should be there for engines with the capacity to reason
>> against OWL relation semantics, when encountered.
> 
> +1. Where it adds concrete value with little to no costs we should
> definitely add it. Even if just of use for a small group of users. I'm not
> much concerned about making the machine-readable vocabulary description
> "more complex". Very few non-RDF-minded developers will look at it anyway..
> and for those few who do, we can easily make the JSON-LD definition pretty
> enough.
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler

Received on Monday, 3 February 2014 18:45:58 UTC