Change "website" field to "url"

[pmackay]

website is a field in the organization and service entities. To have more alignment with schema.org naming, how about to rename this field to url, to match http://schema.org/url ?

Also some services may not be a whole website, they may be a page on a website, in which case labelling a field "website" when its just a page on one part of a website is misleading.

[haileypate]

+1

[migurski]

What’s the value in schema.org alignment?

[pmackay]

Its one pretty comprehensive option for reuse of existing terms. There are other others of course, as this Popolo appendix shows http://www.popoloproject.com/appendices/terms.html for the models they have developed (some of which are also relevant here).

Generally making data standards and APIs more consistent would improve interoperability.

[spara]

Accepted.

[monfresh]

Sorry for chiming in on this so late, but I wanted to provide some context around our decision. In Ohana API, url has a very specific meaning and purpose. It represents the URL of the API resource, and is used by our Ohanakapa Ruby wrapper to provide Hypermedia support. To represent a Location's or Organization's main website that people will visit, we chose to use website.

The OpenReferral spec is free to use whatever term it wants, but note that Ohana API will still be expecting website for an entity website. Also, since data in OpenReferral-compliant CSV files are likely to be entered by people who may not know what url means, I would recommend sticking to website, which everyone understands. By using url, you would have to add a note explaining what that means, so might as well just use website. The best documentation is no documentation.

For schema.org support, we've already added the microdata markup in ohana-web-search.

@pmackay Is there a specific example you can provide that demonstrates how url is better than website, or how it is breaking interoperability?

[pmackay]

@monfresh thanks for reply, that's some really useful info. There's several overlapping topics here:

Open Referral names As mentioned above, particularly for Location I'm not sure this field would always represent a website root. A location might have a web page on an organisation website. So semantically url is more general and covers those cases. But I agree that website could be a somewhat friendlier term for some people who are creating data.

Ohana API spec Is there a specific hypermedia strategy that Ohana is using? I found http://sookocheff.com/posts/2014-03-11-on-choosing-a-hypermedia-format/ which is a nice summary (and JSONAPI is mentioned in comments) and none of these approaches seem to use url as the property that represents the URL of the API resource. Sawyer doesnt suggest what hypermedia model it uses either (I may be missing something). JSON-LD uses @id. HAL uses _links: { self: { href: "example.com/api/1" } }

I'd personally like to see Ohana consider developing JSON-LD support and would be keen to help contribute to that where possible, but obviously that's a longer term issue.

The OpenReferral spec is free to use whatever term it wants, but note that Ohana API will still be expecting website for an entity website.

I'm still unsure of what leads the iteration of these projects from this statement. If OR is updated, does Ohana update to match? When would that not be the case? (It is good to keep data format and API in sync as close as possible but it doesnt have to be 100%).

Use of schema.org on the Ohana UI This is a good thing for the UI, but I see web page support for schema.org as separate from an API being consistent with schema.org terms (reason why I raised this issue).

The example in the JSON-LD section of http://sookocheff.com/posts/2014-03-11-on-choosing-a-hypermedia-format/ illustrates the point (not my example of course). When adapting to JSON-LD you define the context, so the author takes the property names of the Player object and renames them because "It’s a good idea to use standard naming for our APIs".