RE: Local identifiers in IriTemplates

On 19 Dez 2014 at 11:37, Dietrich Schulten wrote:
> Am 16.12.2014 um 23:08 schrieb Markus Lanthaler:
>> On 15 Dez 2014 at 10:31, Dietrich Schulten wrote:
> 
> 
>>> Make ex:AcmeEvent a subClassOf schema:Event, then ex:acmeEventId
>>> rdfs:domain ex:AcmeEvent ex:acmeEventId rdfs:range xsd:Integer
>>> ex:acmeEventId a owl:FunctionalProperty ex:acmeEventId a
>>> owl:InverseFunctionalProperty
>> 
> 
>>> Why would I want to do that? I could tell a client "if you are
>>> asked for a both functional and inverseFunctional property of a
>>> subclass of schema:Event, then use 4711" - rather than having to
>>> tell it about a vendor-specific property acmeEventId. Bingo - no
>>> vendor-specific knowledge needed in advance.
>> 
>> Hmm... not sure whether that's such a good idea. What if you have
>> multiple of those identifiers? Think of, e.g., SKU and EAN or ISBN
>> numbers.
>
> That is part of my motivation: for *those* there are properties in
> schema.org. If the API can use such an ID, that is of course
> preferable over custom ids.

That was intended as an example. In companies with a certain size you often
see multiple identifiers for the same thing.


> So I can at least answer this question :)

:-)


>>> Would that be correct? If so, then this probably could also be
>>> generated somehow, at least with Spring-Hateoas which has a way
>>> to mark attributes as Identifiable.
>> 
>> I haven't thought too much about it but my gut feeling is that you
>> will run into all kinds of issues with such a heuristic. Why do you
>> try so hard to work around the fact that the number "4711" is a
>> vendor-specific, proprietary identifier? If it is, why can't it be
>> expressed using a vendor-specific, proprietary property?
> 
> Actually I am not trying to work around that fact but I try to find a
> way to document that fact in a machine-readable way. My proposal is in
> fact a propriety property, but I want to be able to describe it so
> that a machine could more easily recognize and handle it for what it is.

... and that's fine. What I find problematic is the heuristic you proposed.


> I guess what I need is a compelling use case. My issue has to do with
> the way I think of the way we should program clients for linked data.
> 
> Right now what we have is the Traverson approach: you tell the client
> to follow a rel path to achieve a goal. That is already a huge change,
> compared with the traditional way. But my mid-term goal is a client
> which I can tell to achieve a goal based on some predefined knowledge,
> and it finds its way through a hypermedia-enabled api.

Remind me of our discussion in Paris :-)


> Part of that predefined knowledge would be "necessary identifiers".

And how would those identifiers be stored in the client (before interacting
with the service the first time)? 


> Lots of issues to solve there, I know :)

Yeah, this is basically what I described you as being my goal as well -
modulo the identifier heuristics.


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 21 December 2014 22:11:55 UTC