Re: Local identifiers in IriTemplates

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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?
> 
> 
> Cheers, Markus

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.

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.
Part of that predefined knowledge would be "necessary identifiers".

Lots of issues to solve there, I know :)

Best regards,
Dietrich


- -- 
Dietrich Schulten
Escalon System-Entwicklung
Bubenhalde 10
74199 Untergruppenbach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iEYEARECAAYFAlST//YACgkQuKLNitGfiZMOigCgmOxMOQ7g/sPoV3Uinw00Mz72
OogAoJRBiewMCRqJjOCKV+NTqTEcbgMj
=k/40
-----END PGP SIGNATURE-----

Received on Friday, 19 December 2014 10:38:15 UTC